Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case
Hello, On Sat 06 Aug 2022 at 12:12AM +02, Guilhem Moulin wrote: > Could you please double check that > > > https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/3854ce68641ba84b04df35828ccb9abcb569e5c6 > and > > https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/e03fcc0d3e3285b4e72208f40a4ac59db3022b48 > > suit your use case? (No need to build the package, you can just patch > the initramfs hook and boot script in /usr/share/initramfs-tools.) Tested building an image, and now it generates a crypttab in the initramfs that I am pretty sure will work -- thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case
Hi Sean, On Sun, 31 Jul 2022 at 13:45:29 -0700, Sean Whitton wrote: > 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. It appears we can remove our ugly lvm2 handling logic: lvm2 ≥2.03.15-1 has removed its initramfs-tools script and instead relies solely on udev rules. And your report was good timing since lvm2 2.03.15-1 was uploaded in the beginning of July :-) Could you please double check that https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/3854ce68641ba84b04df35828ccb9abcb569e5c6 and https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/e03fcc0d3e3285b4e72208f40a4ac59db3022b48 suit your use case? (No need to build the package, you can just patch the initramfs hook and boot script in /usr/share/initramfs-tools.) Note that if you have LVM devices that need to be activated at early boot stage you'll need lvm2 from Bookworm/sid. cheers -- Guilhem. signature.asc Description: PGP signature
Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case
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
