[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