[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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 
>>> <daniel@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-----


Reply to: