[pkg-cryptsetup-devel] Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case

Sean Whitton spwhitton at spwhitton.name
Sun Jul 31 21:45:29 BST 2022


Package: cryptsetup-initramfs
Version: 2:2.3.7-1+deb11u1

Dear maintainer,

I'm building disk images with an ext4 rootfs on LVM on LUKS.  I put a
PARTUUID in the /etc/crypttab of the image's rootfs, like this:

  erebus_crypt PARTUUID=13b9dfdf-04a2-4c97-a241-fe6cdfe76f68 none luks,discard,initramfs

I then run 'update-initramfs -u' while chrooted into the image's rootfs,
and the cryptsetup-initramfs scripts put this line in cryptroot/crypttab
in the initramfs:

  erebus_crypt /dev/mapper/loop0p2 none luks,discard,initramfs

So, the PARTUUID= source is being mapped to a /dev/mapper source, which
I think is the work of the fix for #902943.  It's the same for UUID=.

The problem is that /dev/mapper/loop0p2 is valid only on the
image-building host, and not on the host that will actually try to boot
the image.  Indeed, that's the whole reason I am using a PARTUUID, so
that it will stay valid.  So it looks like the fix for #902943 has
broken this sort of use case.  It would be great to have some way to
cause the PARTUUID to be passed through unchanged.

Thanks.

-- 
Sean Whitton



More information about the pkg-cryptsetup-devel mailing list