Re: elilo-installer copyright status
Hey Dann, Not sure what you want me to say, but GPL version 2 or later is fine with me. It was a long time ago, but as I recall I just wrote a shell script and did a bit of packaging work. Richard dann frazier wrote: (Trying a different address for Richard, @debian.org bounces) On Sat, Sep 29, 2007 at 03:08:36AM -0400, Joey Hess wrote: Peter Rock wrote: Hello, I hope I'm contacting the right folks! I'm trying to find out the copyright status of the elilo-installer package to see if it qualifies as free software or not. Below is a bit of a description and I was advised by debian-legal to ask the package maintainers. Hope someone can help! Bdale is the original author of elilo-installer, although it's derived from lilo-installer. rhirst, cjwatson, bubulle, dannf, Jim Lieb, and I have each made changes that might be substantial enough to be copyrightable (or not). Since lilo-installer is licensed under the GPL version 2 or later, I suggest it's sanest for elilo-installer to have the same license. I place my modifications to it under this license. Could the listed people please respond with a similar statement? Isn't this our _second_ udeb that got past the ftp-masters with no copyright file? It's not the last one. See upcoming mail for quik-installer. :-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge
On Mon, Apr 12, 2004 at 09:19:27AM -0500, James Bottomley wrote: On Mon, 2004-04-12 at 06:12, Richard Hirst wrote: It may be relevant that the ISO had a rather long kernel commandline, relative to the 127 char limit that palo claims. I'm never sure whether that 127 char limit is before or after palo adds all the console and sti related parameters though. That limit is absolute and may not be overrun. The co-ordinates of the 64 bit kernel lie immediately after the 128 char buffer. Usually the system is unbootable if you overrun this limit. Unbootable, or unbootable on 64 bit h/w? Unfortunately, palo is rather poor about checking this limit when installing the image or modifying the command line... and last time I tried building palo on a sid system to investigate these hangs on boot, the result didn't work at all :( Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: if something is not done, hppa will not have an installer for sarge
On Mon, Apr 12, 2004 at 10:15:46AM -0500, James Bottomley wrote: On Mon, 2004-04-12 at 10:05, Richard Hirst wrote: Unbootable, or unbootable on 64 bit h/w? It seems to be unbootable entirely, but for 32 bit kernels that's random (sometimes it will, sometimes it won't). Unfortunately, palo is rather poor about checking this limit when installing the image or modifying the command line... and last time I tried building palo on a sid system to investigate these hangs on boot, the result didn't work at all :( I think just reducing the command line would be the best option. Why's it so long? This is the cmdline when booting from the aforementioned ISO: Command line for kernel: 'ramdisk_size=8192 root=/dev/ram devfs=mount,dall init=/linuxrc DEBCONF_PRIORITY=high console=tty0 sti=8/24 sti_font=VGA8x16 TERM= linux palo_kernel=0/vmlinux' Looks like 162 chars to me. You can deduce how much of that comes from the d-i build process and how much is manufactured by palo on boot from the start of the ISO: 000: 8000 5041 4c4f 0003 00c8 e000 003d fddd ..PALO...=.. 010: 0053 5000 001b e9de 302f 766d 6c69 6e75 .SP.0/vmlinu 020: 7820 7261 6d64 6973 6b5f 7369 7a65 3d38 x ramdisk_size=8 030: 3139 3220 726f 6f74 3d2f 6465 762f 7261 192 root=/dev/ra 040: 6d20 2020 2020 2069 6e69 7472 643d 302f m initrd=0/ 050: 7261 6d64 6973 6b20 6465 7666 733d 6d6f ramdisk devfs=mo 060: 756e 742c 6461 6c6c 2069 6e69 743d 2f6c unt,dall init=/l 070: 696e 7578 7263 2044 4542 434f 4e46 5f50 inuxrc DEBCONF_P 080: 5249 4f52 4954 593d 6869 6768 RIORITY=high I don't know what default ramdisk size we build the kernel for, but it needs to be over 6MB (initrd is 6449152 bytes this time). Note palo has added at least console=tty0 sti=8/24 sti_font=VGA8x16 TERM=linux palo_kernel=0/vmlinux which looks like 71 of our 127 chars - hence my comment about whether or not the 127 char limit is supposed to include the bits added by palo. If we just take the part that is passed to palo when the ISO is mastered, I guess that is ramdisk_size=8192 root=/dev/ram initrd=0/ramdisk devfs=mount,dall init=/linuxrc DEBCONF_PRIORITY=high which is well under 127. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why is it so hard to build?
Hi Willy, Basically needs more developer effort to get it working well on hppa. Unfortunately I've been too busy lately and have dedicated the time I did have to d-i for ia64. You need to build on unstable, and I iirc the QM_MODULES thing was a glibc or kernel headers issue. I have built it for hppa in the past, and had some success installing on a B180. There was also an issue with mklibs reducing libm to (nearly) nothing, and that breaking glibc. Carlos fixed glibc, but I don't know if his fix is in debian unstable. I had a hack to mklibs to work round it. Recently I saw a mail saying anna changes means d-i only works with di-kernel-image based kernels now, and I don't think hppa is there yet. Richard On Tue, Mar 16, 2004 at 09:14:25PM +, Matthew Wilcox wrote: I've had three attempts at building d-i for hppa. 1. It won't build on a woody system (the packages it wants aren't available). 2. Documentation is broken -- build/README does not document that make build_netboot won't work. You need to type fakeroot make build_netboot instead. 3. It won't build on this kernel: mkdir -p ./tmp/netboot/tree/lib/modules/2.4.20-32-udeb/kernel; if [ -e ./tmp/netboot/tree/boot/System.map ]; then depmod -F ./tmp/netboot/tree/boot/System.map -q -a -b ./tmp/netboot/tree/ 2.4.20-32-udeb; mv ./tmp/netboot/tree/boot/System.map ./tmp/netboot; else depmod -q -a -b ./tmp/netboot/tree/ 2.4.20-32-udeb; fi; mkdir -p ./tmp/netboot/tree/lib/modules/2.4.20-64-udeb/kernel; if [ -e ./tmp/netboot/tree/boot/System.map ]; then depmod -F ./tmp/netboot/tree/boot/System.map -q -a -b ./tmp/netboot/tree/ 2.4.20-64-udeb; mv ./tmp/netboot/tree/boot/System.map ./tmp/netboot; else depmod -q -a -b ./tmp/netboot/tree/ 2.4.20-64-udeb; fi; depmod: QM_MODULES: Function not implemented joshk willy: QM_MODULES: Function not implemented? willy joshk: Indeed. bob2 known silly bug willy ... is there a workaround? bob2 no, I've been tagged wontfix *sigh* -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman-palo template
On Sat, Mar 06, 2004 at 03:32:59PM +0100, cobaco wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, the partman-palo template states that the palo partition should be in the first 2 /Mb/ Im guessing this needs to be either MB or MiB ? It would be 2GB (or GiB), not 2MB. Richard - -- Cheers, cobaco 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFASeEb5ihPJ4ZiSrsRAvPIAJ9dBcEcJ9V71CqWYRPc0nh5iiryNgCbBCWi dZJv7fUUM4NiQ5c1vg49WMs= =CpqC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Default partition table type for non i386?
On Wed, Mar 03, 2004 at 10:05:48AM +0200, Anton Zinoviev wrote: Hi! Can people working on non-i386 tell how we can find the default partition table type. This is necessary for the autopartitioner of partman to work on them and will also simplify the dialog for creation of new partition table. Currently parted supports the following partition tables: bsd, gpt, mac, dvh, msdos, pc98, sun and amiga. hppa/parisc uses msdos. ia64 uses gpt. m68k is tricky, but the vme subarchs use msdos. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia64 boot failure - no kernel
On Tue, Feb 10, 2004 at 04:48:40PM -0800, Aaron Brashears wrote: I downloaded, burned, and ran sarge-ia64-netinst.iso, but with no luck. On boot, the box lands in an 'EFI Boot Manager' which allows boot device selection. I point it at the cd (named 'cdrom2' in my configuration) and tell the boot manager to boot from there, and get: Loading.: cdrom2 Starting: cdrom2 ELILO elilo.c(line 70):Kernel file not found Start of cdrom2 failed: Load Error Looks like you told elilo to load a kernel called 'cdrom2'? I'd normally do something like 'fs2:' to switch to device 'fs2', and then 'elilo' which causes it to load elilo.conf from that dir. I got the sarge iso from: http://gluck.debian.org/cdimage/testing/netinst/ia64/daily/ Is there any further information I could provide which would help with debugging the ia64 boot for sarge? Try an image from http://gluck.debian.org/cdimage/testing/sid_d-i/netinst/ia64/ Those images have fixes to the bootimage layout, which should mean they can be booted rather more easily. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i doesn't load ext3-modules udeb on ia64
This is the daily build for 20040208, netinst iso. ext3-modules is on the iso, but it is not getting loaded. I had to manually udpkg -i /cdrom/.../ext3-modules*udeb and then modprobe jbd ext3. I don't know why ext3-modules isn't automatically loaded; any ideas? Also, I selected a local mirror, it prompted with a path of /debian which I accepted. It then went and tried to access http:/debiandist/... I had to modify the suggested path to be /debian/ for to to work. Finally, it wouldn't come back up on reboot because elilo-3.4-5 is not yet in testing - needed to load the initrd on reboot. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i doesn't load ext3-modules udeb on ia64
On Mon, Feb 09, 2004 at 02:23:43PM +, Richard Hirst wrote: This is the daily build for 20040208, netinst iso. ext3-modules is on the iso, but it is not getting loaded. I had to manually udpkg -i /cdrom/.../ext3-modules*udeb and then modprobe jbd ext3. I don't know why ext3-modules isn't automatically loaded; any ideas? Also, I selected a local mirror, it prompted with a path of /debian which I accepted. It then went and tried to access http:/debiandist/... I had to modify the suggested path to be /debian/ for to to work. Finally, it wouldn't come back up on reboot because elilo-3.4-5 is not yet in testing - needed to load the initrd on reboot. I sent this a bit too soon. elilo wont run because fat-modules is not installed. Again, the udeb is on the iso, but not installed by d-i. In this case, the udeb is priority extra which I guess is wrong (assuming that matters). Also, the system did come back up after boot, because the 2.4.22 initrd-based kernel is not yet in testing, so the older 2.4.20 which doesn't use an initrd was installed. That one booted ok. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i doesn't load ext3-modules udeb on ia64
On Mon, Feb 09, 2004 at 12:54:48PM -0500, Joey Hess wrote: Richard Hirst wrote: This is the daily build for 20040208, netinst iso. sid_d-i or the probably broken other one? http://gluck.debian.org/cdimage/testing/sid_d-i/netinst/ia64/20040208/ Also, I selected a local mirror, it prompted with a path of /debian which I accepted. It then went and tried to access http:/debiandist/... I had to modify the suggested path to be /debian/ for to to work. Ok, fixed in CVS. Thanks Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229465: partman, command_set_flags() breaks if flags added to parted
Package: partman Version: 6 Tags: d-i command_set_flags() depends on PED_PARTITION_LAST_FLAG, and so it breaks if any extra flags are added to parted. I am working on adding a new parted flag to handle hppa boot partitions, and it would be nice if partman didn't need rebuilding to support it. The obvious solution is to loop calling ped_partition_flag_next() to determine how many flags there are, then malloc states[]. Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta2 sources.list config
On Mon, Jan 19, 2004 at 03:26:15AM -0600, Matthew A. Nicholson wrote: On two occasions during installations, when the installer gets to apt's sources.list configuration, it keeps asking for sources until the user presses cancel, at which time the installer will drop to expert mode. This is a known bug, fixed in cvs. Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i install report, hppa
On Mon, Jan 19, 2004 at 04:44:03PM +0100, Thorsten Sauter wrote: * Richard Hirst [EMAIL PROTECTED] [2004-01-18 20:48]: | Initial boot fails due to a SEGV in frontend; this appears to be because | of a bug in glibc, triggered by libm being reduced to what is effectively | an empty library. Bug #228375 filed. I hacked mklibs to include a symbol | from libm, so I could build a working image. text frontend worked ok. | | Kernel hung on reboot when discover tried to load de4x5.o; the kernel | has the tulip driver compiled in to handle the network i/f. I renamed | the module and tried again. This time it rebooted ok, and base-config | ran ok. very good news. mklibs is a little bit mystic for me. :-) Should I include this patch on paer as long as we have no updated mklibs version? Hmm, the patch is below, but I can't say whether you should hack /usr/bin/mklibs on paer. Carlos (hppa glibc guy) agrees that I found the bug in glibc, but he is fixing it in a slightly different way. I'd assumed that we would get a fixed glibc, rather than work round it in mklibs, but I guess a new mklibs is easier to arange. log was just a symbol I picked at random; the requirement is that objdump -p libm.so.6 shows a non-zero DT_JMPREL value. As log adds about 50K to libm, I suspect other archs would be upset by this mklibs change. Richard # doesn't hurt. I guess all archs can live with this. needed_symbols.add((sys_siglist, 1)) + # This is a hack to stop libm being reduced to nothing + # RGH. + needed_symbols.add((log, 1)) # calculate what symbols are present in small_libs present_symbols = Set() -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i install report, hppa
On Mon, Jan 19, 2004 at 08:35:11PM +0100, Thorsten Sauter wrote: * Richard Hirst [EMAIL PROTECTED] [2004-01-19 18:30]: | On Mon, Jan 19, 2004 at 04:44:03PM +0100, Thorsten Sauter wrote: | * Richard Hirst [EMAIL PROTECTED] [2004-01-18 20:48]: | | Initial boot fails due to a SEGV in frontend; this appears to be because | | of a bug in glibc, triggered by libm being reduced to what is effectively | | an empty library. Bug #228375 filed. I hacked mklibs to include a symbol | | from libm, so I could build a working image. text frontend worked ok. | | | | Kernel hung on reboot when discover tried to load de4x5.o; the kernel | | has the tulip driver compiled in to handle the network i/f. I renamed | | the module and tried again. This time it rebooted ok, and base-config | | ran ok. | | | very good news. | mklibs is a little bit mystic for me. :-) | | Should I include this patch on paer as long as we have no updated mklibs | version? | | Hmm, the patch is below, but I can't say whether you should hack | /usr/bin/mklibs on paer. Carlos (hppa glibc guy) agrees that I found | the bug in glibc, but he is fixing it in a slightly different way. I'd | assumed that we would get a fixed glibc, rather than work round it in | mklibs, but I guess a new mklibs is easier to arange. log was just a | symbol I picked at random; the requirement is that objdump -p libm.so.6 | shows a non-zero DT_JMPREL value. As log adds about 50K to libm, I | suspect other archs would be upset by this mklibs change. of course, not hacking the system mklibs binary, but I could use my own mklibs app as long as we have no fixed glibc and/or mklibs package. This will make the images working for this time. Sorry, misunderstood. Yes, that makes sense. Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i install report, hppa
INSTALL REPORT Debian-installer-version: cvs-head, 20040118, built locally uname -a: Date: Sun, 18 Jan 2004 19:28:45 + Method: netboot of lifimage (netboot-image.img), installing from local unstable mirror. Machine: B180L, Merlin L2+ 180 (9000/778/B180L) Processor: PA7300LC (PCX-L2) Memory: 256MB Root Device: SCSI Root Size/partition table: Disk /dev/sda: 4294 MB, 4294816768 bytes 133 heads, 62 sectors/track, 1017 cylinders Units = cylinders of 8246 * 512 = 4221952 bytes Device Boot Start End Blocks Id System /dev/sda1 1 8 32953 f0 Linux/PA-RISC boot /dev/sda2 9 245 977151 83 Linux /dev/sda3 246 306 251503 82 Linux swap Output of lspci: [EMAIL PROTECTED]:~$ lspci 00:13.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 04) 00:14.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) [EMAIL PROTECTED]:~$ lspci -n 00:13.0 Class 0100: 1000:000f (rev 04) 00:14.0 Class 0200: 1011:0019 (rev 30) [EMAIL PROTECTED]:~$ Base System Installation Checklist: Initial boot worked:[E] Configure network HW: [O] Config network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [E] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: Initial boot fails due to a SEGV in frontend; this appears to be because of a bug in glibc, triggered by libm being reduced to what is effectively an empty library. Bug #228375 filed. I hacked mklibs to include a symbol from libm, so I could build a working image. text frontend worked ok. Kernel hung on reboot when discover tried to load de4x5.o; the kernel has the tulip driver compiled in to handle the network i/f. I renamed the module and tried again. This time it rebooted ok, and base-config ran ok. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
PA-RISC/HPPA netboot lifimage generation
On Sat, Jan 10, 2004 at 07:23:39PM +0100, Thorsten Sauter wrote: * Richard Hirst [EMAIL PROTECTED] [2004-01-10 17:51]: | The SEGV is in frontend, looks like a null pointer deref. I switched | to text frontend, fixed d-i to actually make a lifimage for netboot (I | guess you created yours manually?), and tried again. I havn't submitted | my change yet. I have created a new target in boot/arch/linux-hppa caled netboot.lif. But I haven't commited it yet. I'm not sure, that this is the right place. I created a 2 line file, build/config/type/netboot-hppa containing # FLOPPY_SIZE value is not relevant, but it needs to exist so that palo gets run FLOPPY_SIZE=1440 After that, make TYPE=netboot produces a lifimage, from the existing $(IMAGE) target in make/arch/linux-hppa. Output is dest/netboot-image.img Thorsten, shall I submit this, or will it interfere with what you are doing? Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ia64 beta2 install report
Tested both netinst and businesscard ISOs, on i2000 prototype (dual Itanium). Both worked fine. Only issues, which are already known are: elilo udeb works but is English only and spews some unwanted text to the screen. Will be fixed in the next upload. Installed kernel gives sc() messages for unimplmented syscalls. Works fine, but is noisy. Will be fixed when new kernel debs make their way in to testing. Current solution is to install a newer kernel from unstable. apt config after booting requires you to hit cancel to get out of the add apt source screen. I think after adding the first one, it should give you a do you want to add another screen. ISO doesn't autoboot because I got the dir structure wrong. Have to select the relevant device and type 'elilo'. Can't install from USB. Could do with some unaligned access warnings cleaning up. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia64 beta2 install report
On Fri, Jan 16, 2004 at 12:09:00PM -0500, Joey Hess wrote: Richard Hirst wrote: apt config after booting requires you to hit cancel to get out of the add apt source screen. I think after adding the first one, it should give you a do you want to add another screen. This is not specific to the ia64 port. I think I have fixed the logic error in apt-setup, but I have still not managed to test it satesfactorally. I replaced the base-config deb on an ia64 beta2 netinst ISO with one built from cvs a few hours ago and did a test install. Now it gives me the choose an apt source screen, I select http, and a local mirror, it loads package files from my mirror and from security.d.o, and then goes directly to the install software screen (offering tasksel, aptitude, etc). So it does indeed seem to be fixed. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#227114: 20040108 fails on ia64
On Wed, Jan 14, 2004 at 11:23:49PM +, Richard Hirst wrote: Ugh, ignore my recent post saying networking wasn't configured after installing from the 20040111 netinst iso. What has actually happened, is that the installed system has a /etc/network/interfaces file containing: cut == auto lo iface lo inet loopback # This entry was created during the Debian installation auto eth0 iface eth0 inet dhcp on. cut == If I run /etc/init.d/netowrking start, I get an error about an option with an empty value on line 7. If I delete that line netowrking comes up ok. I've no idea atm where the on. comes from. Looks like that is down to the busybox, cp doesn't truncate target file bug I saw mentioned in the last few days. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#227114: 20040108 fails on ia64
On Tue, Jan 13, 2004 at 02:39:47PM -0500, Joey Hess wrote: Richard Hirst wrote: The problem is that initrd-tools is not included on the netinst ISO. The kernel doesn't depend on it, so that is correct. Unfortunately on ia64 we have do_initrd=yes so kernel-installer wants to install initrd-tools. Not a problem with the businesscard ISO because it just pulls initrd-tools from the net. I belive that I have checked in a fix to debian-cd's tools/generate_di+k_list to fix this. Manty will need to cvs up that file in his build tree. Thanks Joey. d-i manages to install a kernel then, but elilo-installer causes (at least) one of my scsi disks to run down, and report 'Not Ready'. I have two disks, sda (8/0) and sdb (8/16). The errors are on sdb, which I'm not installing to. elilo runs parted /dev/discs/discN/disc print | sed when translating /dev/discs/ paths in to /dev/scsi/ paths. Earlier in the install (partitioning disks) I was able to use parted to print the partition table ok. I havn't seen this problem with the businesscard ISOs, but the most recent I tested so far was 20040108. The ia64 udebs on the netinst CD you used have not been updated since then, so I don't know about this. I'm putting this scsi error problem down to dying hardware. I went back to the 20040108 iso that I'm previously used, and am getting similar (and worse) symptoms, only on one of the two disks. So, I still think ia64 d-i is ok for beta2, assuming initrd-tools gets included on the netinst ISO. No new ISOs generated since 20040111 though. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#227114: 20040108 fails on ia64
On Wed, Jan 14, 2004 at 09:39:02PM +, Richard Hirst wrote: I'm putting this scsi error problem down to dying hardware. I went back to the 20040108 iso that I'm previously used, and am getting similar (and worse) symptoms, only on one of the two disks. Ripped the box apart, blew the dust out, etc, reassembled, and installed from the 20040111 netinst iso with no problems except for initrd-tools workaround. However, d-i never did network configuration, and on reboot base-config didn't either, so I had no networking :( Richard So, I still think ia64 d-i is ok for beta2, assuming initrd-tools gets included on the netinst ISO. No new ISOs generated since 20040111 though. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#227114: 20040108 fails on ia64
Ugh, ignore my recent post saying networking wasn't configured after installing from the 20040111 netinst iso. What has actually happened, is that the installed system has a /etc/network/interfaces file containing: cut == auto lo iface lo inet loopback # This entry was created during the Debian installation auto eth0 iface eth0 inet dhcp on. cut == If I run /etc/init.d/netowrking start, I get an error about an option with an empty value on line 7. If I delete that line netowrking comes up ok. I've no idea atm where the on. comes from. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#227114: 20040108 fails on ia64
Hi Alex, Thanks for your report, comments below.. On Fri, Jan 09, 2004 at 02:30:26PM -0700, Alex Williamson wrote: Package: installation-reports Version: 20040108-ia64 Severity: grave Justification: renders package unusable Debian-installer-version: http://people.debian.org/~manty/testing/netinst/ia64/20040108/sarge-ia64-netinst.iso uname -a: 2.4.20-ia64 #1 Mon Jan 5 07:53:11 GMT 2004 ia64 Date: Fri, 09 Jan 2004 13:50:04 -0700 Method: USB Keychain and IDE CDROM Machine: hp rx2600 Processor: 2x Itanium2 Memory: 6GB Root Device: SCSI sda Root Size/partition table: GPT 100MB fat16 (not mounted), ~30G ext3 (/), ~2G swap Output of lspci: Not available Base System Installation Checklist: Initial boot worked:[E] - failed to autoboot. manually running bootloader worked OK, I'll fix the directory layout after beta2. Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [E] - failed to load from USB mass storage, worked fine from CD I havn't tried to use usb at all on my box. Hopefully Dannf's new kernel packages (2.4.22 or 23) will provide that module, and I plan on adopting those after beta2. Will have to ensure those modules get included in the initrd. Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[E] - Never got there, couldn't get a kernel installed This is odd. I have the buisnesscard iso here, and it lists 8 kernels, not 4 as you got from the netinst iso. It lists images for itanium and mckinley, smp and up, for 2.4.19 and 2.4.20. I wonder if there is something missing from the netinst iso. The latest ISOs are now on gluck; I'm currently downloading http://gluck.debian.org/cdimage/testing/netinst/ia64/20040111/sarge-ia64-netinst.iso and will see what that does for me. In the meantime, if you are bored, you might try the latest buisnesscard ISO (from http://gluck.debian.org/cdimage/testing/netinst/ia64). Something else that may not be obvious; when you partition the target disk you need to use parted to create a FAT16 filesystem on the boot partition, and set the BOOT flag (set N boot on). Thanks, Richard Reboot: [ ] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: I was hoping to do an install off of a USB keychain. I'm using a 256MB keychain, partitioned as GPT with a 100MB fat16 partition, and the rest ext3. I copied the contents of the el-torito image into the fat16 partition and the rest of the CD into the ext3 partition. The system failed to autoboot when I selected USB for install (the directory and filename layouts are incorrect for autoboot). I then went to an EFI Shell and booted manually by typing elilo (I'm using a VGA console for install). Install went fine till it started looking for a CD. I got it to look for the install media elsewhere, but it got an error that the usb-storage module wasn't available. I gave up on the USB keychain and popped in a CD. In the processes of installing the base system, I got some unaligned access errors on the console. These were mainly from main-menu and anna. Really ought to fix these, use prctl to turn them off or maybe just turn down the dmesg level to make them not go to the console. I got the base system installed and selected the install kernel option. It presented a list of 4 available kernels. Selecting any of them immediately brought me back to the main menu w/ the install kernel option highlighted. I checked the /target drive, and no kernel was installed. I tried this several times before I gave up. I have some concerns about using devfs for the install. I'm told that after install you will not end up with a devfs system, but I couldn't get that far to verify. It's confusing to be presented with SCSI devices as host/bus/target/lun when you're really just expecting sda. I'm aware of all the naming problems with sdX, but using a deprecated interface doesn't seem like the way to work around it. My 2 cents. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daily images for PA-RISC/HPPA
On Fri, Jan 09, 2004 at 08:21:17AM +0100, Thorsten Sauter wrote: Hello debian-installer's :-), I have setup daily images for the HPPA architecture on paer.debian.org. The images creates cdrom, netboot and a lif image from source. As usually everything is available here: http://people.debian.org/~tsauter/d-i/images-hppa/daily/ I hope, we can build daily cdrom images as well. I have tested the images on the following machine types (always tftpboot via lif image): 9000/712-60 and 9000/712-80. Please test the images. netboot.lif seems to have a rather strange cmdline: TERM=linux console=tty initrd=netboot-initrd.gz ramdisk_size=8192 root=/dev/rd/0 initrd=0/linuxrc devfs=mount,all rw I couldn't find initrd=0/linuxrc anywhwere in the d-i source. The crdom-image.img seems to have a more sane cmdline, but I still had to use palo to edit it to add root=/dev/ram devfs=mount,dall before it would get anywhere. I had to remove TERM=linux as well, because palo locked up if I included all those params. palo has a history of locking up when you edit the cmdline, unfortunately. Anyway, after that, it booted and mounted the initrd, and then looped complaining that it couldn't find various kernel modules, and reporting 'segmentation fault'. This was on a B180, STI console. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daily images for PA-RISC/HPPA
On Sat, Jan 10, 2004 at 01:17:56PM +, Richard Hirst wrote: On Fri, Jan 09, 2004 at 08:21:17AM +0100, Thorsten Sauter wrote: Hello debian-installer's :-), I have setup daily images for the HPPA architecture on paer.debian.org. The images creates cdrom, netboot and a lif image from source. As usually everything is available here: http://people.debian.org/~tsauter/d-i/images-hppa/daily/ I hope, we can build daily cdrom images as well. I have tested the images on the following machine types (always tftpboot via lif image): 9000/712-60 and 9000/712-80. Please test the images. netboot.lif seems to have a rather strange cmdline: TERM=linux console=tty initrd=netboot-initrd.gz ramdisk_size=8192 root=/dev/rd/0 initrd=0/linuxrc devfs=mount,all rw I couldn't find initrd=0/linuxrc anywhwere in the d-i source. The crdom-image.img seems to have a more sane cmdline, but I still had to use palo to edit it to add root=/dev/ram devfs=mount,dall before it would get anywhere. I had to remove TERM=linux as well, because palo locked up if I included all those params. palo has a history of locking up when you edit the cmdline, unfortunately. Anyway, after that, it booted and mounted the initrd, and then looped complaining that it couldn't find various kernel modules, and reporting 'segmentation fault'. This was on a B180, STI console. The SEGV is in frontend, looks like a null pointer deref. I switched to text frontend, fixed d-i to actually make a lifimage for netboot (I guess you created yours manually?), and tried again. I havn't submitted my change yet. Getting further now, currently running debootstrap, installing unstable. Couldn't partition disks because there is no [c]fdisk udeb installed. parted won't work for hppa because we need to create a partition of type 'F0' and parted can't do that. I skipped that step and used my existing partitions. IIRC this is a problem with fdisk-udeb priority. It gets pulled in on i386 anyway because lilo-installer wants it (at least, that is what I recall), but doesn't get pulled in for hppa. I think the easy answer is to include it in the pkg-lists for hppa. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia64 install report
On Fri, Jan 09, 2004 at 06:58:48AM +0100, Christian Perrier wrote: I tried to find this tring in the beta2 tree, but I could not. Anyway, it appears to be a French translation that is wrongly encoded; d-i should only use utf-8. If you can grep out the relevant udeb in /var/lib/dpkg/info/, in the chroot, it should be easy to fix. The back-translation of this string is No boot partition detected, if that helps track it down. This only appears in sparc-installer and elilo-installer. Both french translations are originally coded in ISO-8859-15 as we usually do. Both package have the correct debian/po/output file so that translations are converted to UTF-8 when they are integrated in the templates. So, I have no idea where this may come from. It must be elilo-installer then. I'll try and figure it out. In any case, it doesn't cause a problem. Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia64 install report
On Thu, Jan 08, 2004 at 07:58:57PM -0500, Joey Hess wrote: Richard Hirst wrote: a) The iso has kernel-installer_0.045_all.udeb, even though 0.046 is in the archive. Presumably we are stuck with that until Joeyh forces 0.046 in to testing. As a result, it installed a 2.4.19 kernel for Itanium, rather than choosing Itanium or Mckinley 2.4.20 based on /proc/cpuinfo. This is why I want manty to make some cds that use udebs from unstable, so we can test this stuff before moving it into testing. I understnad he's working on it. But a least during proparation for this beta it would probably be ok to just force it in, since the stuff in testing is not known to work at all. My list of packages that need to go into testing for ia64 is: Needs base-installer (0.046) in testing. Needs the kernel module udebs from kernel-patch-2.4.20-ia64 (021210.em20.7) in testing. If that is the full set, I will try to get them in before tomorrow's dinstall.. Yes, that is the full set, Thanks! Richard b) At some point during loading the installer modules, it spews a load of text over the screen, such as: Unknown localized field: Description-fr.ISO-8859-15: Aucune partition de dmarrage dtecte That doesn't seem to cause a problem though. I tried to find this tring in the beta2 tree, but I could not. Anyway, it appears to be a French translation that is wrongly encoded; d-i should only use utf-8. If you can grep out the relevant udeb in /var/lib/dpkg/info/, in the chroot, it should be easy to fix. I checked that the sym53c8xx_2 module jbailey wanted was available, so I think we can say ia64 is ready for beta2. Would be very nice if someone else could test though. That's great news. I am inclined to call beta2 as soon as we have two architectures ready. The other two or so architectures could then catch up and get their own release announcement. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia64 install report
On Thu, Jan 08, 2004 at 07:58:57PM -0500, Joey Hess wrote:
b) At some point during loading the installer modules, it spews a load
of text over the screen, such as:
Unknown localized field:
Description-fr.ISO-8859-15: Aucune partition de dmarrage dtecte
That doesn't seem to cause a problem though.
I ran a text mode install and logged the console:
[ 46.6%][ 46.6%] Unpacking e2fsprogs-udeb
[ 48.3%][ 48.3%] Retrieving libblkid1-udeb
[ 50.0%][ 50.0%] Unpacking libblkid1-udeb
[ 51.7%][ 51.7%] Retrieving libuuid1-udeb
[ 53.4%][ 53.4%] Unpacking libuuid1-udeb
[ 55.2%][ 55.2%] Retrieving elilo-installer
[ 56.9%][ 56.9%] Unpacking elilo-installer
Unknown localized field:
Description-cs.ISO-8859-2: Oblast pro instalaci zavadìèe:
Unknown localized field:
Description-da.ISO-8859-1: Partition at installere opstartsindlæseren på:
Unknown localized field:
Description-fr.ISO-8859-15: Partition où sera installé le chargeur de démarrage :
Unknown localized field:
Description-hu.ISO-8859-2: A rendszerbetöltõ erre a partícióra kerül:
Unknown localized field:
Description-ja.EUC-JP: ¥Ö¡¼¥È¥í¡¼¥À¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó:
Unknown localized field:
Description-pt_BR.ISO-8859-1: Partição a ser usada para a instalação do carregador de
inicialização :
Unknown localized field:
Description-cs.ISO-8859-2: Nebyly detekovány ¾ádné oblasti
Unknown localized field:
Description-da.ISO-8859-1: Fandt ingen opstartspartitioner
Unknown localized field:
Description-fr.ISO-8859-15: Aucune partition de démarrage détectée
Unknown localized field:
Description-hu.ISO-8859-2: Rendszerbetöltõ partíció felderítése sikertelen
Unknown localized field:
Description-ja.EUC-JP: ¥Ö¡¼¥È¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤¬¸¡½Ð¤µ¤ì¤Þ¤»¤ó¤Ç¤·¤¿
Unknown localized field:
Description-pt_BR.ISO-8859-1: Nenhuma partição de inicialização (boot) detectada.
[ 58.6%][ 58.6%] Retrieving userdevfs
...
...
I then extracted the templates files from base-installer and elilo-installer
to see if there were any obvious differences:
base-installer:
Template: base-installer/debootstrap-failed
Type: error
Description: Failed to install the base system
The base system installation into /target/ failed.
.
Please check /target/var/log/debootstrap.log and
/target/var/log/debootstrap.err.log for the details.
Description-bg.UTF-8: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] на
оÑ~AновнаÑ~Bа Ñ~AиÑ~AÑ~Bема
[EMAIL PROTECTED] на оÑ~AновнаÑ~Bа Ñ~AиÑ~AÑ~Bема в
/target/ [EMAIL PROTECTED] неÑ~CÑ~AпеÑ~Hно.
.
Ð~\олÑ~O [EMAIL PROTECTED]@еÑ~Bе /target/var/log/debootstrap.log и
/target/var/log/debootstrap.err.log за [EMAIL PROTECTED]
...
...
elilo-installer:
Template: elilo-installer/bootpart
Type: select
Choices: ${BOOTPARTS}
Description: Partition for boot loader installation:
Partitions currently available in your system are listed.
Please choose the one you want elilo to use to boot Debian.
Description-cs.ISO-8859-2: Oblast pro instalaci zavadìèe:
Vypsány jsou v¹echy dostupné oblasti v systému. Vyberte tu, kterou má
elilo pou¾ít k zavedení Debianu.
...
...
The obvious difference to me is that in base-installer, all the
Description names are Description-*.UTF-8, while in elilo-installer they
are all .ISO-8859-2, or EUC-JP, or whatever.
I then built a new elilo-installer from head, and its templates file
uses UTF-8, so I conclude that we should build/upload a new
elilo-installer. So far as beta2 is concerned, I tried an install in
French, and all was well, except the one dialog from elilo was in
English. I guess we can live with that for now.
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ia64 install report
INSTALL REPORT Debian-installer-version: http://people.debian.org/~manty/testing/netinst/ia64/daily/sarge-ia64-businesscard.iso dated 08-JAN-2004 15:02 uname -a: Date: Jan 8th 2004, 23:20 GMT Method: businesscard.iso, specified 'testing', local http mirror Machine: HP i2000 proto Processor: Itanium (dual) Memory: 1G Root Device: SCSI Root Size/partition table: 100MB FAT16 for EFI, 1990MB ext3 for '/'. Output of lspci: Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: Two issues: a) The iso has kernel-installer_0.045_all.udeb, even though 0.046 is in the archive. Presumably we are stuck with that until Joeyh forces 0.046 in to testing. As a result, it installed a 2.4.19 kernel for Itanium, rather than choosing Itanium or Mckinley 2.4.20 based on /proc/cpuinfo. b) At some point during loading the installer modules, it spews a load of text over the screen, such as: Unknown localized field: Description-fr.ISO-8859-15: Aucune partition de dmarrage dtecte That doesn't seem to cause a problem though. I checked that the sym53c8xx_2 module jbailey wanted was available, so I think we can say ia64 is ready for beta2. Would be very nice if someone else could test though. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i ia64 install report, with patch
Using: p.d.o/~manty/testing/netinst/ia64/20040103/sarge-ia64-buisnesscard.iso dated 02-JAN-2004 15:02 Still doesn't automatically load ide-probe-mod.o, but joeyh has that change queued waiting for alioth to come back, I believe. That meant I had to mess about a bit to get the cdrom visible. The fixed parted ia64 build had not made it in to archive for this iso. /etc/resolv.conf was set up correctly this time. I was able to install testing this time (previously debootstrap meant I had to install unstable). I hand-editted kernel-installer.postinst before it was run, to make it choose an appropriate kernel for the hardware (patch below). That made it load a 2.4.20 kernel which is better than the 2.4.19 it used before. However, it loaded the 2.4.20 kernel in testing (obviously), which is a couple of revisions older than the one in unstable, and spews messages about unimplemented syscalls up the screen (still works, but annoying). The 2.4.20 kernel udebs work fine for my h/w, but we need the new packages for people with other scsi cards. So, this is what we need for ia64 to be widely useful: 1. Fixed parted in the archive and udeb on the iso - presumably that will happen today 2. hw-detect fixed to modprobe ide-probe-mod (joeyh?) 3. new 2.4.20 kernel udebs with extra scsi driver modules (bdale/dannf?) 4. newer 2.4.20 kernel debs in testing would be nice, but not vital 5. the following patch applied to kernel-installer. I havn't got round to getting cvs access on alioth yet, so maybe once it is back someone could apply this for me, and upload a new kernel-installer? Thanks, Richard --- base-installer-0.045/debian/kernel-installer.postinst- 2004-01-03 21:11:09.0 + +++ base-installer-0.045/debian/kernel-installer.postinst 2004-01-03 21:16:05.0 + @@ -186,6 +186,17 @@ *) log warning: Unknown $ARCH subarchitecture '$MODEL'. ;; esac ;; +ia64) + version=2.4.20 #hack, hack! + # Running a UP kernel for install atm, so don't know how to detect + # whether SMP is needed. Assume SMP for now. + if grep -q Itanium /proc/cpuinfo; then + family=itanium + else + family=mckinley + fi + trykernel=kernel-image-$version-$family-smp + ;; *) log warning: Unknown architecture '$ARCH'. ;; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i ia64 install report, with patch
On Sat, Jan 03, 2004 at 03:24:20PM -0900, Joey Hess wrote: Richard Hirst wrote: Still doesn't automatically load ide-probe-mod.o, but joeyh has that change queued waiting for alioth to come back, I believe. That meant I had to mess about a bit to get the cdrom visible. I'm waiting until i386 is frozen in testing before uploading that, just because it could cause ugly error messages or something on i386. So, this is what we need for ia64 to be widely useful: 1. Fixed parted in the archive and udeb on the iso - presumably that will happen today 2. hw-detect fixed to modprobe ide-probe-mod (joeyh?) 3. new 2.4.20 kernel udebs with extra scsi driver modules (bdale/dannf?) 4. newer 2.4.20 kernel debs in testing would be nice, but not vital 5. the following patch applied to kernel-installer. I havn't got round to getting cvs access on alioth yet, so maybe once it is back someone could apply this for me, and upload a new kernel-installer? This sounds suspiciously close the the date estimates I asked for regarding when each architecture will be ready for the beta. FWIW, I have received no estimates at all so far. Would you guys like to make one? Tricky... take the latest of i386 frozen in testing alioth back up new kernel pkgs uploaded then allow, say, three days to get ide-probe-mod and kernel-installer changes uploaded, new d-i build, new iso, quick test. I can't really speak for when the kernel pkgs will be done, as I don't know what Bdales commitments are. I'd hope we would be ready within a week though, which falls within your 10th-14th Jan proposal. --- base-installer-0.045/debian/kernel-installer.postinst- 2004-01-03 21:11:09.0 + +++ base-installer-0.045/debian/kernel-installer.postinst 2004-01-03 21:16:05.0 + I'd apply this if alioth were back up yet. I forget, do you have commit access on alioth? Not atm. I had commit access before the move to alioth, but alioth has been down since I found time to look at d-i again. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i ia64 install report
On Wed, Dec 31, 2003 at 06:46:24PM -0500, Joey Hess wrote: Richard Hirst wrote: parted seems to be broken. It doesn't seem able to create filesystems anymore. Havn't looked in to this yet, but mkpartfs pri ext2 1000 2000 just returns to the prompt without apparently doing anything. Need to look in to this a bit more and file bug. I've been hearing murmerings about parted for a few days, is this a more widespread problem? There was a new version uploaded recently. Serious bug filed on parted 1.6.6-2; the new amiga fs support breaks all filesystem creation. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i ia64 install report
On Thu, Jan 01, 2004 at 01:10:53PM -0500, Joey Hess wrote: Richard Hirst wrote: On Wed, Dec 31, 2003 at 06:46:24PM -0500, Joey Hess wrote: Richard Hirst wrote: parted seems to be broken. It doesn't seem able to create filesystems anymore. Havn't looked in to this yet, but mkpartfs pri ext2 1000 2000 just returns to the prompt without apparently doing anything. Need to look in to this a bit more and file bug. I've been hearing murmerings about parted for a few days, is this a more widespread problem? There was a new version uploaded recently. Serious bug filed on parted 1.6.6-2; the new amiga fs support breaks all filesystem creation. Is this specific to ia64, or is it also breaking i386? I see no reason why it would be ia64 specific. I assume it is no longer possible to create filesystems with parted on any arch. d-i will of course create filesystems for you, for ext[23], so the fact that parted can't currently create an fs isn't fatal for i386. It is fatal for ia64 because we rely on parted to create the FAT boot partition filesystem. parted can still create partitions, it just can't create filesystems within those partitions. mkpart works, mkpartfs and mkfs don't. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installation Report (failure)
On Thu, Jan 01, 2004 at 03:50:35PM -0500, Joey Hess wrote: Erich Waelde wrote: New year, new images, new luck, new exciting features: used image from ~manty: sarge-i386-netinst-20031231.iso (2003-12-31 17:00) 2c806ec1e53ac891b431ab0a6a84bfab Everything works fine until Installation of Basesystem installation returned Error 127 tail /target/var/log/debootstrap.log Errors were encountered while processing: libgnutls7 exim4-daemon-light mailx at exim4 This will be fixed in approximatly 1.5 hours. HOWEVER: /target/bin/sleep is available and chroot /target sleep 2 exit works. So cp /target/bin/sleep /bin cp /target/lib/librt* /lib sleep 2 now works as well I've never tried to work out what is trying to call sleep where and fix it; it only happens on error anyway. It is debootstrap, in file 'functions', in repeat() We should take that sleep out, or add sleep to busybox - people keep assuming that their install failed because 'sleep' wasn't found. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#225823: mklibs 0.1.13 fails on ia64
Package: mklibs Version: 0.1.13 tags: d-i Trying to build debian-installer-20031230: ... ... Object: ./tmp/cdrom/tree/lib/libm.so.6.1-so-stripped Object: ./tmp/cdrom/tree/lib/libdebconfclient.so.0-so-stripped Object: ./tmp/cdrom/tree/lib/libslang.so.1-UTF8-so-stripped Object: ./tmp/cdrom/tree/lib/ld-linux-ia64.so.2-so-stripped 557 symbols, 20 unresolved Moving libresolv.so.2 to libresolv.so.2. Unlinking libnss_dns.so.2. Moving libtextwrap.so.1 to libtextwrap.so.1. Moving libdebian-installer.so.4 to libdebian-installer.so.4. Moving libresolv-2.3.2.so to libresolv.so.2. Moving libnss_dns-2.3.2.so to libnss_dns.so.2. Moving libdiscover.so.1 to libdiscover.so.1. Moving libc.so.6.1 to libc.so.6.1. Unlinking libdiscover.so. Moving ld-linux-ia64.so.2 to ld-linux-ia64.so.2. Moving libnewt.so.0.51 to libnewt.so.0.51. Moving libdl.so.2 to libdl.so.2. Moving libm.so.6.1 to libm.so.6.1. Moving libdebconfclient.so.0 to libdebconfclient.so.0. Moving libdiscover.so.1.0.0 to libdiscover.so.1. Command failed with status 1 : objcopy --strip-unneeded -R .note -R .comment ./tmp/cdrom/tree/lib/ With output: objcopy: ./tmp/cdrom/tree/lib/: File format not recognized make[2]: *** [cdrom-tree-stamp] Error 1 make[2]: Leaving directory `/root/debian-installer-20031230' make[1]: *** [all_images] Error 2 make[1]: Leaving directory `/root/debian-installer-20031230' make: *** [build-stamp] Error 2 chilly:~/debian-installer-20031230# Looking at the end of mklibs.py: # Canonicalize library names. for lib in regexpfilter(os.listdir(dest_path), (.*so[.\d]*)$).elems(): lib_path = dest_path + / + lib if os.path.islink(lib_path): debug(DEBUG_VERBOSE, Unlinking %s. % lib) os.remove(lib_path) continue soname = extract_soname(lib_path) if soname: debug(DEBUG_VERBOSE, Moving %s to %s. % (lib, soname)) os.rename(dest_path + / + lib, dest_path + / + soname) # Make sure the dynamic linker is present and is executable ld_file = find_lib(ldlib) ld_file_name = os.path.basename(ld_file) if not os.access(dest_path + / + lib, os.F_OK): command(target + objcopy, --strip-unneeded -R .note -R .comment, ld_file, dest_path + / + ld_file_name) os.chmod(dest_path + / + ld_file_name, 0755) That for-loop corrupts global lib_path, which makes find_lib() fail. That if not os.access(... line is testing for 'lib' which never exists as it just moved it. I believe it should be using ldlib: - if not os.access(dest_path + / + lib, os.F_OK): + if not os.access(dest_path + / + ldlib, os.F_OK): Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i ia64 install report
This is using the daily build sarge-ia64-buisnesscard.iso, dated 30-DEC-2003 11:02. Installing sarge didn't work, because it doesn't have the newest debootstrap, so I used it to install sid. This is the first time I've tried d-i for a few weeks, and some things have broken in the meantime. Issues: Some char-set issue on language selection, top line has '?', at least. Didn't see this problem before. Failed to detect my cdrom (ide), because it never loaded ide-probe-mod.o I have to manually modprobe that before d-i loaded the other kernel modules for cdrom detection to work. If I modprobed it after d-i failed to detect the cd, I then had to manually mknod /dev/cdrom b 3 0 and tell d-i to use that. Didn't see this problem before. dhcp network config got an ip address ok, but failed to fill in /etc/resolv.conf, so it couldn't resolve names. Had to give ip addr for my local mirror. Didn't see this problem before. Auto kernel selection picked 2.4.19, although there are newer ones available. We need code to detect the appropraite one for the h/w really (smp, itanium, mckinley), and a more recent version. May be problems going for the most recent though, as that has switched to everything modular, and booting via an initrd. Don't know if elilo setup will need some tweeks for that. elilo failed to run because I didn't have a vaild boot partition with a FAT filesystem on it already on the disk. Had to run elilo manually with --format, or mkdosfs first (after chroot-ing to /target). The right way to get round that is to use parted to make a fat32 filesystem on the boot partition when creating it, but: parted seems to be broken. It doesn't seem able to create filesystems anymore. Havn't looked in to this yet, but mkpartfs pri ext2 1000 2000 just returns to the prompt without apparently doing anything. Need to look in to this a bit more and file bug. jbailey has hit problems on his box because the 2.4.20 kernel we boot doesn't have include a module for the 53c1030. Now dannf has done the ia64 work of getting initrd based booting to work, with everything modular, I think we really should switch to using his 2.4.22 kernels for d-i, and installing that kernel. That might require some elilo setup fixes. I see the autobuild of d-i fails, re QM_MODULES. IIRC that was a glibc problem, and I thought it was fixed. I'm a bit out of touch with d-i, so it may be some of these issues are known/inhand. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i ia64 install report
On Wed, Dec 31, 2003 at 06:46:24PM -0500, Joey Hess wrote: Richard Hirst wrote: Installing sarge didn't work, because it doesn't have the newest debootstrap, so I used it to install sid. This is the first time I've tried d-i for a few weeks, and some things have broken in the meantime. d-i is supposed to use debootstrap-udeb, which as a udeb is not in testing (but just symlined to it along with all the others). So I don't understand what you mean by the above. Is it possible debootstrap-udeb 0.2.21 has not yet been compiled for ia64? I think the sid script already pulled in libacl/libattr, while the sarge script didn't. 0.2.21 fixed the sarge script to pull in those libs too. So, using an older debootstrap worked for sid, but not sarge. 0.2.21 is compiled for ia64, but I guess it just didn't make that iso build. I'm assuming the debootstrap udeb comes off the iso, not from the archive.. I've been hearing murmerings about parted for a few days, is this a more widespread problem? There was a new version uploaded recently. I'll try and look closer tomorrow. jbailey has hit problems on his box because the 2.4.20 kernel we boot doesn't have include a module for the 53c1030. I understand that Bdale is in the process of fixing this. Of course it requires a kernel rebuild and, apparently, a marge. Sigh. Good to hear; I'm a bit out of touch atm. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: architectures status
On Tue, Dec 09, 2003 at 04:53:10PM -0500, Joey Hess wrote: If you're involved in a d-i port, please write back and tell me what the current status is (boots to main menu, some successful installs, whatever), and what you expect the status to be in approximatly 2 weeks. I've been working on ia64, and to some extent parisc. Unfortunatey real work means I wont do anything else significant on either in the next few weeks. parisc worked quite well on my test box (B180) last time I tried, but that was maybea couple of months ago. ia64 builds - Jeff Bailey builds from CVS every day - but I don't know how well the resulting images work ATM. It is certainly possible that they work well enough to release, but someone with some more time than me needs to test them. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to debian-installer/libdebian-installer/src by waldi
On Tue, Nov 18, 2003 at 06:49:32AM +0100, Bastian Blank wrote: On Fri, Nov 14, 2003 at 07:26:21PM +, Richard Hirst wrote: Havn't looked closely at this code, but that struct looks like it will end up generating lots of unaligned access traps on ia64, as mem[] will be on a 4 rather than 8 byte binary. please explain why the size of size_t is 4 bytes on your ia64, any ia64 machine i know have 8 byte. Sorry for the noise.. I see that s/di_ksize_t/size_t/ was done to fix this problem. I'm a little confused, because I thought this allocation stuff had been ripped out in favour of plain malloc(). Not yet, as someone break make demo and therefor the debugging facility. OK, thanks. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to debian-installer/libdebian-installer/src by waldi
On Thu, Nov 13, 2003 at 02:29:00PM -0700, [EMAIL PROTECTED] wrote:
Update of /cvs/debian-boot/debian-installer/libdebian-installer/src
In directory gluck:/tmp/cvs-serv10695/src
Modified Files:
Makefile.am exec.c hash.c mem.c packages.c parser_rfc822.c
string.c
Added Files:
mem_chunk.c
Log Message:
- cleanup includes
- make code more modular
--- NEW FILE: mem_chunk.c ---
...
struct di_mem_area
{
di_mem_area *next; /** the next mem area */
di_mem_area *prev; /** the previous mem area */
size_t index;/** the current index into the mem array */
size_t free; /** the number of free bytes in this mem area */
size_t allocated;/** the number of atoms allocated from this area */
char mem[MEM_AREA_SIZE]; /** the mem array from which atoms get allocated
* the actual size of this array is determined by
* the mem chunk area_size. ANSI says that it
* must be declared to be the maximum size it
* can possibly be (even though the actual size
* may be less).
*/
};
Havn't looked closely at this code, but that struct looks like it will
end up generating lots of unaligned access traps on ia64, as mem[] will
be on a 4 rather than 8 byte binary. I'm a little confused, because I
thought this allocation stuff had been ripped out in favour of plain
malloc().
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer images failing on ia64 autobuilder
On Sun, Nov 09, 2003 at 11:07:28PM -0500, Joey Hess wrote: Joey Hess wrote: Joey Hess wrote: The following packages have unmet dependencies: debootstrap-udeb: Depends: mounted-partitions I see Richard Hirst fixed this, so never mind. Nope, spoke too soon, it's still failing on ia64: http://buildd.debian.org/fetch.php?pkg=debian-installerver=20031109arch=ia64stamp=1068431608file=logas=raw mkfs.msdos -i deb1 -n Debian Inst -C dest/cdrom-image.img.new 8192 /bin/sh: line 1: mkfs.msdos: command not found Well at least the error is different this time. Is this a missing build-dep for ia64? Yes, just added mtools for ia64. It nearly completed the build that time :) Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer images failing on ia64 autobuilder
On Sun, Nov 09, 2003 at 11:07:28PM -0500, Joey Hess wrote: Joey Hess wrote: Joey Hess wrote: The following packages have unmet dependencies: debootstrap-udeb: Depends: mounted-partitions I see Richard Hirst fixed this, so never mind. Nope, spoke too soon, it's still failing on ia64: http://buildd.debian.org/fetch.php?pkg=debian-installerver=20031109arch=ia64stamp=1068431608file=logas=raw mkfs.msdos -i deb1 -n Debian Inst -C dest/cdrom-image.img.new 8192 /bin/sh: line 1: mkfs.msdos: command not found Well at least the error is different this time. Is this a missing build-dep for ia64? Well, mkfs.msdos comes from dosfstools, which you added, thanks. Next line of the script uses mcopy, which comes from mtools, hence my change. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ia64 install report
INSTALL REPORT Debian-installer-version: http://gluck.debian.org/cdimage/testing/netinst/ia64/daily/sarge-ia64-businesscard.iso Dated 07-Nov-2003 16:17 uname -a: Linux (none) 2.4.20-ia64 #1 Tue Oct 14 04:24:27 MDT 2003 ia64 unknown Date: Sat, 8 Nov 2003 11:40:08 + Method: cdrom boot, businesscard iso Machine: ia64 bigsur (i2000 proto) Processor: 2 off itanium-I @ 667MHz Memory: 1GB Root Device: SCSI Root Size/partition table: 2GB, /dev/sdb4, with /dev/sdb1 as efi boot partition. Output of lspci: Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [E] had to manually modprobe eepro100 Config network: [O] (dhcp) Detect CD: [O] Choose a mirror:[O] Load installer modules: [O] loaded from CD Detect hard drives: [O] Partition hard drives: [ ] parted ran ok, but I used existing partitions Create file systems:[O] Mount partitions: [O] Install base system:[O] Install the kernel: [O] Install boot loader:[O] Reboot: [O] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: Manually modprobing eepro100 is because ia64 doesn't have e100.o atm, and discover-data got changed to specify e100 recently. Bug 219513 filed, new kernel expected soon. Had to boot with TERM_UTF8=no to avoid issue where bterm dies with SIGILL. Not yet investigated or filed bug. hadn't seen that before as I'd been testing netboot, which doesn't use bterm. 'Detect hardware' seemed to cause main-menu to die, ps showed a main-menu in state Z, one in state S, and no menu displayed. Killed the frontend that was running and got main-menu redisplayed with 'Partition a harddrive' highlighted. Hadn't seen that with my local built netboots. Not investigated yet. Installed sid, because debootstrap is broken for sarge on ia64 (libreadlin4), bug 219655 filed. Would have liked to use a local mirror, but fix for that is not in this build. When Downloading packages the dialog box often (but not for all pkgs) says Validating %s. On reboot, console has lots of non-implemented syscall warnings as a result of the new glibc - bug 219512. So, still limping along a bit, unfortunately. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia64 install report
On Sat, Nov 08, 2003 at 12:00:04PM +, Richard Hirst wrote: Had to boot with TERM_UTF8=no to avoid issue where bterm dies with SIGILL. Not yet investigated or filed bug. hadn't seen that before as I'd been testing netboot, which doesn't use bterm. Actually, I think bterm just hangs, when I switch consoles to try and figure out what happened, bterm gets SIGILL. 'Detect hardware' seemed to cause main-menu to die, ps showed a main-menu in state Z, one in state S, and no menu displayed. Killed the frontend that was running and got main-menu redisplayed with 'Partition a harddrive' highlighted. Hadn't seen that with my local built netboots. Not investigated yet. Following 'Detect hardware', I'm left with a blue screen. Rather than switching consoles and killing processes, I can just hit ctrl-c to get back to main-menu. Running frontend detect-hw by itself doesn't seem to fail. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#219503: choose-mirror broken for manual entry
package: choose-mirror vesrion: cvs (0.21+) tags: d-i If you run choose-mirror and try to enter information manually, it doesn't work. Used to work until recently. The problem is in choose-mirror.c, where choose_country() ends with: country = strdup(debconf-value); debconf_set (debconf, DEBCONF_BASE country, country); Then in choose_mirror(), it does: manual_entry = ! strcmp(debconf-value, enter information manually); but by this time, debconf-value has been set to value set, so the compare always fails. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [powermac] installation report gluck image from october 31
On Sat, Nov 01, 2003 at 02:18:45AM +0100, Arnaud Vandyck wrote: Hi all! Many progress! Many thanks for the good job. Now the problems I faced: - debootstrap stopped with error code 127. I read the /target/var/log/debootstrap.log: ln: /target/usr/bin/awk: File exists So I deleted the symlink in a shell (I cannot go to another console :(), then exit and re-run install the base system. A lot of packages seem to have been installed but I got a debootstrap error code 1. In the log: Errors were encountered while processing: amiga-fdisk You need to look farther back in the log to see what the problem was processing amiga-fdisk. It's likely your install used a version of debootstrap that doesn't install libreadline4, which amiga-fdisk needs. libreadline4 was removed from debootstrap in a recent version, breaking m68k (since fixed, except libreadline4 is now included twice in sarge) and ia64 (bug filed). It seems it broke powerpc as well. /usr/sbin/debootstrap: 1: sleep: not found IIRC debootstrap uses sleep, but busybox-cvs doesn't provide it. Seems relatively harmless. Richard I'll try tomorrow (heu... well, later today ;)) with DEBCONF_PRIORITY=normal Cheers and many thanks for the good job! -- .''`. ** Debian GNU/Linux ** : :' : Arnaud Vandyck `. `' http://people.debian.org/~avdyk/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fdisk isn't getting installed
On Sat, Nov 01, 2003 at 10:01:49PM +0100, Goswin von Brederlow wrote: Hi, when trying out images on alpha today I noticed that fdisk is not getting installed. Two things can be done: 1. raise fdisks priority so anna installs it 2. have partitioner depend on it The 2. thing needs to happen but I think the first should also happen. Some other archs fdisks have priority standard and only fdisk-udeb has a lower one. Also on archs or setups without partitioner frontend you still need to partition your disk. Any objections against me fileing bugs against partitioner and fdisk to implement this? Sounds like this might help for hppa also, so that cfdisk gets installed automatically, see #213773. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215403: debconf_capb definition broken
package: cdebconf version: cvs debconfclient.h has #define debconf_capb(_client, _capb...) \ _client-command(_client, CAPB, ##_capb) which should probably have a , NULL included to match similar defines in that file. kbd-chooser gives SEGV on ia64, probably because of that missing NULL. - _client-command(_client, CAPB, ##_capb) + _client-command(_client, CAPB, ##_capb, NULL) Alternatively, things calling debconf_capb() need to include a NULL as the last arg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment
package: libdebian-installer
version: cvs
tags: d-i
di_mem_chunk_alloc() returns 4 byte aligned areas, even on 64 bit
platforms. This is bad, when the caller is going to lay some struct
containing longs or pointers over the alloc-ed memory. On ia64 it
results in loads of unaligned access exceptions flooding dmesg.
Alloc-ed memory comes from the mem[] array in the following struct
(from src/mem.c):
struct di_mem_area
{
di_mem_area *next; /** the next mem area */
di_mem_area *prev; /** the previous mem area */
di_ksize_t index;/** the current index into the mem array */
di_ksize_t free; /** the number of free bytes in this mem area */
di_ksize_t allocated;/** the number of atoms allocated from this area */
char mem[MEM_AREA_SIZE]; /** the mem array from which atoms get allocated
* the actual size of this array is determined by
* the mem chunk area_size. ANSI says that it
* must be declared to be the maximum size it
* can possibly be (even though the actual size
* may be less).
*/
};
given:
include/debian-installer/types.h:typedef uint32_t di_ksize_t
the above array comes out at 4 byte alignment.
We need to make mem[] aligned(MEM_ALIGN).
I also wonder about MEM_AREA_SIZE being hardwired at 4, although I
didn't dig in to the code far enough to see if it should be 8 on 64 bit
platforms.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215453: ddetect, bad pattern match on module search
package: ddetect
version: 0.44
tags: d-i
The following line from hw-detect.sh
if find /lib/modules/`uname -r`/ | grep -q ${module}\\.o
is broken. On ia64 we don't have floppy.o but we do have ide-floppy.o.
When trying to load the floppy module, the above grep matches
ide-floppy.o and consequently it does a modprobe floppy and throws up an
error dialog. Fix will be something like:
- if find /lib/modules/`uname -r`/ | grep -q ${module}\\.o
+ if find /lib/modules/`uname -r`/ | grep -q /${module}\\.o$
I'll file a seperate bug to get ddetect to probe for ide-floppy as well.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215455: ddetect needs to modprobe ide-floppy.o on ia64
package: ddetect version: 0.44 tags: d-i On ia64 we have ide-floppy.o, and not floppy.o. I'm not sure what the right way is to make ddetect modprobe ide-floppy.o... we could just add echo ide-probe-mod:Linux IDE probe Driver echo ide-detect:Linux IDE detection Driver + echo ide-floppy:Linux IDE Floppy Driver echo ide-disk:Linux ATA DISK Driver echo ide-cd:Linux ATAPI CD-ROM Driver echo isofs:Linux ISO 9660 Filesystem Driver #echo i82365:Linux Unknown to get_hw_info(), unless anyone has a better idea. Only drawback would appear to be that there will be a low priority prompt to load it from a floppy if you want the driver, on other archs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215448: di_mem_chunk_alloc() should return sizeof(long) or better alignment
On Sun, Oct 12, 2003 at 11:48:07PM +0200, Falk Hueffner wrote:
First, IMHO we should drop this stuff and just use malloc. I don't see
any point in increasing code size and introducing new bugs thereby.
Anyway:
struct di_mem_area
{
di_mem_area *next; /** the next mem area */
di_mem_area *prev; /** the previous mem area */
di_ksize_t index;/** the current index into the mem array */
di_ksize_t free; /** the number of free bytes in this mem area */
di_ksize_t allocated;/** the number of atoms allocated from this area */
char mem[MEM_AREA_SIZE]; /** the mem array from which atoms get allocated
* the actual size of this array is determined by
* the mem chunk area_size. ANSI says that it
* must be declared to be the maximum size it
* can possibly be (even though the actual size
* may be less).
*/
};
I also wonder about MEM_AREA_SIZE being hardwired at 4, although I
didn't dig in to the code far enough to see if it should be 8 on 64
bit platforms.
Just use long mem[] there, we can assume a C99 compiler, and it will
ensure alignment (at least for all Linux platforms).
Really? I thought the code later referenced something like
foo-mem[bar]
which will surely break if you just s/char/long/
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why kernel-image.udeb
On Sat, Oct 11, 2003 at 07:55:24PM +0200, Geert Stappers wrote: On Sat, Oct 11, 2003 at 07:06:02PM +0200, Steinar H. Gunderson wrote: Hi, The businesscard .iso is now about ~60MB, which probably won't even fit on most businesscard-sized CDs. Could somebody please answer: [several questions why the image is so large] I afford myself the luxury that some team member will answer. - Really, what do you need the kernel-image udebs for at all? That is where I can help. The d-i-boot-kernel does not has to be the base-config-boot-kernel, e.g. network boot, run d-i, reboot from harddisk and run base-config. It is the modular concept of Debian Installer. Do we really need kernel-image udebs on the iso? I can see that we might want some kernel module udebs. We might consider a kernel-image deb (not udeb), but I don't see the point, when it is supposed to be a _net_ install. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First HPPA test
On Sun, Oct 05, 2003 at 08:42:34PM +0200, Thorsten Sauter wrote: Hi all, Yesterday, I have tried to install a fresh Debian system on my hppa 712/60 using the new debian-installer. Attached are my notes about this process. In short: most of the stuff is working, and you can using d-i on hppa. (debconf priority high) 1. kbd-chooser is in the mainmenu between (!) dhcp and static network configuration 2. kbd-chooser segfaults everytime (manually edited the status file) imho. if something does wrong tree time, it should never displayed to the user. 3. anna display cdrom-checker/cdrom-detect/network-ppp during a network installation. Hmmm. 4. anna, only display udebs with a menuitem. So I can't install any fdisk program (this makes partitioner unusable) There is a bug filed on that; problem is fdisk-udeb is priority extra. Don't know what the answer is. 5. the hardware detection always told me, I need more modules (floppy, ide, isofs, ...) But everything is alread in the kernel 6. palo-installer doesn't make the disc-bootable. Has worked for me, although it seems to report the standard verbose palo output as 'error ouput'. Richard Hardware: PA-RISC/HPPA 712/60, 32MB RAM, 60MHz :) Notes: I have created an new lif image (which contains both 32 and 64 bit kernels). Boot method was netboot (dhcp/tftp). Bye Thorsten -- Thorsten Sauter [EMAIL PROTECTED] (Is there life after /sbin/halt -p?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia64 testers wanted for sarge cds
Hi Khalid, On Mon, Oct 06, 2003 at 03:31:44PM -0600, Khalid Aziz wrote: I tried the netinstall CD image on an HP zx2000 and didn't get very far. Here are the two problems I saw that prevented me from going any further: 1. Selecting Detect a keyboard and select layout causes: An error or warning message was logged while running kbd-chooser SIGSEGV Was a problem with old kbd-chooser udeb. CVS works ok for me, not sure of current archive status. Note also I havn't tried on a usb k/b box, only on a bigsur with ps2 k/b. 2. Detect CDROM results in Unable to load module 'ide-probe-mod' for 'Linux IDE probe Driver'. Bug Bdale, waiting on new kernel udebs ;-) Bugs are filed with patches. See http://www.debian.org/devel/debian-installer/ports-status for what I had to do to make a working ia64 ISO a few days ago. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ia64 testers wanted for sarge cds
On Tue, Oct 07, 2003 at 11:07:18PM +0200, Santiago Garcia Mantinan wrote: Peter, please reply to the lists, I don't know a thing about ia64 and people on the lists can help us with this kind of things ;-) On Oct 07 2003, Peter Chubb wrote: Santiago == Santiago Garcia Mantinan [EMAIL PROTECTED] writes: Santiago to see if they boot, the installer is started, and if that The credit card image doesn't boot on I2000; it appears not to have a DOS EFI filesystem on it to boot off. So, what is this DOS EFI filesystem? Is it really needed? I mean, others have booted it, or are there several booting methods and depending on the maker we have to implement a different one? I'm away from home and unable to actually try your ISOs this week. However, the ISOs will boot the same way on all ia64 boxes. The d-i build produces a cdrom-image.img which is basically a large floppy image (8MB, iirc), containing a FAT filesystem. On that filesystem is the kernel and initrd images, elilo.efi, and elilo.conf. This floppy image is what is being referred to as a DOS EFI filesystem. debian-cd creates the ISO, specifying that floppy image as the boot image. When you put the CD in the ia64 box, and from the EFI Shell change to the relevant device, and issue ls you should see those files. You can then invoke 'elilo' to start the install process. I suppose it is possible one of your ISO images is broken, and all success reports were for the other one, but it seems unlikely. Peter, can you give us any more info on what you did to determine that the CD didn't appear to be bootable? Thanks, Richard Ideas on how to fix this? Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i - subarchitecture stuff
On Fri, Oct 03, 2003 at 08:12:59AM +0200, Wouter Verhelst wrote: I'll hereby specify for m68k: - mac - amiga - atari - vme - unknown Well, as we currently have three different vme kernels (mvme147, mvme16x, bvme6000), that might mean three different subarchs. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i - subarchitecture stuff
On Fri, Oct 03, 2003 at 11:44:19AM +0200, Wouter Verhelst wrote: Op vr 03-10-2003, om 10:04 schreef Richard Hirst: On Fri, Oct 03, 2003 at 08:12:59AM +0200, Wouter Verhelst wrote: I'll hereby specify for m68k: - mac - amiga - atari - vme - unknown Well, as we currently have three different vme kernels (mvme147, mvme16x, bvme6000), that might mean three different subarchs. Separating kernels from eachother is done by the XB-Kernel-Version field in a kernel-image-udeb. Unless you're telling me that some of the VME boards can only boot with vmelilo, while others can only boot with m68k-vme-tftplilo, that won't be necessary. No, that is not the case. They all boot via vmelilo, and all but mvme147 boot via tftplilo. Sounds like they are all just 'vme' then. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer, ia64 status update
On Sun, Sep 28, 2003 at 10:05:20AM +0200, Matt Kraai wrote: On Sat, Sep 27, 2003 at 01:12:18PM +0100, Richard Hirst wrote: I'm using the newt frontend, which looks pretty good, except for some package names running off the edge of the screen during base install. Maybe the frontend code could cut down the start of the filepath, keeping the first word of the line intact, so it looks like: Retrieving: ...ebian/pool/main/f/foobar_1.2_ia64.deb Frotend-specific, of course, because the frontend is the bit that knows how wide the window is. There is code in CVS to wrap long progress bar information. Ugh, just seen it in action. Very ugly, IMHO, with the window jumping up and down the screen, changing height, and wrapping in the middle of the package name (which is really the only interesting bit of information in that text). I think it would look much nicer to abbreviate the line somehow (as in my exapmle above) rather than wrap it. Maybe we do that in the front end, or maybe we make debootstrap do it, working on some assumption such as progress text should not be longer than 70 chars. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#213669: cdebconf-newt-udeb: progress bar dialog changes size all the time, which is ugly
On Thu, Oct 02, 2003 at 05:48:42AM -0700, Matt Kraai wrote: On Wed, Oct 01, 2003 at 10:55:17PM +0200, Steinar H. Gunderson wrote: With the progress bar status text wrapping patch that was made at debcamp, the dialog changes size all the time (it changes height) to make room for the new text. When the text changes frequently (like installing packages from a fast source) this makes the dialog box change size back and forth all the time, which flickers and is really really ugly. I'd propose keeping it at a fixed height (say, three lines) and simply cropping the text if it is larger than that -- alternatively, make the minimum height three lines and making it expand above that, which at least reduces the flickering considerably. This isn't such a problem on my 128-column console. :) I'd prefer to only let it grow, rather than truncate the text. Here's the patch I'll commit if it passes testing. It'll still look ugly, as it flickers between Retrieving: http://beast/debian/pool/main/e/ef/ef_0.3_ia64.udeb Retrieving: http://beast/debian/pool/main/e/efi-reader/efi-reader_0.3_ia64.udeb Retrieving: http://beast/debian/pool/main/l/long-efi-reader/long-efi-reader_0.3 _ia64.udeb I accept that it isn't a problem for your wide console, which is why I originally suggested that the frontend, which presumably knows the space it has available, should truncate the start of the path name. Giving something like: Retrieving: http://beast/debian/pool/main/e/ef/ef_0.3_ia64.udeb Retrieving: ...debian/pool/main/e/efi-reader/efi-reader_0.3_ia64.udeb Retrieving: ...l/main/l/long-efi-reader/long-efi-reader_0.3_ia64.udeb where the one interesting bit on information, the package name, is in a fairly consistent position on the screen. It is a bit ugly from a technical pov having the frontend know it has to truncate the start of the second component of the string, but it'll look a whole lot nicer. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i, pulling in fdisk-udeb
On Thu, Oct 02, 2003 at 09:51:08AM +0200, Sven Luther wrote: On Wed, Oct 01, 2003 at 12:41:49AM +0100, Richard Hirst wrote: On Wed, Oct 01, 2003 at 01:38:11AM +0200, Steinar H. Gunderson wrote: On Tue, Sep 30, 2003 at 04:32:20PM -0700, Matt Kraai wrote: Make it depend on partitioning-program, and make both fdisk-udeb and parted-udeb Provide[s]: that. Should solve the problem. No, it won't. anna could still install just parted-udeb since that would satisfy the dependency. If partitioner depends on a particular udeb, it needs to Depend on the particular udeb. If parted-udeb is unusable on a particular platform, I'd take it it was never built/uploaded for that platform at all...? I didn't mean to say that parted was unusable on hppa. It exists and probably works ok. But parted cannot be used for creating the 'f0' partition that palo needs. Have you ever considered asking the parted upstream author or filling a bug report against the parted debian package, for this particular feature request. I have been doing some parted work, but know nothing about the hppa specific needs, but if you explain it to me, i may be willing to add the needed support to libparted or something. I've put quite a bit of effort in on parted in the past too, relating to GPT partition tables. The issue is that parted tends to identify partition types by their content, and not by the 'type' byte in an msdos partition table. This is partly because parted handles many different partition table formats, they don't all have a 'type' byte, and parted tries to present a uniform interface. GPT tables, for example, have a 32 byte GUID instead. So parted lets you say this partition is for linux swapspace, and for msdos tables it knows to set the type to 82 and for GPT it knows to use some specific GUID. Some special types or GUIDs are exposed to the parted interface as 'flags' you can set. e.g. if you set the hp_service 'flag', it will write the PARTITION_HPSERVICE_GUID in a GPT table. To fix this issue, I'd need to expose a new flag through the parted i/f, so you could set palo on, or similar. For msdos tables it would know that meant to set type=f0. For other partition table types it would have no effect. Alternatively I could introduce a new command completely for setting a partition table 'type' to some user-specified hex value. But what would that do for non-msdos tables? Having an interface where you can type in 32 byte GUIDs seems silly to me. As to why I havn't done anything about this.. there really hasn't been any incentive as we have cfdisk on hppa which works fine and has a nice easy to understand interface. If d-i ends up dictating that I have to use parted, or eventually presents a nicer interface to parted than its current cli one, then it'll be worth worrying about. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i, pulling in fdisk-udeb
On Thu, Oct 02, 2003 at 03:37:26PM +0200, Sven Luther wrote: On Thu, Oct 02, 2003 at 01:53:22PM +0100, Richard Hirst wrote: To fix this issue, I'd need to expose a new flag through the parted i/f, so you could set palo on, or similar. For msdos tables it would know Adding a flag is almost trivial to do, no ? Sure, it was when I added hp_service, anyway. that meant to set type=f0. For other partition table types it would have no effect. Alternatively I could introduce a new command completely for setting a partition table 'type' to some user-specified hex value. But what would that do for non-msdos tables? Having an interface where you can type in 32 byte GUIDs seems silly to me. Notice that libparted already knows how to do that, but does it only when writing filesystem. There is no way currently to tell libparted to set a given partition type, and use another tool to create the filesystem. I have also been playing with the thought of adding some kind of attribute setting for partitions, which could accept, in addition to boolean flags, also other kind of values (which are needed to set the filesystem block type on amiga partition/filesystems for example, as well as the boot priority). Sounds good, parted does need some feature like that, IMHO. As to why I havn't done anything about this.. there really hasn't been any incentive as we have cfdisk on hppa which works fine and has a nice easy to understand interface. If d-i ends up dictating that I have to use parted, or eventually presents a nicer interface to parted than its current cli one, then it'll be worth worrying about. Well, libparted is not only used by parted proper, but also by a bunch of other tools in d-i. Yes, and having the auto-partitioner understand to create an f0 partition for hppa, and a small efi boot partition for ia64, etc, would be very nice. I just havn't had chance to look at that yet. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i, pulling in fdisk-udeb
On Thu, Oct 02, 2003 at 04:19:21PM +0200, Sven Luther wrote: On Thu, Oct 02, 2003 at 02:47:37PM +0100, Richard Hirst wrote: Yes, and having the auto-partitioner understand to create an f0 partition for hppa, and a small efi boot partition for ia64, etc, would be very nice. I just havn't had chance to look at that yet. Do you think you will find the time for this nextly, or someone else should start to look into this ? Probably in the next few weeks, for ia64 anyway. But if someone wants to beat me to it, that's fine. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer, ia64 status update
On Thu, Oct 02, 2003 at 07:58:49AM -0700, Matt Kraai wrote: On Thu, Oct 02, 2003 at 07:46:44AM -0700, Matt Kraai wrote: On Thu, Oct 02, 2003 at 12:56:23PM +0100, Richard Hirst wrote: Ugh, just seen it in action. Very ugly, IMHO, with the window jumping up and down the screen, changing height, and wrapping in the middle of the package name (which is really the only interesting bit of information in that text). I think it would look much nicer to abbreviate the line somehow (as in my exapmle above) rather than wrap it. Maybe we do that in the front end, or maybe we make debootstrap do it, working on some assumption such as progress text should not be longer than 70 chars. I'd prefer the latter. Actually, since the package name is the only interesting part, why not have debootstrap display only that? Sounds like a good idea to me. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i, pulling in fdisk-udeb
Hi, For hppa I need fdisk-udeb pulled in when d-i runs. parted cannot be used to partition for hppa because we need a partition for palo of type 'f0', and parted doesn't let you specify partition types (didn't last time I looked anyway). At the moment I have to specifically request that installer module in the load installer modules menu item. How should I make fdisk-udeb get pulled in automatically? I could make palo-installer depend on it, I guess, but that doesn't sound very logical as palo doesn't really care which partitioner is used provided it creates the right partitions. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i, pulling in fdisk-udeb
On Tue, Sep 30, 2003 at 11:07:37PM +0200, Geert Stappers wrote:
On Tue, Sep 30, 2003 at 06:59:05PM +0100, Richard Hirst wrote:
Hi,
For hppa I need fdisk-udeb pulled in when d-i runs. parted cannot be
used to partition for hppa because we need a partition for palo of type
'f0', and parted doesn't let you specify partition types (didn't last
time I looked anyway). At the moment I have to specifically request
that installer module in the load installer modules menu item.
How should I make fdisk-udeb get pulled in automatically? I could make
palo-installer depend on it, I guess, but that doesn't sound very
logical as palo doesn't really care which partitioner is used provided
it creates the right partitions.
In build/Makefile is this code:
|# Build the driver floppy image
|$(EXTRA_TARGETS) : %-stamp : $(TYPE)-get_udebs-stamp
|mkdir -p ${TEMP}/$*
|for file in $(shell grep --no-filename -v ^\# pkg-lists/$*/common \
|`if [ -f pkg-lists/$*/$(DEB_HOST_ARCH) ]; then echo
pkg-lists/$*/$(DEB_HOST_ARCH); fi` \
|| sed -e 's/^\(.*\)$${kernel:Version}\(.*\)$$/$(foreach
VERSION,$(KERNELIMAGEVERSION),\1$(VERSION)\2\n)/g' ) ; do \
|cp $(EXTRAUDEBDIR)/$$file* ${TEMP}/$* ; \
|echo $$file ${TEMP}/$*/udeb_include; \
|done
|touch $@
It generates udeb_include from files under build/pkg-lists
I have not yet played with it, but that is where I would start
adding udebs.
Hmm, I could add fdisk-udeb to pkg-lists/*/hppa, but that would include
the udeb in the initrd image, rather than downloading it from the cdrom
or mirror at runtime along with the other d-i modules.
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i, pulling in fdisk-udeb
On Tue, Sep 30, 2003 at 03:09:25PM -0700, Matt Kraai wrote: On Tue, Sep 30, 2003 at 06:59:05PM +0100, Richard Hirst wrote: For hppa I need fdisk-udeb pulled in when d-i runs. parted cannot be used to partition for hppa because we need a partition for palo of type 'f0', and parted doesn't let you specify partition types (didn't last time I looked anyway). At the moment I have to specifically request that installer module in the load installer modules menu item. How should I make fdisk-udeb get pulled in automatically? I could make palo-installer depend on it, I guess, but that doesn't sound very logical as palo doesn't really care which partitioner is used provided it creates the right partitions. I think the Depends field for partitioner should be Depends: cdebconf-udeb, fdisk-udeb, hw-detect-full on hppa and left as Depends: cdebconf-udeb, parted-udeb, hw-detect-full on other architectures. I'm not sure how to do this, though. According to partitioner/scripts/* there are many archs that want *fdisk. I can see lilo-installer depends on it, so I guess it is pulled in for i386, but for no-one else. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i, pulling in fdisk-udeb
On Wed, Oct 01, 2003 at 01:38:11AM +0200, Steinar H. Gunderson wrote: On Tue, Sep 30, 2003 at 04:32:20PM -0700, Matt Kraai wrote: Make it depend on partitioning-program, and make both fdisk-udeb and parted-udeb Provide[s]: that. Should solve the problem. No, it won't. anna could still install just parted-udeb since that would satisfy the dependency. If partitioner depends on a particular udeb, it needs to Depend on the particular udeb. If parted-udeb is unusable on a particular platform, I'd take it it was never built/uploaded for that platform at all...? I didn't mean to say that parted was unusable on hppa. It exists and probably works ok. But parted cannot be used for creating the 'f0' partition that palo needs. Anyway, for any arch where you are going to partition manually, you'll surely want to use cfdisk rather than cmdline parted, if possible. (ia64 is an exception, as parted is the only thing that can create GPT partition tables). Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Installer, ia64 status update
Installing from cdrom works, although my build system has local fixes for a few bugs where I'm waiting for new versions of packages: 210570 - discover-data, fix module used for various QLogic cards 210359 - kernel-patch-2.4.20-ia64, CONFIG_TR kernel headers problem, breaks busybox-cvs 212328 - kernel-patch-2.4.20-ia64, include ide-probe-mod.o 211088 - module-init-tools, fails to install because arch/generic missing I know Bdale is travelling, and will get to the kernel-patch bugs soon. There may be changes in d-i cvs that havn't uploaded yet, as well. There is an issue with a recent debootstrap change which removed libperl5.8 from the required list. That breaks things for sarge installs because the corresponding change to perl packaging isn't in sarge yet. I assume that'll sort itself out in time. I've reverted that change in my local debootstrap for now. Outstanding issues: A couple of menu items (cdrom detect, and h/w detect full version, iirc) give me dialogs complaining that something went wrong with modprobe floppy. ia64 needs to modprobe ide-floppy instead, and hppa has no floppy support atm. Not sure of the best way to make this arch specific. Configure partitions option throws up a dialog about failing to load the xfs module - I don't have one, so it should not try to load it, or should fail silently. I have priority=medium atm. I've also tested installing from the net successfully (actually loading the kernel and initrd from a floppy, but using the TYPE=netboot image). I'm using the newt frontend, which looks pretty good, except for some package names running off the edge of the screen during base install. Maybe the frontend code could cut down the start of the filepath, keeping the first word of the line intact, so it looks like: Retrieving: ...ebian/pool/main/f/foobar_1.2_ia64.deb Frotend-specific, of course, because the frontend is the bit that knows how wide the window is. I'm not a d-d, so I assume I can't update the d-i status page.. if someone could do that I'd appreciate it. Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Initial d-i success on alpha
On Wed, Sep 17, 2003 at 11:40:47PM -0500, Steve Langasek wrote: - debootstrap fails with an error ',: applet not found' (IIRC -- I don't have the log in front of me right now). That's game,set,match; can't do much if you can't start the actual install. :) Had this on ia64 also. Turned out the busybox-cvs build was broken, 'tr' existed as a link to busybox, but tr functionality was not in busybox. The cause was broken glibc headers.. linux/config.h was getting included and that does #undef CONFIG_TR (no token ring), which overrode the CONFIG_TR in busybox. Bug filed on krnel-patch_2.4.20-ia64. HTH, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i experiences
On Tue, Sep 16, 2003 at 12:58:40AM +0100, Daniel Silverstone wrote: It seems debootstrap barfed on an id call, something to do with [ and I see this on ia64 too. 'id' in busybox doesn't work in the d-i environment, but does work in a normal system environment. That particular error seems to be non-fatal. debootstrap does 'id -u' and gets id: unknown group: 0 or similar. As it is in something like if [ `id -u` != 0 ]; then the shell complains. My guess was that 'id' might require more libraries (*nss* stuff), but I havn't invesigated further yet. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i, kernel-img.conf and {link,image}_in_boot
Hi, link_in_boot is just the new name for image_in_boot. rootskel/debian/templates-arch defined link_in_boot, which is used in tools/base-installer/debian/kernel-installer.postinst when creating /etc/kernel-img.conf. However, that script writes image_in_boot = yes link_in_boot = $link_in_boot which confuses elilo, at least. elilo looks for either of those values set to 'yes' to decide what to do, and for ia64 link_in_boot = no. So should we set them both to $link_in_boot, or should we just delete the old image_in_boot entry? If no-one says different, I'll delete the old image_in_boot entry. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#210359: kernel CONFIG_TR interferes with busybox CONFIG_TR
package: busybox-cvs version: 0.60.99.cvs20030819 On ia64 the kernel has CONFIG_TR undefined (token ring). The busybox build pulls in /usr/include/linux/autoconf.h, which includes the line #undef CONFIG_TR That results in the 'tr' applet being disabled in the config-udeb build. The include sequence to pull in autoconf.h is /usr/include/linux/autoconf.h /usr/include/linux/config.h:4, /usr/include/asm/param.h:11, /usr/include/linux/param.h:4, /usr/include/sys/param.h:24, include/busybox.h:111, applets/applets.c:32: This stops debian-installer (actually debootstrap) working on ia64. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian installer on ppc/pegasos
On Wed, Aug 27, 2003 at 05:44:45PM +0200, Sven Luther wrote: On Wed, Aug 27, 2003 at 01:41:06AM -0700, Chris Tillman wrote: On Wed, Aug 27, 2003 at 08:16:07AM +0200, Sven Luther wrote: RAMDISK: Compressed image found at block 0 Freeing initrd memory: 2028k freed VFS: Mounted root (ext2 filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 320k init 40k pmac 8k prep ... Nope, nothing more. I think it is definitively related to the 206531 bug. Similar problem on ia64 last night; I copied a full libc6 in to my initrd and things were much better - I got the d-i main menu displayed. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status for reiser support in d-i
On Tue, Aug 26, 2003 at 01:39:05PM +0400, Yury Umanets wrote: On Tue, 2003-08-26 at 13:22, Petter Reinholdtsen wrote: [Yury Umanets] But when I said, about improving parted interface, I meant, that somebody should write a patch exactly to making parted to use ncurses or something like this. I've not meant to write another front end. Actually there is one called qtparted. Area you aware of nparted, URL:http://www.laespiral.org/proyectos/nparted/? No, thanks, It seem to be dead upstream, but was a nice start. :) There is also cparted ftp://ftp.parisc-linux.org/src/cparted/ which I started some time ago. It looks similar to cfdisk, but handles msdos and efi partition tables via libparted. One problem with it is that as you make changes via the user interface, they are committed to disk directly. You don't have an oppertunity to abort after playing with your partition table, as the disk is already modified. That seems to be the way parted works, and is not very suited to an installer. Someone once said it was possible to make libparted work with an in-memory image of a partition table, and avoid commiting to disk until you were happy with all your changes. Havn't investigated that though, and I'm not sure how it would work w.r.t. the parted approach of examining a partition content to decide what type it was. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status for reiser support in d-i
On Tue, Aug 26, 2003 at 04:57:36PM +0400, Yury Umanets wrote: On Tue, 2003-08-26 at 16:34, Richard Hirst wrote: On Tue, Aug 26, 2003 at 01:39:05PM +0400, Yury Umanets wrote: On Tue, 2003-08-26 at 13:22, Petter Reinholdtsen wrote: [Yury Umanets] But when I said, about improving parted interface, I meant, that somebody should write a patch exactly to making parted to use ncurses or something like this. I've not meant to write another front end. Actually there is one called qtparted. Area you aware of nparted, URL:http://www.laespiral.org/proyectos/nparted/? No, thanks, It seem to be dead upstream, but was a nice start. :) There is also cparted ftp://ftp.parisc-linux.org/src/cparted/ which I started some time ago. It looks similar to cfdisk, but handles msdos and efi partition tables via libparted. One problem with it is that as you make changes via the user interface, they are committed to disk directly. You don't have an oppertunity to abort after playing with your partition table, as the disk is already modified. That seems to be the way parted works, and is not very suited to an installer. Someone once said it was possible to make libparted work with an in-memory image of a partition table, and avoid commiting to disk until you were happy with all your changes. Havn't investigated that though, and I'm not sure how it would work w.r.t. the parted approach of examining a partition content to decide what type it was. What about filesystems? Suppose you have created partition. And suppose also, that you're going to create filesystem on it. But filesystem cannot be created without partition being initialized first and filesystem cannot be created in memory. I agree, that is a problem. One approach would be to have a front end that used libparted to get the existing partition configuration, and then modified that data internally based on user interaction. Once the user was happy, the frontend could use libparted to implement whatever partition scheme the user finally settled on (including creating filesystems). I don't like the idea though; sounds like you would be reimplementing parts of parted in the frontend to manage the partition data while the user was interacting with it. Hence you really do want to use libparted to manipulate the partition table, but you don't want it to commit changes to disk until you say so. I guess you delay making filesystems until after the point where you commit to disk. Then you end up with libparted keeping track of the proposed partition layout, and the frontend keeping track of the proposed filesystem types, which is also a little ugly. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdebconf upload
On Wed, Mar 12, 2003 at 07:59:12AM +0800, John Summerfield wrote: On Tue, 11 Mar 2003, Erik Andersen wrote: On Mon Mar 10, 2003 at 11:00:32PM -0500, Joey Hess wrote: - switch to a smaller libc, such as uclibc The only downside to this is that I currently do not support all the architectures that are supported by Debian. Adding support for a new arch to uClibc is really not very hard, and most of the needed bits can be directly swiped from glibc, but it does take someone that is familiar with the architecture and willing to put in a bit of time. Debian arches not currently supported by uClibc: hppa, hurd, ia64, s390 Working but need some additional polish and ldso support: alpha, sparc, m68k Fully supported: arm, i386, mips, mipsel, powerpc, sh Does d-i need a trim libc for all these architectures? For S/390, for example, if you can get a bootable kernel/initrd in place, you can get as bulky an installer as you could wish too. Likewise hppa and ia64 don't have a 1.4MB floppy limitation. Some hppa boxes have 1.4MB floppies, but we don't have kernel driver, and have managed ok so far with CD and network booting. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of Boot-Floppies release 3.0.24
On Wed, Dec 18, 2002 at 07:55:46PM +0100, Eduard Bloch wrote: ( first semi-official call-for-helpers, see also: http://people.debian.org/~blade/bf3024/ ) Preparation of Boot-Floppies release 3.0.24 === ia64 b-f built from cvs Dec 20th are available here: http://gluck.debian.org/~rgh/bf-cvs-ia64/ Now using 2.4.19 kernel. I've tested them on an HP i2000, both with serial and graphical console, and with dhcp and manual network config. In both cases booting from 120MB floppy and installing from the net. Further test reports most welcome. The only issue I have is xlp.tgz which appears in the .changes file; I'm not sure if it should, or if it should be part of bf-misc.tar.gz, or what. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [cdebconf] helper macros, i18n, backup, etc
On Mon, Dec 16, 2002 at 10:09:16PM -0800, Randolph Chung wrote: sorry for the late reply, i was out of town for a few days. 1. The helper macros recently introduced do break several packages under debian-installer/tools/ which used to declare their own debconf_input function. Maybe we could remove these macros, I wonder whether they are that useful. i thought you asked for them? :-) unless i hear otherwise i'll commit a patch tomorrow to wrap them inside a #ifdef WITH_DEBCONF_HELPER_MACROS or something like that. I believe I fixed all resulting breakage a few days ago, with a global s/debconf_input/my_debconf_input/. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: working on the Alpha port
On Thu, Dec 12, 2002 at 09:52:18AM +0100, Denis Barbier wrote: On Thu, Dec 12, 2002 at 05:31:41AM +0300, Alexander Kotelnikov wrote: [...] Dec 12 02:19:35 (none) user.info init: Starting pid 882, console /dev/console: '/sbin/debian-installer' Cannot open template file /var/lib/cdebconf/templates.dat Cannot open template file /var/lib/cdebconf/templates.dat I hit a similar problem when I started the hppa port; turned out that I was mounting '/' read-only. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: loading the initrd
On Thu, Dec 12, 2002 at 03:47:58PM -0500, Noah L. Meyerhans wrote: On Wed, Dec 11, 2002 at 10:14:03PM -0500, Joey Hess wrote: This is something of a shot in the dark, but try using a filesystem that is not cramfs. I vaguely remember some problems along these lines being due to cramfs, maybe its use is not supported on a second floppy. sigh Luser error. I was using the generic kernel-image package, which compiles floppy support as a module. That has been corrected. At this point, the installer system will boot and run on my AlphaServer 4100. I still have to manually load the modules for my NIC, and need to include the SCSI modules in the initrd. One problem I've noticed that may be a bug is that when I tell the installer to Detect hard drives and load modules for them, it only detects the NCR SCSI controller, which only controls my CD-ROM drive. I have to manually load the qlogicisp module to be able to access my hard drives. Also, when trying to partition the hard disks, I get: /var/lib/dpkg/info/di-utils-partitioner.postinst 51: /dev/scsi/host1/bus0/target4/lun0/disc: Permission denied This just happened, so I haven't had time to investigate it. I'm going to do that now, but if this is a known issue I'd be happy to hear about it. You need to fix the partitioner udeb to define FDISK for your platform. Script does $FDISK /dev/scsi/host1/bus0/target4/lun0/disc buf FDISK is null. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cvs main-menu bust?
This change:
@@ -304,20 +306,21 @@
int ret, i;
struct package_t *dep;
+ if (di_pkg_is_virtual(p)) {
+ if (!satisfy_virtual(p))
+ return 0;
+ }
+
for (i = 0; p-depends[i] != 0; i++) {
if ((dep = p-depends[i]-ptr) == NULL)
continue;
if (dep-status == installed)
continue;
- if (di_pkg_is_virtual(dep)) {
- if (!satisfy_virtual(dep))
- return 0;
- } else {
- /* Recursively configure this package */
- if (!config_package(dep))
- return 0;
- }
+ /* Recursively configure this package */
+ if (!config_package(dep))
+ return 0;
}
+
asprintf(configcommand, DPKG_CONFIGURE_COMMAND %s, p-package);
ret = SYSTEM(configcommand);
free(configcommand);
breaks main-menu for me. Execute a Shell still works, but the other
entries on that first menu all just result in the main menu being
redisplayed, preceeded by
Package libdebconf1 is already installed and configured
This in on hppa. Anyone else see this problem, or is it just me?
Richard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Default disk partition table type?
On Tue, Dec 10, 2002 at 12:41:23PM +0100, Petter Reinholdtsen wrote: The current autopartkit contains the following code: /* Need to define on a per arch basis */ #if defined(__i386__) #define DISK_LABEL msdos #else /* not __i386__ */ #error Default DISK_LABEL is not known on this platform #endif /* not __i386__ */ What is the partition table type on other platforms/architectures? I believe the available values are bsd, loop, mac, msdos, pc98 and sun. I got the values from the parted documentation. hppa used msdos. ia64 uses gpt (which parted does support) these days, but has use msdos in the past. m68k uses different ones on different h/w; the mvme boards use msdos. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i hppa support update
Currently builds a net-boot image, 32 bit only, which I have successfully used to install on a B180, via serial and graphical consoles. Install ran right through to login prompt fairly smoothly. If you want to build it, you need a kernel udeb, which you can find here: http://ftp.parisc-linux.org/d-i along with my latest boot image. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
d-i on hppa semi-working
Hi, I have d-i semi-working on hppa; currently breaks on 'partition hard drive' because it doesn't know which partitioner to use. I will commit changes, or file bugs, as appropriate in the next day or two. My current build (net-bootable image) is at ftp.parisc-linux.org:/home/ftp/d-i/lifimage-32-20021202.gz Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: todo?
On Wed, Nov 06, 2002 at 12:21:56AM +0100, Tollef Fog Heen wrote: Getting d-i to work on other arches than i386 is high-priority. I know talk is cheap, but I do intend to work on d-i for hppa and ia64. Just a matter of finding time to get started. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody install for hppa
On Wed, Oct 02, 2002 at 11:01:30PM -0400, Neal Robinette wrote: Hi, I am trying to install woody on a 735/99 with 320 megs of RAM and a 2.4 GB HP FW SCSI hard drive. I have downloaded copies of the install disks. Installationgoes just fine, but the install program can't detect my harddrive. I had thought that the problem with the FW SCSI on the 735 had been resolved; is there a certain setting I need Sorry, FW disks on 735 still don't work under linux. to change, etc., to get the install program to see my harddrive? I am using an external NEC scsi cd-rom drive to install from, and have no floppy or other removable media for this machine. Is this still an active problem, or is there a fix not included with the woody distro? It's one of those problems that gets worked on every now and then when someone has time/interest/hardware. Don't know when it is likely to be resolved. Some people are using 735 by adding a narrow SE drive to the interface with the CDROM. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] debconf, partitioning widget?
On Wed, Jul 17, 2002 at 09:21:51AM +0200, Tollef Fog Heen wrote: * Richard Hirst | Current status is that it can handle msdos and gpt table creation, and | partition creation and deletion. Tested only on ia64. Not touched it | since March, but I can certainly make the code available. yes please. ftp://ftp.parisc-linux.org/src/cparted/ Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] debconf, partitioning widget?
On Tue, Jul 16, 2002 at 10:14:36PM +0200, Eduard Bloch wrote: #include hallo.h Philip Blundell wrote on Tue Jul 16, 2002 um 09:03:29PM: Ah, I just noticed that there is already a newt-based parted frontend (nparted), which will do for dialog mode. The standard parted should suffice for readline mode; I think it should be easy enough to put I tested nparted. Buggy like hell. It was when I looked too, but that was some time ago. I started work on something I called cparted a while ago, which was a cfdisk-like front end to parted. It doesn't yet support all the flashy features of parted (partition moving, resizing), but it has the advantage that it is a familiar interface. Current status is that it can handle msdos and gpt table creation, and partition creation and deletion. Tested only on ia64. Not touched it since March, but I can certainly make the code available. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#152804: boot-floppies: framebuffer causes Mobile Radeons to lock
On Sun, Jul 14, 2002 at 01:13:20AM +0100, Philip Blundell wrote: On Sat, 2002-07-13 at 17:21, Chris Tillman wrote: It was already documented by Richard. But, I added some more details about what the problems look like and what machines have reported problems. Okay, cool. I wonder if's worth explaining the distinction between problems caused by framebuffer itself and problems caused by bogl / LANG_CHOOSER lossage. In the former case, using nolangchooser won't help. Equally, video=vga16:off is hardware specific, so that isn't ideal either, sigh. Actually, I came across code in drivers/video/fbmem.c (2.4 kernel) the other day, which indicates video= works for all frame buffers. It supports the 'off' parameter itself, and for any other parameters it calls the framebuffer specific code if that code has a setup function. So, for the atari, for example, you might use video=atafb:off, or for hppa video=stifb:off. I havn't tested this, and don't know if it applies to 2.2. kernels. Where 'nolangchooser' just stops bterm running, this would disable the framebuffer driver itself. As I say, untested. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n second stage...
On Thu, Jun 13, 2002 at 06:54:39PM +0200, Michael Bramer wrote: gluck.d.o (aka ddtp) is down. Know someone the problem? That's hosted at HP, isn't it? they are having some internal routing problems the last day or so. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: coordinating b-f 3.0.23 release
On Wed, May 15, 2002 at 12:01:22PM -0500, Christian T. Steigies wrote: On Wed, May 15, 2002 at 12:23:59PM -0400, Adam Di Carlo wrote: For coordinating, can we agree to perhaps tag and start it building tonight? I don't see anything blocking 3.0.23 release. Do we now have an option to switch the language chooser off? Something that works on framebuffers as well (VGA=off is not an option on m68k, hppa). Currently woody boot-floppies are not usable on monochrome macs and ataris, which is already creating a lot of pain... I've commited my change so booting with 'nolangchooser' stops it using bterm and hence the framebuffer. Undocumented as yet.. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to boot-floppies by rhirst
On Wed, May 15, 2002 at 09:39:22PM +0200, Pierre Machard wrote: On Wed, May 15, 2002 at 12:31:47PM -0700, Debian Boot CVS Master wrote: Repository: boot-floppies who:rhirst time: Wed May 15 12:31:46 PDT 2002 Log Message: add nolangchooser boot option to disable framebuffer; video=vga16:off doesn't work on all systems (e.g. m68k, hppa) Doesn't il also imply an update of scripts/rescue/messages ? Done. Added entry to f7.txt. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to boot-floppies by rhirst
On Wed, May 15, 2002 at 03:36:19PM -0500, Christian T. Steigies wrote: On Wed, May 15, 2002 at 09:03:13PM +0100, Richard Hirst wrote: On Wed, May 15, 2002 at 09:39:22PM +0200, Pierre Machard wrote: On Wed, May 15, 2002 at 12:31:47PM -0700, Debian Boot CVS Master wrote: Repository: boot-floppies who:rhirst time: Wed May 15 12:31:46 PDT 2002 Log Message: add nolangchooser boot option to disable framebuffer; video=vga16:off doesn't work on all systems (e.g. m68k, hppa) Doesn't il also imply an update of scripts/rescue/messages ? Done. Added entry to f7.txt. How do you read that on machines that can not boot from CD or floppy? Is this also mentioned in the documentation? Will be shortly. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: b-f 3.0.23
On Tue, May 14, 2002 at 09:31:13AM +0900, Junichi Uekawa wrote: Christian T. Steigies [EMAIL PROTECTED] immo vero scripsit: On Tue, May 14, 2002 at 12:51:07AM +1000, Anthony Towns wrote: Hi guys, If you'd like to tag and upload 3.0.23 sometime this week, that will be fine. I believe there are some sparc updates desirect so we can have bootable sparc CDs, that Ben will know about. Please follow Adam's lead, and don't do anything to break them. It'd be better if all architectures could sync on 3.0.23 reasonably quickly, but any that don't will just stick with 3.0.22. Has anything happend to make bogl work on monochrome displays or do we have any command line switch/option/whatever to force the fallback on the non-language chooser installer? There seem to be more and more monochrome m68k-macs around and it would be nice if they could use the woody boot-floppies as well. Do we still have problems with monochrome displays ? I think there is a boot-time option to disable the graphics mode, which should be enough. I'm not aware of anything. Maybe some framebuffers have boot time options to disable them, but I don't think boot-floppies has any such option. Can I suggest something like the patch below, which would let us boot with nolangchooser to disable bterm and hence language chooser. Might also help on at least one hppa box where framebuffer code is broken such that b-f wont boot since I turned on language chooser. Richard Index: rootdisk.sh === RCS file: /cvs/debian-boot/boot-floppies/rootdisk.sh,v retrieving revision 1.364 diff -u -r1.364 rootdisk.sh --- rootdisk.sh 2002/04/16 20:45:16 1.364 +++ rootdisk.sh 2002/05/14 12:16:32 @@ -406,7 +406,9 @@ $scripts/prototype/etc/inittab $T/etc/inittab cat EOF $T/sbin/udbootstrap #!/bin/sh -if (/dev/fb0) 2/dev/null ! grep -q console=ttyS /proc/cmdline 2 /dev/null ; then +if (/dev/fb0) 2/dev/null \ + ! grep -q console=ttyS /proc/cmdline 2 /dev/null \ + ! grep -q nolangchooser /proc/cmdline 2 /dev/null ; then LC_CTYPE=C@utf-8 export LC_CTYPE exec /usr/bin/bterm -f /unifont-reduced.bgf /sbin/dbootstrap -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: b-f 3.0.23
On Tue, May 14, 2002 at 03:47:38PM +0100, Philip Blundell wrote: On Tue, 2002-05-14 at 13:58, Junichi Uekawa wrote: On Tue, 14 May 2002 13:15:35 +0100 Richard Hirst [EMAIL PROTECTED] wrote: I'm not aware of anything. Maybe some framebuffers have boot time options to disable them, but I don't think boot-floppies has any such option. Can I suggest something like the patch below, which would let us boot with nolangchooser to disable bterm and hence language chooser. Might also help on at least one hppa box where framebuffer code is broken such that b-f wont boot since I turned on language chooser. Isn't it possible to specify in the kernel command line to disable VGA, which results in no VGA = no language chooser? Not on m68k. Fbcon is the only display method those machines have, you can't turn it off. Your idea would work for PCs where the graphics card breaks with LC for some reason, but I haven't heard of any instances where that actually happens. I'm not sure which boat HPPA is in. HPPA uses stifb, which doesn't have an option to disable it either. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#142305: i386 - borders gone on vanilla flavor
On Wed, Apr 10, 2002 at 11:13:25PM -0700, David Kimdon wrote: Package: boot-floppies Version: 3.0.22 Severity: minor I observed this as well today. I tested the vanilla kernel, there were no borders on the first few boxes (I didn't progress as far as the driver config, so I can't confirm problems there.) Booting with linux TERM=vt102 gives you the borders. TERM=linux only seems to display borders under framebuffer/bterm now. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: parted.txt build problem
On Tue, Apr 09, 2002 at 03:07:37PM +0200, Josip Rodin wrote: For now it would be good if someone provided me with a copy of fully built parted.txt :) Is this what you want? http://saens.debian.org/debian/dists/woody/main/disks-ia64/3.0.22-2002-04-03/doc/parted.txt Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: b-f 3.0.22 on hppa, screen drawing problem
Hi, I rebuilt with newt and whiptail -9.6 versions. It help with one of my problems; note there is no dependancy on that version in b-f source, and it is not yet in woody. On Sat, Apr 06, 2002 at 02:22:07PM -0500, Adam Di Carlo wrote: Richard Hirst [EMAIL PROTECTED] writes: Just built 3.0.22 for hppa, and tried an install in French. When I formatted my second partition, and it put up the dialog asking me where I wanted to mount it (/boot, /usr, etc), that dialog was drawn over the previous one. I selected /boot, and the next dialog was draw over the top again, giving me the main menu with bits of the where do you want to mount one showing at either side. This problem still occurred, I guess it is related to the very long description of /var in French. Subsequent dialogs cleared properly. The next problem was that the screen where I should select which modules I want to load didn't actually list any modules. Just had the 'exit' option. This seems to This was fixed, as Junichi suggested it should be. I guess I don't need to file any bugs, as work is underway to shorten the long translated strings (judging for the other m-l traffic). Should I upload a 3.0.22.0.1 for hppa, wait for 3.0.23, or just live with the remaining problem for now? Cheers, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: newt boxes displaying problems (translation problem)
On Mon, Apr 08, 2002 at 03:04:59PM +0200, Martin Quinson wrote: On Mon, Apr 08, 2002 at 02:41:45PM +0200, thomas poindessous wrote: If it is that, can you contact french translator please ? That's me :) I think the descripion of /var when prompting for mountpoints needs to be shortened too - it is much longer than the other menu entries, resulting in a very wide menu with no borders for me (hppa). Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
