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

Re: upgraded systems won't boot from UUID volumes

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.

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Reply to: