-----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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5162695b.9020...@pocock.com.au