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
