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

[Korbinian Demmel]

Hello Guilhem,

thank you very much for the detailed response.

> Not forever, though.  It drops to a debug shell after ‘rootdelay’
> (default 180) seconds, [...]

Right. Too long to wait ;)

I read through your mail, but obviously lack some context.

I played around with the 'lvm2' script. Support to get the mangled source device (LG/LV) for an given LV UUID is quite simple to add.
But I ran into the issue that the very same UUID is also used afterwards for 'cryptsetup', which obviously won't work.

> 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).

My feeling is that the whole 'initramfs' process to get the rootfs is not iterative (works not recursively) and is in some way "hard-wired" for usual use cases. Some time ago I fiddled around with 'initramfs' itself to support an image with an encrypted rootfs directly. To accomplish that I added support for a list of arguments for 'rootfs', 'rootflags', etc. But eventually it just did not work due to the non-recursive architecture of initramfs.

> But coming up with our own logic to activate VGs is beyond the scope of
> cryptsetup IMHO.

Unfortunately I am lost regarding the original issue:
As far as I understand, there is currently no way to use an encrypted rootfs baked by LVM. Would be nice if that is mentioned in the changelog at least. Or did I miss that?
Since I not really need LVM, I probably will just get rid of it for now.


Regards,
doak



On 03.07.2018 22:58, Guilhem Moulin wrote:
> 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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180706/e9040855/attachment.sig>