Bug#389881: RC-ness of this bug
On Wed, Mar 14, 2007 at 04:57:51PM -0700, Steve Langasek wrote: , it changes if you change the SCSI/IDE bus address of the drive the same applied in the old hd? and sd? days, drives names changing when you change thier IDE/SCSI ids is something admins expect and are used to. Um. Have you ever even used SCSI? Someone which uses scsi-over-fc have much better identification, the wwnn, which is used in by-id: | $ ls -al /dev/disk/by-id/scsi-32020371a* | lrwxrwxrwx 1 root root 9 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24 - ../../sda | lrwxrwxrwx 1 root root 10 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24-part1 - ../../sda1 | lrwxrwxrwx 1 root root 10 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24-part2 - ../../sda2 Well, some of us have, and I don't think any admin of such systems enjoys having to fix /etc/fstab by hand. Also many fc-users wants multipath anyway, which also uses the wwnn for identification. Using dd to back up a partition to another isn't a very sensible backup schema anyway. I think more people move PCI devices than back up systems this way... It is widely used in form of snapshots. What does the kernel do when it finds two filesystems with colliding uuids? Ideally, to avoid any accidents, it should rename them both. With that fix (if indeed it needs fixing), I think all the main problems of by-uuid go away. It does nothing special. This is completely userspace. And current udev just uses the last seen one, which is usualy the removable device in this case. Bastian -- Every living thing wants to survive. -- Spock, The Ultimate Computer, stardate 4731.3 signature.asc Description: Digital signature
Bug#389881: RC-ness of this bug
On Thu, Mar 15, 2007 at 08:56:39AM +0100, Bastian Blank wrote: On Wed, Mar 14, 2007 at 04:57:51PM -0700, Steve Langasek wrote: , it changes if you change the SCSI/IDE bus address of the drive the same applied in the old hd? and sd? days, drives names changing when you change thier IDE/SCSI ids is something admins expect and are used to. Um. Have you ever even used SCSI? Someone which uses scsi-over-fc have much better identification, the wwnn, which is used in by-id: So it's used in by-id, but not in by-path, right? Hence this is still an argument against by-path. | $ ls -al /dev/disk/by-id/scsi-32020371a* | lrwxrwxrwx 1 root root 9 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24 - ../../sda | lrwxrwxrwx 1 root root 10 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24-part1 - ../../sda1 | lrwxrwxrwx 1 root root 10 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24-part2 - ../../sda2 Well, some of us have, and I don't think any admin of such systems enjoys having to fix /etc/fstab by hand. Also many fc-users wants multipath anyway, which also uses the wwnn for identification. True; though supported multipath implementations sadly vary with vendor. Using dd to back up a partition to another isn't a very sensible backup schema anyway. I think more people move PCI devices than back up systems this way... It is widely used in form of snapshots. Yes, snapshots are fairly common, and at least in the case of a power outage / system crash you'd have to worry about them being around on reboot. Hmm, having the system unable to mount a root fs at all on reboot would be even worse for recovery than having it accidentally mount a snapshot, which is already bad enough... What does the kernel do when it finds two filesystems with colliding uuids? Ideally, to avoid any accidents, it should rename them both. With that fix (if indeed it needs fixing), I think all the main problems of by-uuid go away. It does nothing special. This is completely userspace. And current udev just uses the last seen one, which is usualy the removable device in this case. Right. Do you think it would be sensible to rename both devices on collision? Do you think that would be sufficient for making by-uuid a safe default? -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Thu, Mar 15, 2007 at 02:19:11AM -0700, Steve Langasek wrote: Someone which uses scsi-over-fc have much better identification, the wwnn, which is used in by-id: So it's used in by-id, but not in by-path, right? Hence this is still an argument against by-path. No, similar identifiers are listed in both. And for s390 the initramfs scripts expects that the by-path name is used as root to be able to activate the complete device. | lrwxrwxrwx 1 root root 9 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24 - ../../sda | lrwxrwxrwx 1 root root 10 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24-part1 - ../../sda1 | lrwxrwxrwx 1 root root 10 Mar 2 23:24 /dev/disk/by-id/scsi-32020371a2f24-part2 - ../../sda2 32020371a2f24 is the unique identifier of the disk. | lrwxrwxrwx 1 root root 9 Mar 2 23:24 ccw-0.0.2900-zfcp-0x2120371a2f24:0x - ../../sda | lrwxrwxrwx 1 root root 10 Mar 2 23:24 ccw-0.0.2900-zfcp-0x2120371a2f24:0x-part1 - ../../sda1 | lrwxrwxrwx 1 root root 10 Mar 2 23:24 ccw-0.0.2900-zfcp-0x2120371a2f24:0x-part2 - ../../sda2 2120371a2f24 is the identifier of the path to the disk. In this case there exists two paths to the disk via one controller. Using dd to back up a partition to another isn't a very sensible backup schema anyway. I think more people move PCI devices than back up systems this way... It is widely used in form of snapshots. Yes, snapshots are fairly common, and at least in the case of a power outage / system crash you'd have to worry about them being around on reboot. Hmm, having the system unable to mount a root fs at all on reboot would be even worse for recovery than having it accidentally mount a snapshot, which is already bad enough... But irrelevant in this case, as udev does not set links for dm devices in by-uuid, they have a unique name per definition. (Yes, two lvm vgs with the same name have weird effects ...) Right. Do you think it would be sensible to rename both devices on collision? Do you think that would be sufficient for making by-uuid a safe default? I'm not sure. You always get a race condition between the events for the two devices. Bastian -- I have never understood the female capacity to avoid a direct answer to any question. -- Spock, This Side of Paradise, stardate 3417.3 signature.asc Description: Digital signature
Bug#389881: RC-ness of this bug
On Tue, Mar 13, 2007 at 05:49:02PM +0100, Frans Pop wrote: Colin has said a few times that he consideres the Ubuntu solution not clean enough for Debian. If I said that I misspoke; I only meant that it's not settled enough for Etch at this point. As I indicated on #debian-boot yesterday, I don't see anything wrong with Ubuntu's approach to this problem for Debian in general. Personally I also feel that all possible solutions effectively make /etc/fstab unreadable and unmaintainable. The approach we took in Ubuntu was to put comments above each UUID entry in /etc/fstab documenting which traditional device name they corresponded to at the point of installation. Of course this can get out of date, but I don't think there's really any sensible way around that. -- Colin Watson [EMAIL PROTECTED] -- 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 14, 2007 at 11:22:03PM -, peter green wrote: for most users fstab has always identified by rough position (e.g. hda=ide primary master), changing to a system based on partition IDs would mean a lot of relearning for admins (e.g. its no longer ok to backup a partition by dding it to another one) Note that various of the solutions suggested in this thread break the case where you *restore* from a dd'ed backup onto a new disk. If you restore such a backup after a fatal disk crash, you want the result to be mounted in the same place as before even though the drive ID and possibly its physical location are different. Thus I don't agree that by-id or by-path are good solutions to this problem; by-id even breaks where old-style IDE primary master-type identification would have worked fine. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Thursday 15 March 2007 17:44, Colin Watson wrote: Personally I also feel that all possible solutions effectively make /etc/fstab unreadable and unmaintainable. The approach we took in Ubuntu was to put comments above each UUID entry in /etc/fstab documenting which traditional device name they corresponded to at the point of installation. Of course this can get out of date, but I don't think there's really any sensible way around that. My main point is not that the UUID itself is not readable, but rather that the lines get way too long and, depending on your editor (settings), either get wrapped or disappear off screen. You loose the easy overview of what's in fstab. /etc/fstab used to be fairly maintainable because the info could be kept in columns fairly easily for most cases and because the info would mostly fit on one line [1]. IMO with a switch to UUIDs we are going to need an fstab editor (console based) that: - does the translation to the normal device names on the fly (and thus does always reflect the actual situation) - provides different 'views' of what's in fstab - allows to select what representation for the file system should be used in the fstab (traditional, path, uuid, id, ...) - allows to set mount point, type, mount options, etc. - sorts partitions into a logical order - maybe knows about removable devices - has a simple interface to add new entries for e.g. USB sticks - ... [1] Yeah, I know this is not true for NFS volumes and if a lot of options are used, but in general it was true. pgpaxPjCbCtT1.pgp Description: PGP signature
Bug#389881: RC-ness of this bug
On Mar 15, 2007, at 1:12 PM, Frans Pop wrote: On Thursday 15 March 2007 17:44, Colin Watson wrote: Personally I also feel that all possible solutions effectively make /etc/fstab unreadable and unmaintainable. The approach we took in Ubuntu was to put comments above each UUID entry in /etc/fstab documenting which traditional device name they corresponded to at the point of installation. Of course this can get out of date, but I don't think there's really any sensible way around that. My main point is not that the UUID itself is not readable, but rather that the lines get way too long and, depending on your editor (settings), either get wrapped or disappear off screen. You loose the easy overview of what's in fstab. /etc/fstab used to be fairly maintainable because the info could be kept in columns fairly easily for most cases and because the info would mostly fit on one line [1]. IMO with a switch to UUIDs we are going to need an fstab editor (console based) that: - does the translation to the normal device names on the fly (and thus does always reflect the actual situation) - provides different 'views' of what's in fstab - allows to select what representation for the file system should be used in the fstab (traditional, path, uuid, id, ...) - allows to set mount point, type, mount options, etc. - sorts partitions into a logical order - maybe knows about removable devices - has a simple interface to add new entries for e.g. USB sticks - ... [1] Yeah, I know this is not true for NFS volumes and if a lot of options are used, but in general it was true. If you're going to all the trouble of a smart fstab editor, why not simply define a more modern format (e.g. like that of dhcpd.conf) for the information that can accommodate line breaks and nesting. Change the name to something else, don't call it fstab; if the new file doesn't exist the mount command (and the rest of them that currently read fstab) will default to /etc/fstab if present. The biggest problem will be identifying all the places where fstab is currently *assumed* to be present and making them all use the new file. A library is probably needed that does the deciding of which format to use. Are there POSIX/LSB/etc ramifications? just a thought, Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
Personally I also feel that all possible solutions effectively make /etc/fstab unreadable and unmaintainable. Maybe Debian should lead the way to make /etc/fstab a generated file (like e.g. modules.conf used to be). what is so bad about /dev/disk/by-path/pci-:00:07.1-ide-0:0-part1 ? it says exactly where the controller is on the PCI bus, which device it is on the controller and which partition it is. Someone seeing that pattern should easilly be able to add entries for other drives and partitions on the same controller and with a bit more work (e.g. reading lspci and/or looking through /dev/disk/by-path) for drives on other controllers. sure its a little on the long side and you might want to change the spacing in fstab to reflect that but we have editors with copy and paste. A bit of extra verbosity in device names seems a small price to pay to get device names that are stable and reliable. The hd? system was very nice when most people just had a single ide controller with all their (sd? was alwats nasty afaict but few enough people had scsi that it didn't hit too many newbies) but times have moved on and it simply isn't possible to reliablly indentify drives with an identifier that short anymore. i don't see what generating fstab would gain. you are still going to have to have a configuration file that contains all the information about what to mount where including a method for identifying drives even accross addition of new hardware.
Bug#389881: RC-ness of this bug
On Wed, Mar 14, 2007 at 09:05:31PM -, peter green wrote: Personally I also feel that all possible solutions effectively make /etc/fstab unreadable and unmaintainable. Maybe Debian should lead the way to make /etc/fstab a generated file (like e.g. modules.conf used to be). what is so bad about /dev/disk/by-path/pci-:00:07.1-ide-0:0-part1 ? That it's not a persistent means of identifying a filesystem. It changes if you move the PCI device, it changes if you change the SCSI/IDE bus address of the drive, it changes if the kernel changes the name of the storage subsystem used to access the device (on kernel upgrades), it breaks down miserably if you use fiberchannel. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
That it's not a persistent means of identifying a filesystem. for most users fstab has always identified by rough position (e.g. hda=ide primary master), changing to a system based on partition IDs would mean a lot of relearning for admins (e.g. its no longer ok to backup a partition by dding it to another one) It changes if you move the PCI device true, not that i imagine people do that much. , it changes if you change the SCSI/IDE bus address of the drive the same applied in the old hd? and sd? days, drives names changing when you change thier IDE/SCSI ids is something admins expect and are used to. , it changes if the kernel changes the name of the storage subsystem used to access the device (on kernel upgrades) true, i wish they'd stop behaving like that. , it breaks down miserably if you use fiberchannel. never used fiberchanel so can't comment on this. to clarify my position on the overall issue i agree that this is too late for etch (sadly) by-path and by-id each have some pros and cons over each other but both are far better than the old scheme now that multiple controllers and usb devices in sd? are becoming the norm. by-uuid and uuid's in fstab (which seem to achive the same) is a very bad idea, it means that using dd to back up a partition to another one could result in the wrong one being mounted with potentially disasterous consequences. It could also be a severe security issue with the help of a carefully crafted usb stick (especially in an environment where deployment is done by imaging). labels suffer from the problems given above for uuids users installing on expert and possiblly medium should be given the choice between traditional names and the various new options.
Bug#389881: RC-ness of this bug
On Wed, Mar 14, 2007 at 11:22:03PM -, peter green wrote: That it's not a persistent means of identifying a filesystem. for most users fstab has always identified by rough position (e.g. hda=ide primary master), changing to a system based on partition IDs would mean a lot of relearning for admins (e.g. its no longer ok to backup a partition by dding it to another one) It changes if you move the PCI device true, not that i imagine people do that much. That doesn't make it a negligible use case. , it changes if you change the SCSI/IDE bus address of the drive the same applied in the old hd? and sd? days, drives names changing when you change thier IDE/SCSI ids is something admins expect and are used to. Um. Have you ever even used SCSI? , it changes if the kernel changes the name of the storage subsystem used to access the device (on kernel upgrades) true, i wish they'd stop behaving like that. Wishes don't get you robust systems. , it breaks down miserably if you use fiberchannel. never used fiberchanel so can't comment on this. Well, some of us have, and I don't think any admin of such systems enjoys having to fix /etc/fstab by hand. to clarify my position on the overall issue i agree that this is too late for etch (sadly) by-path and by-id each have some pros and cons over each other but both are far better than the old scheme now that multiple controllers and usb devices in sd? are becoming the norm. No, the trade-offs of by-path and by-id are *not* a clear win over the trade-offs of the current scheme. by-uuid and uuid's in fstab (which seem to achive the same) is a very bad idea, it means that using dd to back up a partition to another one could result in the wrong one being mounted with potentially disasterous consequences. Using dd to back up a partition to another isn't a very sensible backup schema anyway. I think more people move PCI devices than back up systems this way... It could also be a severe security issue with the help of a carefully crafted usb stick (especially in an environment where deployment is done by imaging). Heh, that seems oddly possible, yes. I guess it's not hard to read the uuid right out of the fstab, after all... What does the kernel do when it finds two filesystems with colliding uuids? Ideally, to avoid any accidents, it should rename them both. With that fix (if indeed it needs fixing), I think all the main problems of by-uuid go away. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Tuesday 06 March 2007 11:34, Robert Millan [ackstorm] wrote: - 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. I've just done a hd-media installation from USB-stick on my EM64t box (SATA disc controller) and everything worked out of the box [0]. Both grub and /etc/fstab were set up correctly [1]. I will not deny that users _can_ hit this issue, but it has been a known issue since Sarge. Unfortunately no one has yet been able to help us find a good enough for Debian solution for this. To be honest, I'm a bit surprised that this is generating so much confusion at the moment. As I said, it is hardly a new issues and persistent device naming has been a topic on the list on and off for the past year. Colin has said a few times that he consideres the Ubuntu solution not clean enough for Debian. David's script is nice (I've not looked at it in detail), but probably not fundamentally different from a similar script I proposed back in October [2]. Conclusion: - no, I don't feel this issue makes hd-media unreleasable; - yes, it would have been great if this was solved already; - yes, it is definitely too late to solve this issue for Etch; - yes, we should definitely document how people can fix a broken configuration (which is entirely possible) if they run into this issue; - yes, we should find a solution for this post-etch and we should probably implement something ASAP so we have plenty of time to tune it. Note that we need to find a solution that works for all architectures, for all file systems and for both permanent and removable media. Personally I also feel that all possible solutions effectively make /etc/fstab unreadable and unmaintainable. Maybe Debian should lead the way to make /etc/fstab a generated file (like e.g. modules.conf used to be). Cheers, FJP [0] Which in some ways is a pity as I had planned to use the boot failure as a basis to document how to recover from it :-/ [1] Except for creating a completely bogus entry for the usb stick itself using the devfs device name (bug filed, with patch :-) [2] http://lists.debian.org/debian-boot/2006/10/msg00710.html pgp8FG9kJ0uee.pgp Description: PGP signature
Bug#389881: RC-ness of this bug
Frans Pop wrote: I will not deny that users _can_ hit this issue, but it has been a known issue since Sarge. Unfortunately no one has yet been able to help us find a good enough for Debian solution for this. ... Personally I also feel that all possible solutions effectively make /etc/fstab unreadable and unmaintainable. Maybe Debian should lead the way to make /etc/fstab a generated file (like e.g. modules.conf used to be). One potential workaround for anyone running into this issue might be to create the root disk as a 1-disk RAID1, and then it should (?) get mounted by RAID UUID at boot. -jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Thu, Mar 08, 2007 at 11:21:05AM +, Colin Watson wrote:
+ uuid=$(PATH=/lib/udev:$PATH vol_id -u $fs)
+ if [ $uuid ]; then
+ printf # %s\n $(mapdevfs $fs)
+ printf %-15s %-15s %-7s %-15s %-7s %s\n UUID=$uuid
${mp} $type $options $dump $pass
I've seen these UUID tags break fsck on edgy (after it was released as stable).
I don't think it's a good idea to switch to this in the last minute.
Besides, what's the point of fixing it at the fstab generation? grub still
expects device ordering to be consistent (and doesn't rely on fstab for device
mapping).
If device ordering can't be made consistent, you can still workaround the
problem in device.map, but then you'll have to change it again post
grub-install or installed system's device.map will be broken.
--
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 Wed, Mar 07, 2007 at 04:09:48PM -0800, Steve Langasek wrote: 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. If you're going to document it, don't forget to mention that in your repair rescue boot you have to remove the stick quickly after initrd.gz is loaded but before Linux has a chance to detect it. If we're going that way, I would strongly recommend NOT to link the USB images from the download pages. They'll just make Debian look broken... -- 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 Wed, Mar 07, 2007 at 12:28:09PM -0500, Joey Hess wrote: Is this theoretical with SATA, or have you reproduced it? I've only reproduced it for SCSI. 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. USB is detected first, which takes /dev/sda. Then SCSI is detected as /dev/sdb. All of this happens during boot. I can send logs if you want. -- 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 Wed, Mar 07, 2007 at 02:03:35PM +0100, Robert Millan [ackstorm] wrote: On Wed, Mar 07, 2007 at 09:55:45AM -0300, Otavio Salvador wrote: 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, No, it uses UUIDs. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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/*
I've attached the Ubuntu patch for the same issue; it's been deployed
for some time and I think it's largely a cleaner approach than fixing it
up post-facto as your patch does. However, I tend to agree with Steve
that doing that at the last minute is risky; we had a fair few little
bits and pieces around the distribution to fix up, IIRC.
--
Colin Watson [EMAIL PROTECTED]
diff -Nru /tmp/bRFBYZWEev/partman-target-46/finish.d/fstab_hd_entries /tmp/gRV1OOc9kY/partman-target-46ubuntu2/finish.d/fstab_hd_entries
--- /tmp/bRFBYZWEev/partman-target-46/finish.d/fstab_hd_entries 2006-07-25 23:51:30.0 +0100
+++ /tmp/gRV1OOc9kY/partman-target-46ubuntu2/finish.d/fstab_hd_entries 2007-02-15 12:27:59.0 +
@@ -13,9 +13,18 @@
sort |
while read mp fs type options dump pass; do
case $fs in
- (/*)
+ (/dev/disk/*|/dev/fd[0-9]*|/dev/mapper/*|/dev/evms/*|/dev/md[0-9]*)
printf %-15s %-15s %-7s %-15s %-7s %s\n $(mapdevfs $fs) ${mp} $type $options $dump $pass
;;
+ (/*)
+ uuid=$(PATH=/lib/udev:$PATH vol_id -u $fs)
+ if [ $uuid ]; then
+ printf # %s\n $(mapdevfs $fs)
+ printf %-15s %-15s %-7s %-15s %-7s %s\n UUID=$uuid ${mp} $type $options $dump $pass
+ else
+ printf %-15s %-15s %-7s %-15s %-7s %s\n $(mapdevfs $fs) ${mp} $type $options $dump $pass
+ fi
+ ;;
esac
done
)
Bug#389881: RC-ness of this bug
Oh, at least one additional thing that's likely needed in this scenario
is the attached patch to make busybox's mkswap generate UUIDs.
* util-linux/mkswap.c: Set UUIDs on version 1 swap areas.
* util-linux/Makefile.in: mkswap needs uuid/uuid.h from e2fsprogs.
* e2fsprogs/Makefile.in: Build libuuid if building mkswap.
Ubuntu's volumeid.postinst also has some nasty code to add a UUID to
swap partitions that don't have one (due to busybox's mkswap not doing
this in the past). This was necessary because we were expecting to have
to change a lot of hard disk device names due to recent libata changes
in the kernel and forcibly moving over to UUIDs in /etc/fstab in advance
was the only way we could think of to prevent wholesale breakage.
UUIDs certainly have their disadvantages (verbosity being the main one),
but they're a hell of a lot better than labels for automatic use like
this. UUIDs are suitable for automatic generation while labels should
only be set by the sysadmin. The fiasco with Red Hat's installer setting
labels which can then end up conflicting with itself if you do multiple
parallel installs should demonstrate this (and some of the people
involved in Anaconda development said to me in person that in hindsight
this was probably a mistake). We've already backed away from automatic
use of labels once (http://bugs.debian.org/310754) so let's not have to
do so again!
--
Colin Watson [EMAIL PROTECTED]
only in patch2:
unchanged:
--- busybox-1.1.3.orig/e2fsprogs/Makefile.in
+++ busybox-1.1.3/e2fsprogs/Makefile.in
@@ -61,6 +61,7 @@
E2FSPROGS-$(CONFIG_LSATTR) += lsattr.o $(E2P_OBJS)
E2FSPROGS-$(CONFIG_MKE2FS) += mke2fs.o util.o $(E2P_OBJS) $(BLKID_OBJS) $(EXT2FS_OBJS) $(UUID_OBJS)
E2FSPROGS-$(CONFIG_TUNE2FS)+= tune2fs.o util.o $(E2P_OBJS) $(BLKID_OBJS) $(EXT2FS_OBJS) $(UUID_OBJS)
+E2FSPROGS-$(CONFIG_MKSWAP) += $(UUID_OBJS)
E2FSPROGS-y:=$(sort $(E2FSPROGS-y))
only in patch2:
unchanged:
--- busybox-1.1.3.orig/util-linux/mkswap.c
+++ busybox-1.1.3/util-linux/mkswap.c
@@ -44,6 +44,7 @@
#include sys/utsname.h
#include asm/page.h /* for PAGE_SIZE and PAGE_SHIFT */
/* we also get PAGE_SIZE via getpagesize() */
+#include uuid/uuid.h
#include busybox.h
#ifndef _IO
@@ -81,6 +82,17 @@
unsigned int badpages[1];
} *p;
+struct swap_header_v1_2 {
+ char bootbits[1024]; /* Space for disklabel etc. */
+ unsigned int version;
+ unsigned int last_page;
+ unsigned int nr_badpages;
+ unsigned char uuid[16];
+ char volume_name[16];
+ unsigned int padding[117];
+ unsigned int badpages[1];
+};
+
static inline void init_signature_page(void)
{
pagesize = getpagesize();
@@ -276,6 +288,9 @@
int goodpages;
int offset;
int force = 0;
+ uuid_t uuid_dat;
+
+ uuid_generate(uuid_dat);
init_signature_page(); /* get pagesize */
@@ -401,6 +416,21 @@
version, (long) (goodpages * pagesize));
write_signature((version == 0) ? SWAP-SPACE : SWAPSPACE2);
+ if (version == 1) {
+ struct swap_header_v1_2 *h;
+
+ /* Sanity check */
+ if (sizeof(struct swap_header_v1) != sizeof(struct swap_header_v1_2))
+ bb_error_msg(Bad swap header size; no UUID written.);
+ else {
+ char uuid_string[37];
+ h = (struct swap_header_v1_2 *) signature_page;
+ memcpy(h-uuid, uuid_dat, sizeof(h-uuid));
+ uuid_unparse(uuid_dat, uuid_string);
+ printf(UUID=%s\n, uuid_string);
+ }
+ }
+
offset = ((version == 0) ? 0 : 1024);
if (lseek(DEV, offset, SEEK_SET) != offset)
bb_error_msg_and_die(unable to rewind swap-device);
only in patch2:
unchanged:
--- busybox-1.1.3.orig/util-linux/Makefile.in
+++ busybox-1.1.3/util-linux/Makefile.in
@@ -10,6 +10,8 @@
endif
srcdir=$(top_srcdir)/util-linux
+UTILLINUX_CFLAGS := -I$(top_srcdir)/e2fsprogs
+
UTILLINUX-y:=
UTILLINUX-$(CONFIG_DMESG) +=dmesg.o
UTILLINUX-$(CONFIG_FBSET) +=fbset.o
@@ -49,11 +51,14 @@
APPLET_SRC-y+=$(UTILLINUX_SRC-y)
APPLET_SRC-a+=$(UTILLINUX_SRC-a)
+APPLETS_DEFINE-y+=$(UTILLINUX_CFLAGS)
+APPLETS_DEFINE-a+=$(UTILLINUX_CFLAGS)
+
$(UTILLINUX_DIR)$(UTILLINUX_AR): $(patsubst %,$(UTILLINUX_DIR)%, $(UTILLINUX-y))
$(do_ar)
$(UTILLINUX_DIR)%.o: $(srcdir)/%.c
- $(compile.c)
+ $(compile.c) $(UTILLINUX_CFLAGS)
ifneq ($(strip $(CONFIG_LFS)),y)
ifeq ($(strip $(FDISK_SUPPORT_LARGE_DISKS)),y)
Bug#389881: RC-ness of this bug
I took the liberty of trimming the CC list since the details of a persistent device node script would probably not interest everyone... On Thu, March 8, 2007 12:21, Colin Watson said: 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/* I've attached the Ubuntu patch for the same issue; it's been deployed for some time and I think it's largely a cleaner approach than fixing it up post-facto as your patch does. I considered doing the changes directly rather than as a post fixup, but I opted not to for a couple of reasons: You explicitly have to exclude some volumes, with my patch that decision (i.e. which devices it is sane to have persistent device names for) is left to udev. It becomes much easier to switch between different kinds of persistent device names with the standalone script. With the post-fix script, it would be simple to support an argument such as by-id or by-uuid which changed the type of symlinks that were used (then we could have that in a priority low question so that the propellerheads can change it themselves, experience so far seems to indicate that some people will never be happy with the choice of persistent device names whether they are based on label, uuid, id, path, etc). At some point the future we're going to have to help users convert their fstabs to persistent device names to avoid breakage (which I think is the only argument that supported implementing persistent device names before the release of Etch, although I think we'll have to live without it). One such example will be the libata introduction (whether that will be during the Etch - Lenny upgrade or at some different point in time). If we have one such standalone script, and use it both in the installer and in upgrading older systems, it will receive much more testing. Using vol_id directly rather than reading the symlinks, which would be required if this is implemented in fstab_hd_entries, also has the disadvantage that we'd need to duplicate the string conversions that udev performs on the output from vol_id before it creates the device nodes. And on a related note, one disadvantage of using UUID=something or LABEL=something instead of /dev/disk/by-something/something is that the former requires every script that will ever parse fstab to add code to parse and handle X=Y (it would break cryptsetup and possibly other boot-related scripts right now). X=Y also makes it impossible to add new schemes without having to change all related scripts to support the new values of X (we already have by-path and by-id) while doing so is easy with the symlinks. Phew, this came out a bit longer than expected :) However, I tend to agree with Steve that doing that at the last minute is risky; we had a fair few little bits and pieces around the distribution to fix up, IIRC. I agree with Steve as well -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
On Thu, March 8, 2007 12:32, Colin Watson said: UUIDs certainly have their disadvantages (verbosity being the main one), but they're a hell of a lot better than labels for automatic use like this. UUIDs are suitable for automatic generation while labels should only be set by the sysadmin. The fiasco with Red Hat's installer setting labels which can then end up conflicting with itself if you do multiple parallel installs should demonstrate this (and some of the people involved in Anaconda development said to me in person that in hindsight this was probably a mistake). We've already backed away from automatic use of labels once (http://bugs.debian.org/310754) so let's not have to do so again! I agree. We had similar pains with the default naming of volume groups for lvm installations, people will do multiple installs and the labels *will* collide. (And I find by-id even better than by-uuid since by-uuid still might break due to careless admins doing whole-partition backups using dd.) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
Colin Watson [EMAIL PROTECTED] writes: 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/* I've attached the Ubuntu patch for the same issue; it's been deployed for some time and I think it's largely a cleaner approach than fixing it up post-facto as your patch does. However, I tend to agree with Steve that doing that at the last minute is risky; we had a fair few little bits and pieces around the distribution to fix up, IIRC. To full support it, another change would be need on Parted IIRC. You reported the patch for it but I hadn't applied yet since we weren't using it that time. -- 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.
Bug#389881: RC-ness of this bug
On Thu, March 8, 2007 13:55, Otavio Salvador said: To full support it, another change would be need on Parted IIRC. You reported the patch for it but I hadn't applied yet since we weren't using it that time. Do you have a link? The fstab things should take place well after the partitioning stage so I don't understand how parted would be affected? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
David Härdeman [EMAIL PROTECTED] writes: On Thu, March 8, 2007 13:55, Otavio Salvador said: To full support it, another change would be need on Parted IIRC. You reported the patch for it but I hadn't applied yet since we weren't using it that time. Do you have a link? The fstab things should take place well after the partitioning stage so I don't understand how parted would be affected? To support UUID for swap. -- 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.
Bug#389881: RC-ness of this bug
UUIDs certainly have their disadvantages (verbosity being the main one), but they're a hell of a lot better than labels for automatic use like this. UUIDs are suitable for automatic generation while labels should only be set by the sysadmin. The fiasco with Red Hat's installer setting labels which can then end up conflicting with itself if you do multiple parallel installs should demonstrate this (and some of the people involved in Anaconda development said to me in person that in hindsight this was probably a mistake). We've already backed away from automatic use of labels once (http://bugs.debian.org/310754) so let's not have to do so again! i'd still be happier with hardware IDs or paths than partition UUIDs, UUIDs seem very prone to things breaking on filesystem or disk cloning which is not something a *nix admin would expect to break stuff (unlike changing hardware)
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]
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
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
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#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#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#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
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#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]
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
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 #
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
Bug#389881: RC-ness of this bug
Hi, 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. This makes USB sticks unusable for any computer using SATA or SCSI (i.e., almost every modern x86). I would rather not ship any USB images at all than shipping them in this state. As for finding a solution, I'm not sure what can be done. Perhaps d-i could tell udev in some way that device node names need to be reordered, right after disks have been detected ? -- 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 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. -- ciao, Marco signature.asc Description: Digital signature
Bug#389881: RC-ness of this bug
[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. -- 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 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). Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389881: RC-ness of this bug
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). isn't udev supposed to provide persistant device naming avoiding this problem?
