Bug#612402: upgraded systems won't boot from UUID volumes
On Sun, 2013-04-07 at 17:15 +0100, Ben Hutchings wrote: So it seems that this is only going to be an issue if users take the unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe there are management tools that do that as a matter of course? I vaguely recall the occasion which caused me to file this bug report but I can't recall any of the specifics about how I got into this state. (Which points to something of a shortcoming in my bug report, sorry). I do notice that I sent the report from a work machine so it might be something to do with Xen, but it is equally likely to be something on one of our server machines or I just happened to send it from work in my lunch hour. I can't think of a reason why I would have deliberately switched from the LV name to a UUID in fstab, but that's not to say I didn't. It's also possible that this was just a transient issue in the installer or grub or some other component which is gone now. Sorry for not being much help here. Ian. signature.asc Description: This is a digitally signed message part
Bug#612402: upgraded systems won't boot from UUID volumes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/04/13 18:15, Ben Hutchings wrote: On Sun, 2013-04-07 at 16:19 +0200, Daniel Pocock wrote: On 07/04/13 15:47, Neil Williams wrote: On Sun, 07 Apr 2013 15:25:43 +0200 Daniel Pocock dan...@pocock.com.au wrote: I notice this bug was downgraded below the RC threshold and appears to have been missed so far: It was only pushed to RC status by your request and then almost immediately moved back to original severity of Important by one of the maintainers. It is up to the maintainers to assign severity of bugs. Why have you not asked the maintainers of their opinion of the severity? Because they already downgraded below the RC status, so I'm curious if other people have reason to believe there is a problem. I have only come across a few systems with UUID in fstab, If you *don't* use LVM this is normal, as device names are not stable. but if somebody else is aware of widespread use of this, now is probably the time to comment. I just did some install and upgrade tests: 1. I installed squeeze and selected guided partitioning using LVM. The installer put /dev/mapper/* names in /etc/fstab (and also created a non-LVM /boot formatted as ext2!). Upgrading to wheezy worked fine. 2. I installed squeeze and selected 'manual partitioning' and created a pure LVM layout with root and swap LVs. This also resulted in /dev/mapper/* names in /etc/fstab. I'm not suggesting that squeeze systems were installed that way by default, although people who have migrated an FS from a raw partition to an LV may have this in fstab. 3. Running 'dpkg-reconfigure linux-base' did not change these device names, as expected (it should only touch IDE and SCSI device names). So it seems that this is only going to be an issue if users take the unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe there are management tools that do that as a matter of course? As noted in the bug, somebody using a btrfs root FS (re-assembly of multiple volumes) may also have a problem if all those LVs are not active, and UUID may solve that for them. Once again, that is not an FS layout that any previous installer would have created automatically, but it is a valid way to mount a root filesystem. Maybe this is just something to be noted in the release notes, or if there are other issues like this that people have in mind, maybe it would be possible to write a pre-upgrade check script that users can download and run to find out about things like this before they upgrade. I don't mind helping out with such a script if nobody else has started on one already. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJRYmlbAAoJEOm1uwJp1aqDLDwP/Rs7GN9m/5hgWiRABnXrcG8k OAItn9goEKppV0crR6f3lnMS2ISQ+O+n2hZdQne/K5Dna19kM5UCAnSGxJqibx8U 7saDsdke4M54o76rBGYu4pMffN1uApF1v40dIE8R8dYUfIjSbOMEOlYQXtc7ciJ8 m6jjL/2haVqgaEQeN3Dy2n6gCT16o6OBsjCqIxOCrN5NosThxHDubbNHUuBN2c47 6zMO4XAG5l94r16CvNOiUVyn4eVfTesKly+vRoXUci02UzhSZs6G18//Ks3E0RIM ZI7JZ3cSK52YROpr+nCTLTqSCLqIMkPZJmRacT+8RquZEuP1ER+Vq2s/ANXpijZX ZhFtK1FuhDkuurZNY04PPZQuAUlQ9rT5UZPlNG879e9iZtc9DOr9vvLt1WwE75wi udjpMEvM2LMsGUaf2KzupK6yfhnWbXEEmEWmk4WnkRHKcAJraGvY1NDeeEjm2aDv d1dUcOxOr0VIbXhJ35Q+ouLVIEBf2hyd2SWi+wgl56VwyG4ZAEwHNUDQsZrCQRD7 wSVN2scefhchijDNcY+4hsyKjl1eZHEaDCZC3JH5QMofVR8i4jMDrgML8bjP5K+N q2Dujv6oANdXmC7q/ZTlenjLdSWibvCLF8LsaNoIHEj4mQ8tJm8m5Byx2E1tTRzj lO2wZJHuIiUtn6K3h/Yr =7RE5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612402: upgraded systems won't boot from UUID volumes
On Sun, 2013-04-07 at 16:19 +0200, Daniel Pocock wrote: On 07/04/13 15:47, Neil Williams wrote: On Sun, 07 Apr 2013 15:25:43 +0200 Daniel Pocock dan...@pocock.com.au wrote: I notice this bug was downgraded below the RC threshold and appears to have been missed so far: It was only pushed to RC status by your request and then almost immediately moved back to original severity of Important by one of the maintainers. It is up to the maintainers to assign severity of bugs. Why have you not asked the maintainers of their opinion of the severity? Because they already downgraded below the RC status, so I'm curious if other people have reason to believe there is a problem. I have only come across a few systems with UUID in fstab, If you *don't* use LVM this is normal, as device names are not stable. but if somebody else is aware of widespread use of this, now is probably the time to comment. I just did some install and upgrade tests: 1. I installed squeeze and selected guided partitioning using LVM. The installer put /dev/mapper/* names in /etc/fstab (and also created a non-LVM /boot formatted as ext2!). Upgrading to wheezy worked fine. 2. I installed squeeze and selected 'manual partitioning' and created a pure LVM layout with root and swap LVs. This also resulted in /dev/mapper/* names in /etc/fstab. 3. Running 'dpkg-reconfigure linux-base' did not change these device names, as expected (it should only touch IDE and SCSI device names). So it seems that this is only going to be an issue if users take the unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe there are management tools that do that as a matter of course? Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Bug#612402: upgraded systems won't boot from UUID volumes
On Sun, Apr 07, 2013 at 04:01:25PM +0100, Roger Leigh wrote: UUIDs are used by default AFAICS when the installer creates the fstab, and should work just fine. Just looking and I don't have an example system which uses UUIDs /and/ LVM root, however--this does not appear to be the default for LVM. While this is an important issue, the fact that it's not hit by default might be one reason for lowering the severity. They are not used by default for filesystems on LVM, because LVM volume names are already unique identifiers and fs UUIDs are *not* due to snapshotting. So the patch here may or may not be appropriate to apply, but in no case should you be referencing LVM volumes by UUID on /etc/fstab. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#612402: upgraded systems won't boot from UUID volumes
On Sun, 07 Apr 2013, Ben Hutchings wrote: So it seems that this is only going to be an issue if users take the unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe there are management tools that do that as a matter of course? One should never use UUIDs in fstab to refer to non-unique filesystems (which is pretty much a normal thing with LVM, as the use of snapshotting is common). Any management tools that screw this up need a reality check (and post-haste bug fix). Doing otherwise is courting a data loss scenario. We've seen it happen a large number of times over the years because of the md 0.90 layout, until userspace tools started to add defensive layers to make it less likely to happen. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
