In the following scenario genkernel fails to enable lvm volumes: One harddisk, completely encrypted, with lvm volumes inside As lvm starts before cryptsetup in the linuxrc it cannot enable the lvm-in-crypt volumes, thus failing to start and forcing the user to use the rescue shell at every boot. --- /usr/share/genkernel/defaults/linuxrc 2011-11-04 23:47:23.000000000 +0100 +++ linuxrc 2011-11-09 22:31:03.756117585 +0100 @@ -334,6 +334,9 @@ fi fi +# need to start here +startVolumes + mkdir -p "${NEW_ROOT}" CHROOT="${NEW_ROOT}" This small patch starts lvm again after cryptsetup - worst case it just re-finds all the devices (no obvious side-effects), but it allows both combinations of crypt-in-lvm and lvm-in-crypt
TBH I think I have not seen crypt-in-lvm (i.e. individual LVs being crypted), just lvm-in-crypt (i.e. the volumegroup is crypted). So I will look into this.
*** Bug 520788 has been marked as a duplicate of this bug. ***
I agree, this causes not pain to just detect volumes again. accepted, thanks
Created attachment 421012 [details] genkernel-3.4.52.3-lvm-twice.png @ Rick: Are you sure this was still needed? From my understanding I have a setup which would require these changes (lvm-in-crypt): I have two disks (sda and sdb) in mdraid 1 (mirror). md0 is my unencrypted boot partition and md1 (the rest) is encrypted with LUKS. In (on top of) my encrypted partition (md1) I have my LVM layer with partitions for "/", "/home" and swap. When I now boot with an initramfs containing your patch (https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=33c3c90cce2a242a7d6e45effa48ebbd91f63cff, first released with sys-kernel/genkernel-3.4.52.3) I'll see this: 1. mdadm will assemble my RAID 2. I'll see the first LVM scan (which will detect nothing on my system, because my LVM volumes resides on the still encrypted partition). 3. I'll get the LUKS prompt which will open "md1". 4. The second LVM scan is started (which will now find my LVM volumes). 5. A third LVM scan is started (this is new!). [genkernel-3.4.52.3-lvm-twice.png] So for me it looks like that this bug 390079 was fixed long time ago and this change isn't required anymore.
After reading the commit logs/source code up to 2009 I would call this bug invalid: For me it looks like the original reporter (Patrick) didn't used CRYPT_ROOT. If you set CRYPT_ROOT we are already re-scanning for LVM volumes after opening LUKS, see https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/initrd.scripts#n1292 I vote for reverting commit 33c3c90cce2a242a7d6e45effa48ebbd91f63cff because from my view it doesn't make _any_ sense. But if I miss something it would be glad if somebody could explain. Thanks.
agreed, but next time please open a new bug for the new issue and simply reference the old bug https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=c7a2fbef56b808b97135307621dc43b4fe970a44
