On Fri, 06 Jul 2018 at 00:51:02 +0200, Korbinian Demmel wrote: > 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.
It's not the LV UUID that we need here, but the LUKS UUID. And the
script doesn't know which device to activate, so it'd need to activate
all of them. But indeed it's quite simple to add, for instance by adding
a default option in the `case "$dev" in … esac`:
*) lvchange_activate;;
We can do better however, and activate only the required LV rather than
all of them. The boot script can't map the block device UUID to a LV,
but on `update-initramfs -u` our hook can map it since at that point the
LV is activated. In the upcoming 2:2.0.3-5 the hook substitutes the
mapped source devices with /dev/mapper/$SOURCENAME in the list of
devices to unlock at initramfs stage, which should work around this
issue.
>> 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.
It is recursive now. Once we have we have the list of block devices
holding the rootfs (for btrfs it's in /sys/fs/btrfs/$UUID/devices/*, for
traditional file systems it's /proc/mounts' first column) we recursively
traverse the sysfs hierarchy to find the list of underlying dm-crypt
devices. It works for LV — dm-crypt — MD stacks in whichever
combination.
>> 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?
No you didn't, otherwise I would have closed the issue and not retitle
it as a regression and tagged at as pending :-) 2:2.0.3-5 will contain
a workaround.
> Since I not really need LVM, I probably will just get rid of it for now.
I'll upload 2:2.0.3-5 in the next day or two. As a workaround, you
should be able to boot if you either 1/ add the catchall to the lvm2
local-block script; or 2/ use /dev/mapper/linux-debian as source in your
crypttab *and* remove lines 131-132 in the cryptroot hook file:
https://sources.debian.org/src/cryptsetup/2:2.0.3-4/debian/initramfs/hooks/cryptroot/#L131
--
Guilhem.
signature.asc
Description: PGP signature
