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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
