[pkg-cryptsetup-devel] Bug#902943: cryptsetup-initramfs: Encrypted rootfs in LVM is not found after upgrade

[Guilhem Moulin]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180703/ef3efefa/attachment.sig>