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. Either way, I think there is a bug that needs to be fixed with
initramfs-tools so that neither adjustment should be necessary.

Cheers
A.