Bug#413814: installing Debian GNU/Linux 4.0 on a Power Macintosh G3 Server
Package: installation-reports Boot method: BootX Image version: Debian etch powerpc weekly build Date: February 4th 2007 Machine: Power Macintosh G3 Server Architecture: powerpc Processor: PowerPC 740/750 (G3) Memory: 256 MB Partitions: Result of df -Tl: FilesystemType 1K-blocks Used Available Use% Mounted on /dev/hda9 ext3 2883640 1201232 1535924 44% / tmpfstmpfs 119788 0119788 0% /lib/init/rw udev tmpfs 1024096 10144 1% /dev tmpfstmpfs 119788 0119788 0% /dev/shm /dev/hda10ext3 5291948171180 4851944 4% /home /dev/hda8 ext3 132385 26384 99166 22% /var/log /dev/hda6 hfs 819182364065455117 45% /mnt/MacOS Result of mac-fdisk -l: /dev/hda #type name length base ( size ) system /dev/hda1 Apple_partition_map Apple63 @ 1 ( 31.5k) Partition map /dev/hda2Apple_Driver_ATA Macintosh54 @ 64 ( 27.0k) Unknown /dev/hda3Apple_Driver_ATA Macintosh74 @ 118 ( 37.0k) Unknown /dev/hda4 Apple_Driver_IOKit Macintosh 512 @ 192 (256.0k) Unknown /dev/hda5 Apple_Patches Patch Partition 512 @ 704 (256.0k) Unknown /dev/hda6 Apple_HFS sans titre 1638400 @ 1216 (800.0M) HFS /dev/hda7 Apple_UNIX_SVR2 swap1015626 @ 1639616 (495.9M) Linux swap /dev/hda8 Apple_UNIX_SVR2 untitled 273438 @ 2655242 (133.5M) Linux native /dev/hda9 Apple_UNIX_SVR2 untitled5859376 @ 2928680 ( 2.8G) Linux native /dev/hda10Apple_UNIX_SVR2 untitled 10753032 @ 8788056 ( 5.1G) Linux native Block size=512, Number of Blocks=19541087 DeviceType=0x0, DeviceId=0x0 Drivers- 1: @ 64 for 21, type=0x701 2: @ 118 for 34, type=0xf8ff Output of lspci -nn: 00:00.0 Host bridge [0600]: Motorola MPC106 [Grackle] [1057:0002] (rev 40) 00:10.0 Unknown class [ff00]: Apple Computer Inc. Heathrow Mac I/O [106b:0010] (rev 01) 00:12.0 VGA compatible controller [0300]: ATI Technologies Inc 3D Rage Pro 215GP [1002:4750] (rev 5c) Output of lspci -vnn: 00:00.0 Host bridge [0600]: Motorola MPC106 [Grackle] [1057:0002] (rev 40) Flags: bus master, fast devsel, latency 0 00:10.0 Unknown class [ff00]: Apple Computer Inc. Heathrow Mac I/O [106b:0010] (rev 01) Flags: bus master, medium devsel, latency 32 Memory at f300 (32-bit, non-prefetchable) [size=512K] 00:12.0 VGA compatible controller [0300]: ATI Technologies Inc 3D Rage Pro 215GP [1002:4750] (rev 5c) (prog-if 00 [VGA]) Flags: bus master, stepping, medium devsel, latency 32, IRQ 22 Memory at 8100 (32-bit, non-prefetchable) [size=16M] I/O ports at fe000c00 [size=256] Memory at 8080 (32-bit, non-prefetchable) [size=4K] Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[E] Overall install:[O] Comments/Problems: Here's a feedback of my installation of Debian 4.0 "etch" on a Power Macintosh G3 MiniTower Since it's an oldworld macintosh, it cannot boot from the Debian CDs. I tried booting from floppies, but it never worked, the floppy drive is probably dead. So my solution was to install a legit copy of MacOS 9.2 Here's what I did: - boot into MacOS 9.2 - launch BootX with the files vmlinux and initrd.gz - debian-installer runs smoothly and everything goes well, except one thing: when debian-installer attempts to install quik as a boot loader, the operation fails, and the error messages states that "the partition is not ext2". This error messages seems odd to me. What partition does d-i mean ? The partition where MacOS 9.2 is, which is HFS ? One of the Linux partitions, which are ext3 and not ext2 ? Anyway, isn't ext2 the same thing as ext3 without journalization ? - anyway I'm not worried at all that quik could not install, because I still can boot into MacOS 9.2 and then fire up BootX to boot into Debian GNU/Linux - debian-installer finished up its work and reboots the machine ... and then something goes wrong: I see on the power macintosh a flashing "?" in a floppy. This means "I can't find any operating system to boot" ... ouch ! Now that's a problem. - I tried zapping the PRAM, it did not help. - Finally I took the "Outil Disque Dur" diskette and chose the menu "Fonction" and then "Mise à jour". Pardon my French, this should translate to "Apple Disk Tool", menu "Functions" and then "Update". I don't know the exact wording since I've never used MacOS
Bug#389881: RC-ness of this bug
On Tue, Mar 06, 2007 at 04:41:19PM +0100, Mike Hommey wrote: > On Tue, Mar 06, 2007 at 01:15:23PM +0100, Marco d'Itri wrote: > > On Mar 06, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: > > > > > I urge you to reconsider severity of this problem. There's another > > > situation > > > that makes it much worse: > > The correct solution is to make d-i use labels in fstab and to find the > > root file system. udev has not much to do with this. > > Which will enable a whole lot of other broken setups. Even uuids would be > better to use, though I'm not sure all filesystem types expose one (ditto > for labels, actually). Labels are not well tested and a source of problems indeed. Can't we just give a different namespace to USB sticks than /dev/sd[a-z] ? -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > > > On Mar 06, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: > > > >> I urge you to reconsider severity of this problem. There's another > >> situation > >> that makes it much worse: > > The correct solution is to make d-i use labels in fstab and to find the > > root file system. udev has not much to do with this. > > I think it's too late for that kind of change on d-i side. This "right > solution" looks to be post-Etch material to me. Then we should remove the USB images from the release. They're utterly broken and only work on old hardware. It'd be a shame if we label this as "stable". -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RAID <-> Crypto wiki page
On Wednesday 07 March 2007 00:58, David Härdeman wrote: > On FJP's request I've put up a wiki page describing the problem with > combined crypto and RAID setups in the current installer and how it can > be worked around. Here's the url for the page: http://wiki.debian.org/DebianInstaller/RAIDvsCrypto pgpKIz7vbBwV4.pgp Description: PGP signature
Bug#389881: RC-ness of this bug
On Mar 07, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: > Labels are not well tested and a source of problems indeed. The /dev/disk/by-*/ devices are well tested and I do not know about problems posed by them. -- ciao, Marco signature.asc Description: Digital signature
Bug#389881: RC-ness of this bug
> -Original Message- > From: Marco d'Itri [mailto:[EMAIL PROTECTED] > Sent: 07 March 2007 11:05 > To: Robert Millan [ackstorm] > Cc: Mike Hommey; [EMAIL PROTECTED]; debian-release@lists.debian.org > Subject: Bug#389881: RC-ness of this bug > > > On Mar 07, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: > > > Labels are not well tested and a source of problems indeed. > The /dev/disk/by-*/ devices are well tested and I do not know about > problems posed by them. but if we are going to use those which set should we use? by-path seems like a reasonable choice though it will break if users move anything (but then so would the old system in many cases) by-id seems to use the make/model of the drive and maybe some unique id of the drive, by-uuid contains my two ext3 partitions but not my swap partition, it also seems like it may be vulnerable to becoming confused. maybe an answer would be to use by-path if drives are presenent on multiple controllers during installation and use conventional names otherwise (possiblly with a way to override this behaviour for experts).
Bug#389881: RC-ness of this bug
On Mar 07, peter green <[EMAIL PROTECTED]> wrote: > by-uuid contains my two ext3 partitions but not my swap partition, it also > seems like it may be vulnerable to becoming confused. Only if the admin is a moron and keeps around multiple file systems cloned with dd. -- ciao, Marco signature.asc Description: Digital signature
Bug#389881: RC-ness of this bug
On Wed, Mar 07, 2007 at 12:05:09PM +0100, Marco d'Itri wrote: > On Mar 07, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: > > > Labels are not well tested and a source of problems indeed. > The /dev/disk/by-*/ devices are well tested and I do not know about > problems posed by them. I thought we were talking about fstab device labels. fsck doesn't seem to work well with them. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
"Robert Millan [ackstorm]" <[EMAIL PROTECTED]> writes: > On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote: >> [EMAIL PROTECTED] (Marco d'Itri) writes: >> >> > On Mar 06, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: >> > >> >> I urge you to reconsider severity of this problem. There's another >> >> situation >> >> that makes it much worse: >> > The correct solution is to make d-i use labels in fstab and to find the >> > root file system. udev has not much to do with this. >> >> I think it's too late for that kind of change on d-i side. This "right >> solution" looks to be post-Etch material to me. > > Then we should remove the USB images from the release. They're utterly broken > and only work on old hardware. It'd be a shame if we label this as "stable". There's no workaround for the issue? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Wed, Mar 07, 2007 at 01:26:47PM +0100, Robert Millan [ackstorm] wrote: > On Wed, Mar 07, 2007 at 12:05:09PM +0100, Marco d'Itri wrote: > > On Mar 07, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: > > > > > Labels are not well tested and a source of problems indeed. > > The /dev/disk/by-*/ devices are well tested and I do not know about > > problems posed by them. > > I thought we were talking about fstab device labels. fsck doesn't seem to > work well with them. I don't know what /dev/disk/by-* do with name collisions, but the result is pretty much everything but what you would expect with the LABEL= syntax (i.e. when libblkid is used). Name collisions on labels are really not unlikely. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
"Robert Millan [ackstorm]" <[EMAIL PROTECTED]> writes: > On Wed, Mar 07, 2007 at 09:33:47AM -0300, Otavio Salvador wrote: >> "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> writes: >> >> > On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote: >> >> [EMAIL PROTECTED] (Marco d'Itri) writes: >> >> >> >> > On Mar 06, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: >> >> > >> >> >> I urge you to reconsider severity of this problem. There's another >> >> >> situation >> >> >> that makes it much worse: >> >> > The correct solution is to make d-i use labels in fstab and to find the >> >> > root file system. udev has not much to do with this. >> >> >> >> I think it's too late for that kind of change on d-i side. This "right >> >> solution" looks to be post-Etch material to me. >> > >> > Then we should remove the USB images from the release. They're utterly >> > broken >> > and only work on old hardware. It'd be a shame if we label this as >> > "stable". >> >> There's no workaround for the issue? > > With USB, you can't just boot a rescue system and repair a broken install > from there, because /dev/sda will still be your USB drive. > > Of course, there are lots of hacks you can do to workaround that, but if > we go this way, why bother using d-i anyway ? I could just boot from USB > and run debootstrap by hand. > > If we remove USB sticks from etch, then at least people will know they're > broken and switch to CDs (or use the dailies). I don't know how invasive those changes might be. AFAIK Ubuntu already does it (Colin?) and wouldn't be too hard to pick the changes from them but we would also need RM and Frans approval :( -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Wed, Mar 07, 2007 at 09:33:47AM -0300, Otavio Salvador wrote: > "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> writes: > > > On Tue, Mar 06, 2007 at 09:44:31AM -0300, Otavio Salvador wrote: > >> [EMAIL PROTECTED] (Marco d'Itri) writes: > >> > >> > On Mar 06, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote: > >> > > >> >> I urge you to reconsider severity of this problem. There's another > >> >> situation > >> >> that makes it much worse: > >> > The correct solution is to make d-i use labels in fstab and to find the > >> > root file system. udev has not much to do with this. > >> > >> I think it's too late for that kind of change on d-i side. This "right > >> solution" looks to be post-Etch material to me. > > > > Then we should remove the USB images from the release. They're utterly > > broken > > and only work on old hardware. It'd be a shame if we label this as > > "stable". > > There's no workaround for the issue? With USB, you can't just boot a rescue system and repair a broken install from there, because /dev/sda will still be your USB drive. Of course, there are lots of hacks you can do to workaround that, but if we go this way, why bother using d-i anyway ? I could just boot from USB and run debootstrap by hand. If we remove USB sticks from etch, then at least people will know they're broken and switch to CDs (or use the dailies). -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413836: installation-reports
Package: installation-reports Boot method: Netinstall CD-image Image version: etch RC1 Date: 28 january 2007 Machine: Processor: p4 ( but installed with i386 ) Memory: Partitions: system, home, swap Output of lspci -nn and lspci -vnn: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ O] Detect network card:[ O] Configure network: [ O] Detect CD: [ O] Load installer modules: [ O] Detect hard drives: [ O] Partition hard drives: [ O] Install base system:[ E] Clock/timezone setup: [ O] User/password setup:[ O] Install tasks: [ E] Install boot loader:[ O] Overall install:[ E] Comments/Problems: Problems with the supplied version of kernel for the i686, but using the i386 to boot and then installing the most recent i686 version worked. Problems with the linux-igd package that reports not being correctly installed but the program works and installs ok - so it works but gives errors Overall installation gave errors but the system is working. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
> > by-uuid contains my two ext3 partitions but not my swap > partition, it also seems like it may be vulnerable to becoming confused. > > Only if the admin is a moron and keeps around multiple file systems > cloned with dd. are you calling it moronic to make a backup of a partition by dding to to a spare one? since this was a perfectly workable system of backup under the conventional way of doing things i'd call that pretty unexpected breakage. the fact it doesn't seem to work for all partition types would seem to rule it out anyway.
Bug#389881: RC-ness of this bug
"Robert Millan [ackstorm]" <[EMAIL PROTECTED]> writes: > On Wed, Mar 07, 2007 at 09:55:45AM -0300, Otavio Salvador wrote: >> > >> > With USB, you can't just boot a rescue system and repair a broken install >> > from there, because /dev/sda will still be your USB drive. >> > >> > Of course, there are lots of hacks you can do to workaround that, but if >> > we go this way, why bother using d-i anyway ? I could just boot from USB >> > and run debootstrap by hand. >> > >> > If we remove USB sticks from etch, then at least people will know they're >> > broken and switch to CDs (or use the dailies). >> >> I don't know how invasive those changes might be. AFAIK Ubuntu already >> does it (Colin?) and wouldn't be too hard to pick the changes from >> them but we would also need RM and Frans approval :( > > I thought you were talking about user workarounds. Yes I was but when I saw that there's no easy workarounds I thought would be possible to try to resolve it "the right way". > Well, Ubuntu uses fstab labels, and they seem to be quite unstable (my > first experience with them resulted in fsck interrupting boot, leaving you > with a root shell). I wouldn't recommend using them (even if we have to drop > support for USB boot). Humm, that's _ugly_ :( -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413836: marked as done (installation-reports)
Your message dated Wed, 07 Mar 2007 14:16:38 +0100 with message-id <[EMAIL PROTECTED]> and subject line Bug#413836: installation-reports has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: installation-reports Boot method: Netinstall CD-image Image version: etch RC1 Date: 28 january 2007 Machine: Processor: p4 ( but installed with i386 ) Memory: Partitions: system, home, swap Output of lspci -nn and lspci -vnn: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ O] Detect network card:[ O] Configure network: [ O] Detect CD: [ O] Load installer modules: [ O] Detect hard drives: [ O] Partition hard drives: [ O] Install base system:[ E] Clock/timezone setup: [ O] User/password setup:[ O] Install tasks: [ E] Install boot loader:[ O] Overall install:[ E] Comments/Problems: Problems with the supplied version of kernel for the i686, but using the i386 to boot and then installing the most recent i686 version worked. Problems with the linux-igd package that reports not being correctly installed but the program works and installs ok - so it works but gives errors Overall installation gave errors but the system is working. --- End Message --- --- Begin Message --- On Wednesday 07 March 2007 13:56, Lars Storm wrote: > Comments/Problems: > Problems with the supplied version of kernel for the i686, but using > the i386 to boot and then installing the most recent i686 version > worked. Not sure what you mean here, but as it was resolved... > Problems with the linux-igd package that reports not being correctly > installed but the program works and installs ok - so it works but gives > errors AFAIK linux-igd is not installed by default, so this is not something for the installer team to look into. Thank you for filing your report. Closing it as there were no real issues. Cheers, FJP --- End Message ---
Bug#389881: RC-ness of this bug
On Wed, Mar 07, 2007 at 09:55:45AM -0300, Otavio Salvador wrote: > > > > With USB, you can't just boot a rescue system and repair a broken install > > from there, because /dev/sda will still be your USB drive. > > > > Of course, there are lots of hacks you can do to workaround that, but if > > we go this way, why bother using d-i anyway ? I could just boot from USB > > and run debootstrap by hand. > > > > If we remove USB sticks from etch, then at least people will know they're > > broken and switch to CDs (or use the dailies). > > I don't know how invasive those changes might be. AFAIK Ubuntu already > does it (Colin?) and wouldn't be too hard to pick the changes from > them but we would also need RM and Frans approval :( I thought you were talking about user workarounds. Well, Ubuntu uses fstab labels, and they seem to be quite unstable (my first experience with them resulted in fsck interrupting boot, leaving you with a root shell). I wouldn't recommend using them (even if we have to drop support for USB boot). -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
> I don't know how invasive those changes might be. AFAIK Ubuntu already > does it (Colin?) and wouldn't be too hard to pick the changes from > them but we would also need RM and Frans approval :( ubuntu already does what? there are four possible soloutions proposed aren't there (labels in fstab and the 3 different /dev/by-* trees)
Bug#389881: RC-ness of this bug
"peter green" <[EMAIL PROTECTED]> writes: >> I don't know how invasive those changes might be. AFAIK Ubuntu already >> does it (Colin?) and wouldn't be too hard to pick the changes from >> them but we would also need RM and Frans approval :( > ubuntu already does what? there are four possible soloutions > proposed aren't there (labels in fstab and the 3 different /dev/by-* > trees) labels on fstab IIRC. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413788: Daily Etch build fails to install on iMac G5 - Ethernet not detected
On Wednesday 07 March 2007 03:47, Mike Hore wrote: > Comments/Problems: The Ethernet connection is not detected. This > machine has an 10/100BASE-T Ethernet port. I suspect the correct > driver hasn't been included in the netinstall image. After network detection failed, please switch to VT2 (on a PC this is alt-F2; I guess option-F2 or something similar on Macs) and enter the following command: lspci -nn | grep Ethernet We need the PCI Id of that device, which looks like [:]. > Since this is a netinstall and the network can't be initialized, I > couldn't proceed beyond this point. This is not true. Netinst CDs contain the full base system, so you can complete an installation without a network card. You would end up with a fairly minimal, but completely functioning system. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Wed, March 7, 2007 13:55, Otavio Salvador said: > I don't know how invasive those changes might be. AFAIK Ubuntu already > does it (Colin?) and wouldn't be too hard to pick the changes from > them but we would also need RM and Frans approval :( initramfs-tools already supports using /dev/disk/by-* entries in fstab. As for the installer, I'm not sure that looking at Ubuntu will help since they use something different than d-i for the regular installs (and I don't know if their d-i based installer has any mount-by-label/uuid/whatever fixes). It would be pretty simple to implement as a late_command script though, quick pseudo-code: --- for each line in /target/etc/fstab; do read device mountpoint fs options dump order if $device matches regex ^/dev/[sh]da[[:digit:]]*$; then for each link in /dev/disk/by-id/*; do if $(readlink "$link") == $device; then device=$link break fi done fi echo "$device $mountpoint $fs $options $dump $order" \ >> /target/etc/fstab.tmp done mv /target/etc/fstab.tmp /target/etc/fstab in-target update-initramfs -u --- I doubt something like this would be accepted though since it would be hard to get sufficient testing for such a large change so late in the game... -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413814: installing Debian GNU/Linux 4.0 on a Power Macintosh G3 Server
Hi Alex! Welcome to an elite minority of those of us who have got this to work! Below are a couple of hints from my own experience in doing this. Rick On Mar 7, 2007, at 5:21 AM, Alex Teclo wrote: Package: installation-reports Boot method: BootX Image version: Debian etch powerpc weekly build Date: February 4th 2007 Machine: Power Macintosh G3 Server Architecture: powerpc Processor: PowerPC 740/750 (G3) Memory: 256 MB Comments/Problems: Here's a feedback of my installation of Debian 4.0 "etch" on a Power Macintosh G3 MiniTower Since it's an oldworld macintosh, it cannot boot from the Debian CDs. I tried booting from floppies, but it never worked, the floppy drive is probably dead. So my solution was to install a legit copy of MacOS 9.2 Here's what I did: - boot into MacOS 9.2 - launch BootX with the files vmlinux and initrd.gz - debian-installer runs smoothly and everything goes well, except one thing: when debian-installer attempts to install quik as a boot loader, the operation fails, and the error messages states that "the partition is not ext2". This error messages seems odd to me. What partition does d-i mean ? The partition where MacOS 9.2 is, which is HFS ? One of the Linux partitions, which are ext3 and not ext2 ? Anyway, isn't ext2 the same thing as ext3 without journalization ? - anyway I'm not worried at all that quik could not install, because I still can boot into MacOS 9.2 and then fire up BootX to boot into Debian GNU/Linux - debian-installer finished up its work and reboots the machine ... and then something goes wrong: I see on the power macintosh a flashing "?" in a floppy. This means "I can't find any operating system to boot" ... ouch ! Now that's a problem. - I tried zapping the PRAM, it did not help. - Finally I took the "Outil Disque Dur" diskette and chose the menu "Fonction" and then "Mise à jour". Pardon my French, this should translate to "Apple Disk Tool", menu "Functions" and then "Update". I don't know the exact wording since I've never used MacOS 9.2 in any other language than French :) ... and *yes*, now I can boot into MacOS 9.2 At some point after the installer has stepped you through choosing language and keyboard, but before running the partitioner, you can choose "go back" from one of the question screens. That will get you to a top-level menu which has an option (near the bottom) of changing the priority level of the questions that the installation asks you. Change it to "low" or "medium". From now on, the installer will return to that top level menu screen between installation steps. It will also ask you more questions than it did at default priority -- just choose the defaults if you don't know the answers. This will give you a chance to prevent it from trying to install the quik bootloader (choose "proceed without installing a boot loader" instead.) This will keep it from messing up the OS-9 bootstrap stuff. When it ejects the CD and pauses one last time before rebooting, switch to VT2 (hit -F2) where you can start up a limited shell by hitting the key. The root partition for the installation is mounted on "/target". have a look around if you like (do "ls", "df", "ps" and anything else non-destructive.) Then do the following stuff: mkdir /target/MacOS # you *may* need to do "modprobe hfs" here (or "modprobe hfsplus"). I don't recall. # In any case, you've got the installer kernel and it's associated modules in the # installer ramdisk, where you currently are, so it will work. mount -t hfsplus /dev/hda6 /target/MacOS # or "-t hfs" if that's what it is. chroot /target # Now you're in "bash" inside the installed system. # If you like, you can poke around a bit now to get a feel for the environment. cp /boot/vmlinux /MacOS/System\ Folder/Linux\ Kernels/vmlinux-new # or whatever you like to call it cp /boot/initrd.img /MacOS/System\ Folder/Linux\ Kernels/initrd- new.img # or whatever exit # now you're back into the installer environment with it's limited shell umount /target/MacOS Then switch back to the VT1 (-F1) console and proceed with the final stages of the installation. It will reboot into MacOS-9.2 and pause at the BootX screen. Enter your "root=/dev/hda9" in the parameter box and choose your new kernel and initrd.img files. Then allow it to boot into Linux. You should be good to go. ... but now when I boot into Debian GNU/Linux with BootX, there is another, more serious problem: When I boot into Debian GNU/Linux with BootX, I can only use the vmlinux and initrd.gz of debian-installer. So instead of booting into my system, I boot into debian-installer. Attempt to solve this problem: start a shell from debian-installer, and chroot to my Debian GNU/Linux system. From there, find the vmlinux and initrd.gz that will allow me to boot directly into Debian GNU/Linux (they are in /boot) an
Bug#413851: missing build-depends on automake1.8
Package: hw-detect Severity: serious debian/rules build AUTOMAKE=automake-1.8 ACLOCAL=aclocal-1.8 \ autoreconf -i -v Can't exec "aclocal-1.8": El fitxer o directori no existeix at /usr/bin/autoreconf line 182. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 182. Can't exec "automake-1.8": El fitxer o directori no existeix at /usr/bin/autoreconf line 183. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 183. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal-1.8 --output=aclocal.m4t Can't exec "aclocal-1.8": El fitxer o directori no existeix at /usr/share/autoconf/Autom4te/FileUtils.pm line 290. autoreconf: failed to run aclocal-1.8: El fitxer o directori no existeix make: *** [configure] Error 1 -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413854: v880 sparc install problem
Package: installation-reports Boot method: CD, netboot Image version: sarge, etch, and daily netboot and CD images Date: March 5-7, 2007 Machine: Sunfire v880 Processor: 4x ultrasparc Memory: 8 GB Partitions: nothing yet. Output of lspci -nn and lspci -vnn: Can't get the box to boot. Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Sarge images give the following error: "error 256 stack underflow" etch and snapshots just display "booting linux..." then nothing more. adding the -p flag gives us: Error: Cheetah error trap taken afsr[ ] Error: TPC[ ] TNPC[ ] TSTATE[ ] Error: M_SYND(0), E_SYND(0), Privileged Error: Highest Priority Error() "Unmapped error from system" Then a bunch of D-cache, I-cache, and E-cache errors. And finally, Kernel Panic – not syncing: Irrecoverable deferred error trap For reference, the gentoo 2006.1 minimal CD (2.6.17 plus gentoo patches) seems to boot ok.
Bug#413855: Apple check is i386-specific
Package: grub-installer Severity: normal Tags: patch Any reason why we shouldn't check for amd64 here ? (other than 64-bit Macs not yet being in the market) Index: debian/isinstallable === --- debian/isinstallable(revision 45613) +++ debian/isinstallable(working copy) @@ -16,7 +16,7 @@ ARCH="$(archdetect)" case $ARCH in -i386/*) +i386/*|amd64/*) MANUFACTURER="$(dmidecode -s system-manufacturer)" case $MANUFACTURER in Apple*) -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: and libtool too
Processing commands for [EMAIL PROTECTED]: > severity 413851 normal Bug#413851: missing build-depends on automake1.8 Severity set to `normal' from `serious' > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413851: and libtool too
severity 413851 normal thanks # sorry, didn't notice this target is svn-only Anyway, you need libtool too: configure.ac:6: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 make: *** [configure] Error 1 -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413851: marked as done (missing build-depends on automake1.8)
Your message dated Wed, 07 Mar 2007 16:53:30 +0100 with message-id <[EMAIL PROTECTED]> and subject line Bug#413851: missing build-depends on automake1.8 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: hw-detect Severity: serious debian/rules build AUTOMAKE=automake-1.8 ACLOCAL=aclocal-1.8 \ autoreconf -i -v Can't exec "aclocal-1.8": El fitxer o directori no existeix at /usr/bin/autoreconf line 182. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 182. Can't exec "automake-1.8": El fitxer o directori no existeix at /usr/bin/autoreconf line 183. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 183. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal-1.8 --output=aclocal.m4t Can't exec "aclocal-1.8": El fitxer o directori no existeix at /usr/share/autoconf/Autom4te/FileUtils.pm line 290. autoreconf: failed to run aclocal-1.8: El fitxer o directori no existeix make: *** [configure] Error 1 -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) --- End Message --- --- Begin Message --- I have no idea where you are getting this from. hw-detect does not use automake. Note: don't bother filing bugs against the few D-I components that do use auto stuff, but don't declare a dependency against them. You only need to run automake once to debootstrap a build. It is not required to build the packages on buildds. --- End Message ---
Bug#413858: archdetect: detect amd64 as a subarch of i386
Package: libdebian-installer4
Version: 0.49
Severity: wishlist
Tags: patch
With this patch, amd64 can be detected as a subarch of i386. e.g.
$ ./archdetect
i386/amd64
This can be useful to conditionalise install of stuff like libc6-amd64,
and possibly other things.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Versions of packages libdebian-installer4 depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
libdebian-installer4 recommends no packages.
-- no debconf information
Index: libdebian-installer/configure.ac
===
--- libdebian-installer/configure.ac (revision 45613)
+++ libdebian-installer/configure.ac (working copy)
@@ -71,6 +71,8 @@
if test -f "$srcdir/src/system/subarch-$DEB_HOST_ARCH_CPU-$DEB_HOST_ARCH_OS.c"; then
SUBARCH_SYSTEM="subarch-$DEB_HOST_ARCH_CPU-$DEB_HOST_ARCH_OS.lo"
+elif test -f "$srcdir/src/system/subarch-$DEB_HOST_ARCH_CPU.c"; then
+ SUBARCH_SYSTEM="subarch-$DEB_HOST_ARCH_CPU.lo"
else
SUBARCH_SYSTEM="subarch-generic.lo"
fi
Index: libdebian-installer/src/system/subarch-i386.c
===
--- libdebian-installer/src/system/subarch-i386.c (revision 0)
+++ libdebian-installer/src/system/subarch-i386.c (revision 0)
@@ -0,0 +1,80 @@
+#include
+
+int check_64bit ();
+
+const char *di_system_subarch_analyze(void)
+{
+ return check_64bit () ? "amd64" : "generic";
+}
+
+/* This amd64 detection code is copied from win32-loader/cpuid/cpuid.c,
+ if you have to modify it, please keep it in sync. */
+
+/**
+ stolen from linux/arch/i386/kernel/cpu/common.c
+ **/
+
+/* Standard macro to see if a specific flag is changeable */
+static inline int
+flag_is_changeable_p (unsigned int flag)
+{
+ unsigned int f1, f2;
+ asm ("pushfl\n\t"
+ "pushfl\n\t"
+ "popl %0\n\t"
+ "movl %0,%1\n\t"
+ "xorl %2,%0\n\t"
+ "pushl %0\n\t"
+ "popfl\n\t"
+ "pushfl\n\t"
+ "popl %0\n\t"
+ "popfl\n\t"
+ : "=&r" (f1), "=&r" (f2)
+ :"ir" (flag));
+ return ((f1 ^ f2) & flag) != 0;
+}
+
+#ifndef X86_EFLAGS_ID
+#define X86_EFLAGS_ID 0x0020 /* CPUID detection flag */
+#endif
+
+/**
+ stolen from linux/include/asm-i386/processor.h
+ **/
+
+static inline unsigned int
+cpuid_eax(unsigned int op)
+{
+ unsigned int eax;
+ __asm__("pushl %%ebx; cpuid; popl %%ebx": "=a" (eax): "0" (op): "cx", "dx");
+ return eax;
+}
+
+static inline unsigned int
+cpuid_edx (unsigned int op)
+{
+ unsigned int eax, edx;
+ __asm__ ("pushl %%ebx; cpuid; popl %%ebx": "=a" (eax), "=d" (edx): "0" (op): "cx");
+ return edx;
+}
+
+/**
+ Based on specs from:
+ - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25481.pdf
+ - http://download.intel.com/design/Xeon/applnots/24161831.pdf
+ **/
+
+int
+check_64bit ()
+{
+ /* probe for CPUID instruction */
+ if (!flag_is_changeable_p (X86_EFLAGS_ID))
+return 0;
+
+ /* probe for 0x8001-level CPUID support */
+ if (cpuid_eax (0x8000) < 0x8001)
+return 0;
+
+ /* probe for 64-bit support */
+ return (cpuid_edx (0x8001) & (1 << 29)) ? 1 : 0;
+}
Index: libdebian-installer/src/system/Makefile.am
===
--- libdebian-installer/src/system/Makefile.am (revision 45613)
+++ libdebian-installer/src/system/Makefile.am (working copy)
@@ -15,6 +15,7 @@
subarch-arm-linux.c \
subarch-armeb-linux.c \
subarch-armel-linux.c \
+ subarch-i386.c \
subarch-m68k-linux.c \
subarch-mips-linux.c \
subarch-mipsel-linux.c \
Bug#413788: Daily Etch build fails to install on iMac G5 - Ethernet not detected
Hi, On Wednesday 07 March 2007 14:46, Frans Pop wrote: > On Wednesday 07 March 2007 03:47, Mike Hore wrote: > > Comments/Problems: The Ethernet connection is not detected. This > > machine has an 10/100BASE-T Ethernet port. I suspect the correct > > driver hasn't been included in the netinstall image. > After network detection failed, please switch to VT2 (on a PC this is > alt-F2; I guess option-F2 or something similar on Macs) and enter the > following command: >lspci -nn | grep Ethernet > We need the PCI Id of that device, which looks like [:]. 0001:03:0f.0 Ethernet controller: Apple Computer Inc. Shasta (Sun GEM) is what another g5 iMac says. http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/powerpc/iso-cd/debian-testing-powerpc-netinst.iso downloaded two hours ago works fine here on an old g3 iMac. regards, Holger pgp1rkOqyKj1v.pgp Description: PGP signature
Bug#413851: closed by Frans Pop <[EMAIL PROTECTED]> (Re: Bug#413851: missing build-depends on automake1.8)
On Wed, Mar 07, 2007 at 03:57:08PM +, Debian Bug Tracking System wrote: > > I have no idea where you are getting this from. hw-detect does not use > automake. Uhm sorry, I mean to file this on libdebian-installer (I was jumping from one place to another, in pursuit of #413858). > Note: don't bother filing bugs against the few D-I components that do use > auto stuff, but don't declare a dependency against them. You only need to > run automake once to debootstrap a build. It is not required to build the > packages on buildds. Ok then. You still could add Build-Depends-Indep though. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413851: closed by Frans Pop <[EMAIL PROTECTED]> (Re: Bug#413851: missing build-depends on automake1.8)
On Wednesday 07 March 2007 17:09, Robert Millan wrote: > Ok then. You still could add Build-Depends-Indep though. I've added a HACKING file with the needed info instead. pgpEvYaWyVyBF.pgp Description: PGP signature
Bug#389881: RC-ness of this bug
On Wed, Mar 07, 2007 at 10:50:46AM -0300, Otavio Salvador wrote: > "peter green" <[EMAIL PROTECTED]> writes: > > >> I don't know how invasive those changes might be. AFAIK Ubuntu already > >> does it (Colin?) and wouldn't be too hard to pick the changes from > >> them but we would also need RM and Frans approval :( > > > ubuntu already does what? there are four possible soloutions > > proposed aren't there (labels in fstab and the 3 different /dev/by-* > > trees) > > labels on fstab IIRC. Ubuntu uses mount by UUID, not labels. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
Robert Millan [ackstorm] wrote: > I urge you to reconsider severity of this problem. There's another situation > that makes it much worse: > > - User boots off USB stick > - sda is USB, sdb is SCSI or SATA > - GRUB install on (hd0) (i.e. sda) fails. > - Manual repairing is not possible, because if you boot a rescue system > off USB stick, root disk will still be sdb. Is this theoretical with SATA, or have you reproduced it? The usb sticks include sata-modules as well as usb-modules, so AFAICS, hardware detection should happen in the same order when booting from the usb stick as booting from eg, netboot. And I don't understand your report about problems with SCSI either, since the USB stick also includes all SCSI modules. -- see shy jo signature.asc Description: Digital signature
Bug#389881: RC-ness of this bug
On Wed, Mar 07, 2007 at 12:28:09PM -0500, Joey Hess <[EMAIL PROTECTED]> wrote: > Robert Millan [ackstorm] wrote: > > I urge you to reconsider severity of this problem. There's another > > situation > > that makes it much worse: > > > > - User boots off USB stick > > - sda is USB, sdb is SCSI or SATA > > - GRUB install on (hd0) (i.e. sda) fails. > > - Manual repairing is not possible, because if you boot a rescue system > > off USB stick, root disk will still be sdb. > > Is this theoretical with SATA, or have you reproduced it? > > The usb sticks include sata-modules as well as usb-modules, so AFAICS, > hardware detection should happen in the same order when booting from the > usb stick as booting from eg, netboot. > > And I don't understand your report about problems with SCSI either, > since the USB stick also includes all SCSI modules. It sound pretty simple, in netboot case, there is no usb stick to take sda... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 413875 to installation-reports, severity of 413875 is normal, tagging 413875
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.27 > reassign 413875 installation-reports Bug#413875: 1 - Install the Debian with DVD 4.0 2 - Select a mirror 3 - The bug born in the middle of the Installing Bug reassigned from package `base' to `installation-reports'. > severity 413875 normal Bug#413875: 1 - Install the Debian with DVD 4.0 2 - Select a mirror 3 - The bug born in the middle of the Installing Severity set to `normal' from `critical' > tags 413875 moreinfo Bug#413875: 1 - Install the Debian with DVD 4.0 2 - Select a mirror 3 - The bug born in the middle of the Installing There were no tags set. Tags added: moreinfo > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#380226: NTFS (partition) not recreated correctly after resize:incorrect start sector
On Fri, Mar 02, 2007 at 06:11:27PM +0100, Frans Pop wrote: > On Friday 02 March 2007 03:11, Ben Hutchings wrote: > > What is the intended difference in semantics between RESIZE_PARTITION > > and VIRTUAL_RESIZE_PARTITION? In the resize_partition() function these > > are distinguished by the open_filesystem flag which implied to me that > > in the latter case we wouldn't expect to find a filesystem in the > > partition at all. Clearly that's not the case here. > > I have no idea to be honest. There is a comment with the functions > VIRTUAL_RESIZE_PARTITION and GET_VIRTUAL_RESIZE_RANGE that says they > "are undocumented and should disappear", but I have no idea beyond that. > > Could it be that a virtual partition is one that has been created or > modified, but has not yet been committed to disk? This happens quite a > lot in partman. Frans is correct. Specifically, a virtual partition is one whose geometry does not match any of the partition geometries existing on disk. You can modify things like a partition's mount point without rendering it virtual. Resizing a partition is (at present) committed immediately and so doesn't produce a virtual partition, at least not at any time when the rest of partman is in a position to notice. However, if you've just created a partition in partman and then resize it, there is clearly no filesystem there and it can be resized simply by changing the geometry of the partition in parted_server (and the associated files in /var/lib/partman/devices) without having to worry about any filesystem resizing. *However*, all of this is complicated by the handling of NTFS in partman (and I'm currently contemplating handling ext2 and ext3 the same way since parted can't handle the resize_inode feature on those filesystems, but that's another story). The VIRTUAL_RESIZE_PARTITION and GET_VIRTUAL_RESIZE_RANGE functions implement equivalents of RESIZE_PARTITION and GET_RESIZE_RANGE, but force parted_server to resize only the partition and not the filesystem. The reason that they were introduced is that parted can detect the presence of NTFS (probe succeeds), but it has no idea how to resize it. partman-partitioning/resize.sh therefore forcibly disables any attempts by parted_server/libparted to resize the filesystem; instead they need to resize the partition but leave it up to ntfsresize to resize the filesystem. Thus, open_filesystem is to be interpreted as a verb in the imperative voice; if it's false, resize_partition is being instructed not to attempt to ped_file_system_open the filesystem (a prerequisite for ped_file_system_resize). At this point you might ask (and I did) how shrinking an NTFS partition manages to work with Ben's patch. The answer is that there's some unbelievably nasty code in partman-partitioning/resize.sh which checks whether it's shrinking or expanding the filesystem. If it's expanding it, it does VIRTUAL_RESIZE_PARTITION, COMMIT [0], ntfsresize; if it's shrinking it, it does COMMIT, ntfsresize --size, VIRTUAL_RESIZE_PARTITION, and then another ntfsresize without --size just to make sure it's right. [0] Unnecessarily, since VIRTUAL_RESIZE_PARTITION already does a ped_disk_commit. This is probably a leftover from something or other. So, given these required semantics, I think Ben's analysis is correct. The business about possibly detecting the broken remnants of a filesystem is true, but in practice (and somewhat counterintuitively) VIRTUAL_RESIZE_PARTITION is only ever called when a filesystem is known to be present on disk, i.e. when VIRTUAL returns false. Some of this should probably end up as comments in the code. > > It should be clear that all the new code (aside from the error check) > > only runs in the currently broken case, so this does not affect > > resizing ext2 etc. And none of it is running below > > maximize_extended_partition(). > > This new patch works again. I've asked Colin Watson if he can review your > patch. Within the D-I team he currently has the best grasp of what > happens in this area of partman. The above is about the best I can do. I don't know the ped_alignment_*, ped_geometry_*, or ped_constraint_* functions well enough to review the specifics of the calls to those functions, but I believe the logic is correct. Incidentally, I noted to Frans on IRC that his call to sleep in partman-partitioning should be replaced with update-dev, which is the proper way in d-i to wait for udev to settle or to ask userdevfs to update itself. (The latter is of course not very relevant in the case of NTFS.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-base_105_amd64.changes
partman-base_105_amd64.changes uploaded successfully to localhost along with the files: partman-base_105.dsc partman-base_105.tar.gz partman-base_105_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-lvm_52_amd64.changes
partman-lvm_52_amd64.changes uploaded successfully to localhost along with the files: partman-lvm_52.dsc partman-lvm_52.tar.gz partman-lvm_52_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-md_33_amd64.changes
partman-md_33_amd64.changes uploaded successfully to localhost along with the files: partman-md_33.dsc partman-md_33.tar.gz partman-md_33_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-partitioning_47_amd64.changes
partman-partitioning_47_amd64.changes uploaded successfully to localhost along with the files: partman-partitioning_47.dsc partman-partitioning_47.tar.gz partman-partitioning_47_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-lvm_52_amd64.changes ACCEPTED
Accepted: partman-lvm_52.dsc to pool/main/p/partman-lvm/partman-lvm_52.dsc partman-lvm_52.tar.gz to pool/main/p/partman-lvm/partman-lvm_52.tar.gz partman-lvm_52_all.udeb to pool/main/p/partman-lvm/partman-lvm_52_all.udeb Override entries for your package: partman-lvm_52.dsc - source debian-installer partman-lvm_52_all.udeb - standard debian-installer Announcing to debian-devel-changes@lists.debian.org Closing bugs: 413183 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-base_105_amd64.changes ACCEPTED
Accepted: partman-base_105.dsc to pool/main/p/partman-base/partman-base_105.dsc partman-base_105.tar.gz to pool/main/p/partman-base/partman-base_105.tar.gz partman-base_105_amd64.udeb to pool/main/p/partman-base/partman-base_105_amd64.udeb Override entries for your package: partman-base_105.dsc - source debian-installer partman-base_105_amd64.udeb - standard debian-installer Announcing to debian-devel-changes@lists.debian.org Closing bugs: 380226 412769 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-md_33_amd64.changes ACCEPTED
Accepted: partman-md_33.dsc to pool/main/p/partman-md/partman-md_33.dsc partman-md_33.tar.gz to pool/main/p/partman-md/partman-md_33.tar.gz partman-md_33_all.udeb to pool/main/p/partman-md/partman-md_33_all.udeb Override entries for your package: partman-md_33.dsc - source debian-installer partman-md_33_all.udeb - standard debian-installer Announcing to debian-devel-changes@lists.debian.org Closing bugs: 397973 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-partitioning_47_amd64.changes ACCEPTED
Accepted: partman-partitioning_47.dsc to pool/main/p/partman-partitioning/partman-partitioning_47.dsc partman-partitioning_47.tar.gz to pool/main/p/partman-partitioning/partman-partitioning_47.tar.gz partman-partitioning_47_amd64.udeb to pool/main/p/partman-partitioning/partman-partitioning_47_amd64.udeb Override entries for your package: partman-partitioning_47.dsc - source debian-installer partman-partitioning_47_amd64.udeb - optional debian-installer Announcing to debian-devel-changes@lists.debian.org Closing bugs: 379835 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397973: marked as done ([powerpci/mac] partman-md appears to not write back the raid flag to partitions.)
Your message dated Wed, 07 Mar 2007 22:02:14 + with message-id <[EMAIL PROTECTED]> and subject line Bug#397973: fixed in partman-md 33 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: partman-md Version: 30 Severity: important Well, there seems to be a problem in how partman/partman-md writes back the RAID flag on mac partition tables. When using the 1.7.1-3 parted, it should work, but somehow partman doesn't actually writes the RAID flag back to the partition, and thus partman-md doesn't find the raid partitions. When going in the console, and invoking parted by hand on the partitions, the flags are indeed not there, even though the partitions where marked as raid partitions. Setting them by hand in parted, and then continuing the raid setup stuff, will make it find the partitions without problem. So this bug is indeed in partman and/or partman-md. I had a look at partman-md, but wasn't able to find anything obvious or sligthly less so. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) --- End Message --- --- Begin Message --- Source: partman-md Source-Version: 33 We believe that the bug you reported is fixed in the latest version of partman-md, which is due to be installed in the Debian FTP archive: partman-md_33.dsc to pool/main/p/partman-md/partman-md_33.dsc partman-md_33.tar.gz to pool/main/p/partman-md/partman-md_33.tar.gz partman-md_33_all.udeb to pool/main/p/partman-md/partman-md_33_all.udeb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Frans Pop <[EMAIL PROTECTED]> (supplier of updated partman-md package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Mar 2007 22:49:26 +0100 Source: partman-md Binary: partman-md Architecture: source all Version: 33 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Frans Pop <[EMAIL PROTECTED]> Description: partman-md - Add to partman support for MD (udeb) Closes: 397973 Changes: partman-md (33) unstable; urgency=low . [ David Härdeman ] * Make sure that the lvm, raid and swap flags are used in a mutually exclusive manner. Closes: #397973. Files: 94855f9437a9284d2007e70680f585d9 621 debian-installer standard partman-md_33.dsc 16211acd68dd1afeea3ecd92a0802d33 43501 debian-installer standard partman-md_33.tar.gz 8a701fb2cde26ded4a4805f539e6bbc7 28998 debian-installer standard partman-md_33_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF7zOWgm/Kwh6ICoQRAgMYAJ0Uvo4xl/lusMKy/4XJNwKfDQX+rQCdGt+A Q0KY6HvrH8k3x+zjvPhplu8= =pBmD -END PGP SIGNATURE- --- End Message ---
Bug#380226: marked as done (NTFS (partition) not recreated correctly after resize:incorrect start sector)
Your message dated Wed, 07 Mar 2007 22:02:13 + with message-id <[EMAIL PROTECTED]> and subject line Bug#380226: fixed in partman-base 105 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: ntfsprogs Version: 1.12.1-1 Severity: critical Justification: causes serious data loss Tags: d-i After a resize using Debian Installer of an NTFS partition created with Windows Vista Beta 2, I found that the partition was no longer usable. I have checked that this really is an issue by doing manual resizes of: - an NTFS (1.2) partition created by installing Windows 2000 - an NTFS (3.1) partition created by installing Windows Vista Beta 2 The two are completely similar, except that the first is successful and the second leads to corruption. The corruption only becomes clear _after_ the physical partition is resized too; resizing the partition back to its original size does not get the partition back. ntfsfix does not help either. Note that during the manual resize operation I used fdisk, but the installer uses libparted; the corruption occurs with both. Logs for the resize of both NTFS partitions are attached and clearly show the problem. I noticed that a 1.13.1 release is available, but cannot tell from the changelog if that would fix this issue. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-generic Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages ntfsprogs depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libfuse22.5.3-2.1 Filesystem in USErspace library ii libntfs81.12.1-1 library that provides common NTFS ntfsprogs recommends no packages. -- no debconf information debian:~# ntfsresize -i /dev/sda1 ntfsresize v1.12.1 (libntfs 8:1:0) Device name: /dev/sda1 NTFS volume version: 1.2 Cluster size : 4096 bytes Current volume size: 20974428672 bytes (20975 MB) Current device size: 20974431744 bytes (20975 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 410 MB (2.0%) Collecting resizing constraints ... You might resize at 409182208 bytes or 410 MB (freeing 20565 MB). Please make a test run using both the -n and -s options before real resizing! debian:~# ntfsresize -s 9G /dev/sda1 ntfsresize v1.12.1 (libntfs 8:1:0) Device name: /dev/sda1 NTFS volume version: 1.2 Cluster size : 4096 bytes Current volume size: 20974428672 bytes (20975 MB) Current device size: 20974431744 bytes (20975 MB) New volume size: 893856 bytes (9000 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 410 MB (2.0%) Collecting resizing constraints ... Needed relocations : 99052 (406 MB) WARNING: Every sanity check passed and only the dangerous operations left. Make sure that important data has been backed up! Power outage or computer crash may result major data loss! Are you sure you want to proceed (y/[n])? y Schedule chkdsk for NTFS consistency check at Windows boot time ... Resetting $LogFile ... (this might take a while) Relocating needed data ... 100.00 percent completed Updating $BadClust file ... Updating $Bitmap file ... Updating Boot record ... Syncing device ... Successfully resized NTFS on device '/dev/sda1'. You can go on to shrink the device for example with Linux fdisk. IMPORTANT: When recreating the partition, make sure that you 1) create it at the same disk sector (use sector as the unit!) 2) create it with the same partition type (usually 7, HPFS/NTFS) 3) do not make it smaller than the new NTFS filesystem size 4) set the bootable flag for the partition if it existed before Otherwise you won't be able to access NTFS or can't boot from the disk! If you make a mistake and don't have a partition table backup then you can recover the partition table by TestDisk or Parted's rescue mode. debian:~# ntfsresize -i -f /dev/sda1 ntfsresize v1.12.1 (libntfs 8:1:0) Device name: /dev/sda1 NTFS volume version: 1.2 Cluster size : 4096 bytes Current volume size: 893856 bytes (9000 MB) Current device size: 20974431744 bytes (20975 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 409 MB (4.5%) Collecting resizing constraints ... You might resize at 408817664 bytes
Bug#413183: marked as done ([powerpci/mac] partman-md appears to not write back the raid flag to partitions.)
Your message dated Wed, 07 Mar 2007 22:02:13 + with message-id <[EMAIL PROTECTED]> and subject line Bug#413183: fixed in partman-lvm 52 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: partman-md Version: 30 Severity: important Well, there seems to be a problem in how partman/partman-md writes back the RAID flag on mac partition tables. When using the 1.7.1-3 parted, it should work, but somehow partman doesn't actually writes the RAID flag back to the partition, and thus partman-md doesn't find the raid partitions. When going in the console, and invoking parted by hand on the partitions, the flags are indeed not there, even though the partitions where marked as raid partitions. Setting them by hand in parted, and then continuing the raid setup stuff, will make it find the partitions without problem. So this bug is indeed in partman and/or partman-md. I had a look at partman-md, but wasn't able to find anything obvious or sligthly less so. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) --- End Message --- --- Begin Message --- Source: partman-lvm Source-Version: 52 We believe that the bug you reported is fixed in the latest version of partman-lvm, which is due to be installed in the Debian FTP archive: partman-lvm_52.dsc to pool/main/p/partman-lvm/partman-lvm_52.dsc partman-lvm_52.tar.gz to pool/main/p/partman-lvm/partman-lvm_52.tar.gz partman-lvm_52_all.udeb to pool/main/p/partman-lvm/partman-lvm_52_all.udeb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Frans Pop <[EMAIL PROTECTED]> (supplier of updated partman-lvm package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Mar 2007 22:48:58 +0100 Source: partman-lvm Binary: partman-lvm Architecture: source all Version: 52 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Frans Pop <[EMAIL PROTECTED]> Description: partman-lvm - Adds support for LVM to partman (udeb) Closes: 413183 Changes: partman-lvm (52) unstable; urgency=low . [ David Härdeman ] * Make sure that the lvm, raid and swap flags are used in a mutually exclusive manner. Closes: #413183. Files: ba11d6dc1514d23f1cda3259aa688fb7 694 debian-installer standard partman-lvm_52.dsc ab0c90b44b2d28165f200cae97c12304 177342 debian-installer standard partman-lvm_52.tar.gz c753356aca228837e9adb02ff9768a20 194470 debian-installer standard partman-lvm_52_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF7zOWgm/Kwh6ICoQRAvi6AJ4z2pUCyxpEC6WK+m6QLKpkdOwmFACaA4oH R7gyEaOt47oJi+ouDZ3useg= =9nfF -END PGP SIGNATURE- --- End Message ---
Bug#379835: marked as done (Windows Vista fails to boot after resizing in d-i)
Your message dated Wed, 07 Mar 2007 22:02:15 + with message-id <[EMAIL PROTECTED]> and subject line Bug#379835: fixed in partman-partitioning 47 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: ntfsprogs Version: 1.12.1-1 Severity: critical Justification: causes serious data loss Tags: d-i After a resize using Debian Installer of an NTFS partition created with Windows Vista Beta 2, I found that the partition was no longer usable. I have checked that this really is an issue by doing manual resizes of: - an NTFS (1.2) partition created by installing Windows 2000 - an NTFS (3.1) partition created by installing Windows Vista Beta 2 The two are completely similar, except that the first is successful and the second leads to corruption. The corruption only becomes clear _after_ the physical partition is resized too; resizing the partition back to its original size does not get the partition back. ntfsfix does not help either. Note that during the manual resize operation I used fdisk, but the installer uses libparted; the corruption occurs with both. Logs for the resize of both NTFS partitions are attached and clearly show the problem. I noticed that a 1.13.1 release is available, but cannot tell from the changelog if that would fix this issue. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-generic Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages ntfsprogs depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libfuse22.5.3-2.1 Filesystem in USErspace library ii libntfs81.12.1-1 library that provides common NTFS ntfsprogs recommends no packages. -- no debconf information debian:~# ntfsresize -i /dev/sda1 ntfsresize v1.12.1 (libntfs 8:1:0) Device name: /dev/sda1 NTFS volume version: 1.2 Cluster size : 4096 bytes Current volume size: 20974428672 bytes (20975 MB) Current device size: 20974431744 bytes (20975 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 410 MB (2.0%) Collecting resizing constraints ... You might resize at 409182208 bytes or 410 MB (freeing 20565 MB). Please make a test run using both the -n and -s options before real resizing! debian:~# ntfsresize -s 9G /dev/sda1 ntfsresize v1.12.1 (libntfs 8:1:0) Device name: /dev/sda1 NTFS volume version: 1.2 Cluster size : 4096 bytes Current volume size: 20974428672 bytes (20975 MB) Current device size: 20974431744 bytes (20975 MB) New volume size: 893856 bytes (9000 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 410 MB (2.0%) Collecting resizing constraints ... Needed relocations : 99052 (406 MB) WARNING: Every sanity check passed and only the dangerous operations left. Make sure that important data has been backed up! Power outage or computer crash may result major data loss! Are you sure you want to proceed (y/[n])? y Schedule chkdsk for NTFS consistency check at Windows boot time ... Resetting $LogFile ... (this might take a while) Relocating needed data ... 100.00 percent completed Updating $BadClust file ... Updating $Bitmap file ... Updating Boot record ... Syncing device ... Successfully resized NTFS on device '/dev/sda1'. You can go on to shrink the device for example with Linux fdisk. IMPORTANT: When recreating the partition, make sure that you 1) create it at the same disk sector (use sector as the unit!) 2) create it with the same partition type (usually 7, HPFS/NTFS) 3) do not make it smaller than the new NTFS filesystem size 4) set the bootable flag for the partition if it existed before Otherwise you won't be able to access NTFS or can't boot from the disk! If you make a mistake and don't have a partition table backup then you can recover the partition table by TestDisk or Parted's rescue mode. debian:~# ntfsresize -i -f /dev/sda1 ntfsresize v1.12.1 (libntfs 8:1:0) Device name: /dev/sda1 NTFS volume version: 1.2 Cluster size : 4096 bytes Current volume size: 893856 bytes (9000 MB) Current device size: 20974431744 bytes (20975 MB) Checking filesystem consistency ... 100.00 percent completed Accounting clusters ... Space in use : 409 MB (4.5%) Collecting resizing constraints ... You might resize at 408817664
Bug#412769: marked as done (partman-base: parted_server creates FIFOs with wrong mode)
Your message dated Wed, 07 Mar 2007 22:02:13 + with message-id <[EMAIL PROTECTED]> and subject line Bug#412769: fixed in partman-base 105 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: partman-base Version: 103.1 Severity: minor parted_server.c contains the line: 2125:status = mkfifo(name, 0x644); The mode was presumably meant to be 0644, not 0x644. Not that it makes much difference given all of partman runs as root. Ben. --- End Message --- --- Begin Message --- Source: partman-base Source-Version: 105 We believe that the bug you reported is fixed in the latest version of partman-base, which is due to be installed in the Debian FTP archive: partman-base_105.dsc to pool/main/p/partman-base/partman-base_105.dsc partman-base_105.tar.gz to pool/main/p/partman-base/partman-base_105.tar.gz partman-base_105_amd64.udeb to pool/main/p/partman-base/partman-base_105_amd64.udeb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Frans Pop <[EMAIL PROTECTED]> (supplier of updated partman-base package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Mar 2007 22:47:26 +0100 Source: partman-base Binary: partman-base Architecture: source amd64 Version: 105 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Frans Pop <[EMAIL PROTECTED]> Description: partman-base - Partition the storage devices (partman) (udeb) Closes: 380226 412769 Changes: partman-base (105) unstable; urgency=low . * Correct mode in mkfifo call. Thanks to Ben Hutchings. Closes: #412769. * Fix the way libparted is called when resizing partitions with a file system that libparted does not support. Many thanks to Ben Hutchings for the patch. Closes: #380226. Files: 947c016f5b0bfcd7ae930958dfb28866 767 debian-installer standard partman-base_105.dsc 2f2d6eade3002d20d93c144807180672 173736 debian-installer standard partman-base_105.tar.gz 390784e2b037148dbe123e9228507484 163182 debian-installer standard partman-base_105_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF7zOWgm/Kwh6ICoQRAsR9AJwOuiM8QwUai5qfpHIvsN+ZGIcYRQCgjHiT LFZl99LNFGxpxk8Y1cwQiBM= =u0Ch -END PGP SIGNATURE- --- End Message ---
Bug#413931: d-i missing ide modules
Package: installation-reports
Boot method: CD
Image version: debian-31r5-i386-netinst.iso, from usc.edu mirror, md5sum good
Date: 7 Mar 2007, 22:00 UTC
Machine: Old Gateway, Tabor{2,3} motherboard
Processor: P3 (Katmai) 596MHz
Memory: 384 MB ECC
Partitions: none
Output of lspci and lspci -n: /bin/sh: lspci: not found
dmesg says:
: PCI: Probing PCI hardware (bus 00)
: PCI: Using IRQ router PIIX/ICH [8086/7110] at :00:07.0
: PCI: Found IRQ 9 for device :00:07.0
: PCI: Sharing IRQ 9 with :00:10.0
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot worked:[O]
Configure network HW: [O]
Config network: [O]
Detect CD: [O]
Load installer modules: [O]
Detect hard drives: [O] looks correct in dmesg
Partition hard drives: [ ]
Create file systems:[ ]
Mount partitions: [ ]
Install base system:[ ]
Install boot loader:[ ]
Reboot: [ ]
Comments/Problems:
Missing modules for ide.
Running as expert26 installation.
The last installer screen before starting disk partitioning says this:
: [.] Detect hardware
: Unable to load some modules
: Linux kernel modules needed to drive some of your hardware are not
: available yet. Simply proceeding with the install may make these
: modules available later.
:
: The unavailable modules, and the devices that need them are: agpgart
: (Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge), ide-scsi
: (Linux IDE-SCSI emulation layer), ide-mod (Linux IDE driver),
: ide-probe-mod (Linux IDE probe driver), ide-detect (Linux IDE
: detection), ide-floppy (Linux IDE floppy)
:
:
Selecting Continue brings us to the start of partitioning and making
filesystems.
As I searched Google's archives of various debian lists for this problem,
the recurrent answer seems to be that this is an informative message only,
and the modules will be loaded later. This seems to be contradicted by
this section from the Installation Guide:
: 6.3.2.B Partitioning and Mount Point Selection
:
:At this time, after hardware detection has been executed a final time,
:debian-installer should be at its full strength, customized for the
:user's needs and ready to do some real work. As the title of this
:section indicates, the main task of the next few components lies in
:partitioning your disks, creating filesystems, assigning mountpoints
:and optionally configuring closely related issues like LVM or RAID
:devices.
The text of the error screen, and the text of the Installation Guide,
seem to be saying clearly that these modules are needed to drive the IDE
hardware, and this was the last chance to automatically find them, and it
did not succeed.
I am _very_ reluctant to proceed to partitioning and file-system making,
for this reason: A week ago I tried installing on this machine, using the
3.1R4 netinst CD and the original 4MB Seagate IDE disk that came with this
machine. I saw the same errors about missing modules, but proceeded anyway.
The installer pretended to partition the disk, and pretended to install some
stuff for a while, then croaked with an error about the disk being Busy.
After much investigating of the disk with Knoppix and smartctl, it seemed
that the disk was permanently bad, giving errors on self-tests, unable
to successfully write to some parts of it, and hanging busy. I replaced it
with 2 nice new high-capacity IDE Ultra-ATA disks, and downloaded the newest
netinst 3.1R5 CD, and tried again today.
I don't want to destroy my new disks by trying to partition them when the
installer is plainly telling me it doesn't have the necessary kernel modules
to do the job. Is there some way I can supply these missing modules to
the installer ? Should I try to partition/mk*fs them from Knoppix ?
Is there any other documentation I should read ?
Please advise.
Note: I am subscribed to the debian-bugs-dist list.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413931: d-i missing ide modules
On Wednesday 07 March 2007 23:58, Lou Poppler wrote: > Comments/Problems: > : The unavailable modules, and the devices that need them are: agpgart > : (Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge), ide-scsi > : (Linux IDE-SCSI emulation layer), ide-mod (Linux IDE driver), > : ide-probe-mod (Linux IDE probe driver), ide-detect (Linux IDE > : detection), ide-floppy (Linux IDE floppy) > The text of the error screen, and the text of the Installation Guide, > seem to be saying clearly that these modules are needed to drive the > IDE hardware, and this was the last chance to automatically find them, > and it did not succeed. No, the message is just informing you that those modules those modules are associated with your hardware, but have not been loaded. To be honest, that message is there more for debugging than for signalling any real issues. Unfortunately it tends to be more confusing than helpful to users. > I am _very_ reluctant to proceed to partitioning and file-system > making, for this reason: A week ago I tried installing on this > machine, using the 3.1R4 netinst CD and the original 4MB Seagate IDE > disk that came with this machine. I saw the same errors about missing > modules, but proceeded anyway. The installer pretended to partition the > disk, and pretended to install some stuff for a while, then croaked > with an error about the disk being Busy. After much investigating of > the disk with Knoppix and smartctl, it seemed that the disk was > permanently bad, giving errors on self-tests, unable to successfully > write to some parts of it, and hanging busy. I replaced it with 2 nice > new high-capacity IDE Ultra-ATA disks, and downloaded the newest > netinst 3.1R5 CD, and tried again today. It is extremely unlikely that your disk problems were in any way caused by the installer, and certainly not by the presence of this message. Note that the message would not even be shown during a regular (non-expert) installation. That would be unthinkable if it contained any real information. If you select "manual partitioning" in the first dialog of the partitioner and the next screen shows your harddisk and the existing partitions that are on it, there is nothing to worry about. > I don't want to destroy my new disks by trying to partition them when > the installer is plainly telling me it doesn't have the necessary > kernel modules to do the job. As I said, it is _not_ saying that. The harddisk problems must have been a latent hardware problem that was just exposed by the intensive writing that is done during an installation. Given the age of your system it should be well supported by Sarge. If it were a recent system I'd advice to install Etch instead of Sarge, but for a Pentium 3 box there is no reason for that. Hope this gives you the confidence to proceed. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Wed, Mar 07, 2007 at 03:18:19PM +0100, David Härdeman wrote:
On Wed, March 7, 2007 13:55, Otavio Salvador said:
I don't know how invasive those changes might be. AFAIK Ubuntu already
does it (Colin?) and wouldn't be too hard to pick the changes from
them but we would also need RM and Frans approval :(
initramfs-tools already supports using /dev/disk/by-* entries in fstab. As
for the installer, I'm not sure that looking at Ubuntu will help since
they use something different than d-i for the regular installs (and I
don't know if their d-i based installer has any
mount-by-label/uuid/whatever fixes).
It would be pretty simple to implement as a late_command script though,
quick pseudo-code:
...
I've attached a patch which implements persistent device names in
partman by checking for devices which are mounted under /target and
which have a suitable link in /dev/disk/by-id/*
For each device that is found, /target/etc/fstab is modified
appropriately.
I've done one test install using the patch and it sucessfully changed
/dev/sda1 to /dev/disk/by-id/ata-QEMU_HARDDISK_QM1-part1 in
/target/etc/fstab, it's currenlty busy installing the base system.
I believe this patch would fix #225802, #295134, #308565, #389881
--
David Härdeman
Index: debian/changelog
===
--- debian/changelog (revision 45633)
+++ debian/changelog (working copy)
@@ -1,3 +1,10 @@
+partman-target (49) UNRELEASED; urgency=low
+
+ * Add script to use persistent device nodes in /etc/fstab where
+possible
+
+ -- David Härdeman <[EMAIL PROTECTED]> Thu, 8 Mar 2007 00:17:24 +0100
+
partman-target (48) unstable; urgency=low
[ Updated translations ]
Index: finish.d/fstab_persistent
===
--- finish.d/fstab_persistent (revision 0)
+++ finish.d/fstab_persistent (revision 0)
@@ -0,0 +1,47 @@
+#!/bin/sh
+
+[ -f /target/etc/fstab ] || exit 0
+fstab=$(
+ cat /target/etc/fstab |
+ while read line; do
+ # Make sure this is a proper entry
+ if echo "$line" | grep -q "^[[:space:]]*$\|^#"; then
+ echo "$line"
+ continue
+ fi
+
+ # Parse entry
+ echo -n "$line" > /tmp/partman-target
+ read fs mp type options dump pass < /tmp/partman-target
+ rm -f /tmp/partman-target
+
+ # Ignore devices not mounted under /target
+ if [ "$mp" = "/" ]; then
+ tmpmp="/target"
+ else
+ tmpmp="/target$mp"
+ fi
+ if ! grep -q " $tmpmp " /proc/mounts; then
+ echo "$line"
+ continue
+ fi
+
+ # See if we can find a persistent device name
+ for link in /dev/disk/by-id/*; do
+ linktarget=$(mapdevfs $(readlink -f "$link"))
+ if [ "$linktarget" = "$fs" ]; then
+break
+ fi
+ linktarget=
+ done
+ if [ -z "$linktarget" ]; then
+ echo "$line"
+ continue
+ fi
+
+ printf "%-15s %-15s %-7s %-15s %-7s %s\n" "${link}" "${mp}" "$type" "$options" "$dump" "$pass"
+ done
+)
+
+echo "$fstab" > /target/etc/fstab
+exit 0
Property changes on: finish.d/fstab_persistent
___
Name: svn:executable
+ *
Index: finish.d/_numbers
===
--- finish.d/_numbers (revision 45633)
+++ finish.d/_numbers (working copy)
@@ -4,3 +4,4 @@
40 fstab_hd_entries
50 fstab_removable_media_entries
95 reformat_after_restart
+98 fstab_persistent
lvm volume group name
Hi, Can you override the default lvm volume name used by d-i using a preseed file (priority=critical)? By default it seems to use the hostname which isn't what I want and would like to override it to vg00 for instance. I found this entry somewhere by googling but it doesn't seem to have the desired effect: # Volume group name: d-i lvmcfg/vgcreate_namestring Any clues/ideas? Regards, Andrew
Bug#389881: RC-ness of this bug
On Thu, Mar 08, 2007 at 12:44:05AM +0100, David Härdeman wrote: > >initramfs-tools already supports using /dev/disk/by-* entries in fstab. As > >for the installer, I'm not sure that looking at Ubuntu will help since > >they use something different than d-i for the regular installs (and I > >don't know if their d-i based installer has any > >mount-by-label/uuid/whatever fixes). > >It would be pretty simple to implement as a late_command script though, > >quick pseudo-code: > >... > I've attached a patch which implements persistent device names in > partman by checking for devices which are mounted under /target and > which have a suitable link in /dev/disk/by-id/* > For each device that is found, /target/etc/fstab is modified > appropriately. Thanks for the patch, David. I don't believe this should be changed for etch at this point in the release process, and that's speaking as someone who's run into this problem myself with SCSI device renumbering -- it's awkward and annoying to have to manually fiddle your boot config because a USB device is no longer registering as /dev/sda, and it's not in line with the quality of experience that our users have come to expect when installing Debian >:), but I don't think that makes anything unreleasable. Changing the fstab handling at this point could break many other scenarios that we haven't thought of and tested for, whereas the USB issue can be documented in the errata. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Bug#389881: RC-ness of this bug
> I don't believe this should be changed for etch at this point in > the release > process, and that's speaking as someone who's run into this problem myself > with SCSI device renumbering -- it's awkward and annoying to have to > manually fiddle your boot config because a USB device is no longer > registering as /dev/sda, and it's not in line with the quality of > experience > that our users have come to expect when installing Debian >:), but I don't > think that makes anything unreleasable. Changing the fstab > handling at this > point could break many other scenarios that we haven't thought of > and tested > for, whereas the USB issue can be documented in the errata. what about writing out a /etc/fstab.by-id file with the header below followed by a copy of thier normal fstab changed to use the /dev/disk/by-id/ syntax? that way we could instruct newbies who run into this problem to just boot in rescue mode and run "cp /etc/fstab.by-id /etc/fstab". that seems to be much simpler to explain to people than a manual fixup whilst not risking breakage for anyone who doesn't run into the device rearangement problem. header for /etc/fstab.by-id # /etc/fstab.by-id # # This file was generated by the debian installer. It represents the same # partition structure as the /etc/fstab that the installer generated but # references disks by thier "id" rather than by thier traditional unix names # which are prone to change on first boot after installation or on changing # hardware. # # This structure is not used by default for etch installations (but probablly # will be for lenny) because of the possibility of regressions from such a # major change late in the release process. If you wish to use it and have not # modified /etc/fstab after installation you may copy this file to "/etc/fstab" #
Re: Bug#413931: d-i missing ide modules
On Thu, 8 Mar 2007, Frans Pop wrote: On Wednesday 07 March 2007 23:58, Lou Poppler wrote: > The text of the error screen, and the text of the Installation Guide, > seem to be saying clearly that these modules are needed to drive the > IDE hardware, and this was the last chance to automatically find them, > and it did not succeed. No, the message is just informing you that those modules those modules are associated with your hardware, but have not been loaded. To be honest, that message is there more for debugging than for signalling any real issues. Unfortunately it tends to be more confusing than helpful to users. Yes, confusing and scary. Perhaps the words "needed" and "need" are too strong in this message. I leave this bug open only to allow d-i maintainers to consider if they want to reword it. [...] It is extremely unlikely that your disk problems were in any way caused by the installer, and certainly not by the presence of this message. Note that the message would not even be shown during a regular (non-expert) installation. That would be unthinkable if it contained any real information. If you select "manual partitioning" in the first dialog of the partitioner and the next screen shows your harddisk and the existing partitions that are on it, there is nothing to worry about. [...] Given the age of your system it should be well supported by Sarge. If it were a recent system I'd advice to install Etch instead of Sarge, but for a Pentium 3 box there is no reason for that. Hope this gives you the confidence to proceed. Yes, thank you. The CD part of the install finished fine, the disks are partitioned and OK, and now it has rebooted from the hard disk and is happily downloading more packages. Thanks again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413788: Daily Etch build fails to install on iMac G5 - Ethernet not detected
Hi Frans, On Wednesday 07 March 2007 03:47, Mike Hore wrote: Comments/Problems: The Ethernet connection is not detected. This machine has an 10/100BASE-T Ethernet port. I suspect the correct driver hasn't been included in the netinstall image. After network detection failed, please switch to VT2 (on a PC this is alt-F2; I guess option-F2 or something similar on Macs) and enter the following command: lspci -nn | grep Ethernet We need the PCI Id of that device, which looks like [:]. 0001:03:0f.0 Ethernet controller: Apple Computer Inc. Shasta (Sun GEM) [106b:0051] Since this is a netinstall and the network can't be initialized, I couldn't proceed beyond this point. This is not true. Netinst CDs contain the full base system, so you can complete an installation without a network card. You would end up with a fairly minimal, but completely functioning system. OK, I guess that's right, if you know what you're doing, but with the little Linux I know I'm basically stuck. Now I probably should have mentioned that BEFORE the Ethernet detection attempt, I got another message to say that some kernel modules could not be found, and should I proceed without them, and the installation might fail if I proceeded. I assumed this was because I was attempting a netinstall, but for all I know that assumption might have been wrong. Cheers, Mike. --- Mike Hore[EMAIL PROTECTED] --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lvm volume group name
On Thursday 08 March 2007 00:53, Andrew Leach wrote: > # Volume group name: > d-i lvmcfg/vgcreate_namestring Try: partman-lvm/vgcreate_name -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413931: marked as done (d-i missing ide modules)
Your message dated Thu, 08 Mar 2007 02:16:37 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#413931: d-i missing ide modules
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: installation-reports
Boot method: CD
Image version: debian-31r5-i386-netinst.iso, from usc.edu mirror, md5sum good
Date: 7 Mar 2007, 22:00 UTC
Machine: Old Gateway, Tabor{2,3} motherboard
Processor: P3 (Katmai) 596MHz
Memory: 384 MB ECC
Partitions: none
Output of lspci and lspci -n: /bin/sh: lspci: not found
dmesg says:
: PCI: Probing PCI hardware (bus 00)
: PCI: Using IRQ router PIIX/ICH [8086/7110] at :00:07.0
: PCI: Found IRQ 9 for device :00:07.0
: PCI: Sharing IRQ 9 with :00:10.0
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot worked:[O]
Configure network HW: [O]
Config network: [O]
Detect CD: [O]
Load installer modules: [O]
Detect hard drives: [O] looks correct in dmesg
Partition hard drives: [ ]
Create file systems:[ ]
Mount partitions: [ ]
Install base system:[ ]
Install boot loader:[ ]
Reboot: [ ]
Comments/Problems:
Missing modules for ide.
Running as expert26 installation.
The last installer screen before starting disk partitioning says this:
: [.] Detect hardware
: Unable to load some modules
: Linux kernel modules needed to drive some of your hardware are not
: available yet. Simply proceeding with the install may make these
: modules available later.
:
: The unavailable modules, and the devices that need them are: agpgart
: (Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge), ide-scsi
: (Linux IDE-SCSI emulation layer), ide-mod (Linux IDE driver),
: ide-probe-mod (Linux IDE probe driver), ide-detect (Linux IDE
: detection), ide-floppy (Linux IDE floppy)
:
:
Selecting Continue brings us to the start of partitioning and making
filesystems.
As I searched Google's archives of various debian lists for this problem,
the recurrent answer seems to be that this is an informative message only,
and the modules will be loaded later. This seems to be contradicted by
this section from the Installation Guide:
: 6.3.2.B Partitioning and Mount Point Selection
:
:At this time, after hardware detection has been executed a final time,
:debian-installer should be at its full strength, customized for the
:user's needs and ready to do some real work. As the title of this
:section indicates, the main task of the next few components lies in
:partitioning your disks, creating filesystems, assigning mountpoints
:and optionally configuring closely related issues like LVM or RAID
:devices.
The text of the error screen, and the text of the Installation Guide,
seem to be saying clearly that these modules are needed to drive the IDE
hardware, and this was the last chance to automatically find them, and it
did not succeed.
I am _very_ reluctant to proceed to partitioning and file-system making,
for this reason: A week ago I tried installing on this machine, using the
3.1R4 netinst CD and the original 4MB Seagate IDE disk that came with this
machine. I saw the same errors about missing modules, but proceeded anyway.
The installer pretended to partition the disk, and pretended to install some
stuff for a while, then croaked with an error about the disk being Busy.
After much investigating of the disk with Knoppix and smartctl, it seemed
that the disk was permanently bad, giving errors on self-tests, unable
to successfully write to some parts of it, and hanging busy. I replaced it
with 2 nice new high-capacity IDE Ultra-ATA disks, and downloaded the newest
netinst 3.1R5 CD, and tried again today.
I don't want to destroy my new disks by trying to partition them when the
installer is plainly telling me it doesn't have the necessary kernel modules
to do the job. Is there some way I can supply these missing modules to
the installer ? Should I try to partition/mk*fs them from Knoppix ?
Is there any other documentation I should read ?
Please advise.
Note: I am subscribed to the debian-bugs-dist list.
--- End Message ---
--- Begin Message ---
On Thursday 08 March 2007 02:06, Lou Poppler wrote:
> Yes, confusing and scary. Perhaps the words "needed" and "need" are
> too strong in this message. I leave this bug open only to allow
> d-i maintainers to consider if they want to reword it.
Well, you're not really supposed to install in expert mode
Bug#389881: RC-ness of this bug
On Wed, Mar 07, 2007 at 04:09:48PM -0800, Steve Langasek wrote: On Thu, Mar 08, 2007 at 12:44:05AM +0100, David Härdeman wrote: I've attached a patch which implements persistent device names in partman by checking for devices which are mounted under /target and which have a suitable link in /dev/disk/by-id/* For each device that is found, /target/etc/fstab is modified appropriately. Thanks for the patch, David. I don't believe this should be changed for etch at this point in the release process, and that's speaking as someone who's run into this problem myself with SCSI device renumbering -- it's awkward and annoying to have to manually fiddle your boot config because a USB device is no longer registering as /dev/sda, and it's not in line with the quality of experience that our users have come to expect when installing Debian >:), but I don't think that makes anything unreleasable. Changing the fstab handling at this point could break many other scenarios that we haven't thought of and tested for, whereas the USB issue can be documented in the errata. Yes, I just finished the install under qemu, and it turns out that grub-installer (but not update-grub from the real grub package) breaks with /boot on /dev/disk/by-*/something. It creates kernel and initrd entries of the form /boot/something rather than /something. -- David Härdeman
