Autor: Hendrik Boom Data: Para: dng Assunto: Re: [DNG] Upgrade problem [ ascii -> beowulf ] failed to boot,
left at initramfs shell -- with fix and query
On Wed, Jul 08, 2020 at 06:14:51PM +1000, Andrew McGlashan via Dng wrote: >
>
> On 8/7/20 7:31 am, Alexander Bochmann wrote:
> > Hi,
> >
> > ...on Tue, Jul 07, 2020 at 02:00:38AM +1000, Andrew McGlashan via Dng wrote:
> >
> > > After the dist-upgrade, it failed to boot and remained at the ministrants shell environment after having complained about not being able to find the /usr file system via it's UUID.
> >
> > I have a system mostly like this (minus mdraid) with split root and /usr
> > on lvm each, and didn't run into your problem.
> >
> > My fstab uses /dev/mapper device names instead of UUIDs, but I don't see
> > why that should make a difference, seeing as it isn't used in the initramfs.
>
> Apparently with initramfs-tools it will try to mount /usr if it is in /etc/fstab ... not being able to mount /usr stopped normally boot from progressing further.
>
> Using the /dev/mapper device name would likely have been just as good, but I'm not sure as I didn't try that; I adjusted the /usr/share/initramfs-tools/scripts/local-top/lvm2 file
> to specifically activate the lv so it could be found to be mounted as it should have been.
>
> > (On the other hand, I usually use UUIDs too, so there might be a reason it
> > looks that way, and I just don't remember about it right now...)
>
> Yes, that makes sense.
>
> I would think that you fixed the problem by using the /dev/mapper
> entry and I fixed it in the lvm2 script.
I quite agree. There's a bug that needs fixing for Devuan, but not
Debian.
I may delay upgrading until it's fixed.
My /boot is on an old-style RAID by itself, so either copy can be used
directly.
My /usr, by the way, is on lvm2 on RAID.
Do I need both adjustments?
-- hendrik
> Either way, I think there is a bug that needs to be fixed with
> initramfs-tools so that neither adjustment should be necessary.
Quite agree. This is a bug in Devuan that originates in Debian but is
not considered a bug there.
So, as I understand it, if /usr is mentioned in /etc/fstab,
initramfstools will generate an initramfs that tries to mount /usr.
And that will succeed it /etc/fstab specifies /usr by the /dev/mapper
name, but not by the uuid?
So updating /etc/fstab to use the /dev/mapper name instead of a uuid
will make things work? Even for LVM2 partitions?
As it happens, my /etc/fstab alrady uses /dev/mapper names, though it
uses a uuid for /boot.
At the very least, this should be mentioned in the upgrade instructions.