On Tue, 03 Jul 2018 at 20:01:02 +0200, doak wrote: > After system upgrade the system is not bootable anymore due the > initramfs is unable to find the "source" for the rootfs and boot > hangs.
Not forever, though. It drops to a debug shell after ‘rootdelay’ (default 180) seconds, unless you've set the ‘panic=<sec>’ boot parameter. > linux-debian_crypt UUID=979d71b4-f9a9-45cb-b72e-6c81754ab504 none luks We're now relying on lvm2's /scripts/local-block/lvm2 to activate the VG holding our source device, which doesn't work with UUIDs: https://sources.debian.org/src/lvm2/2.02.176-4.1/debian/initramfs-tools/lvm2/scripts/local-block/lvm2/ I'd argue that this is a bug in lvm2's local-block script. The very same problem happens if /usr is held by a dedicated LV (whether / is held by a different LV in the same VG, in another VG, or by a non mapped device) and the FS is specified using its UUID in the fstab(5). If you specify the source device as /dev/mapper/linux-debian or /dev/linux/debian then you should be able to boot. “Should”, because for LUKS we're using UUIDs internally, so right now this won't work. When the source device is mapped we can use its (mangled) name instead. But coming up with our own logic to activate VGs is beyond the scope of cryptsetup IMHO. -- Guilhem.
signature.asc
Description: PGP signature