0

So I've installed my system on the following layout:

  • Created an LV spanning two nvme drives called spanned_vg-spanned_lv.
  • I've formatted that LV with LUKS and mapped it as cryptroot
  • That cryptroot virtual drive has only a single partition, which I plan on using as root.
  • Boot is a separate partition on one of the drives.

lsblk:

NAME                      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                       7:0    0   3.1G  1 loop  /mnt/livecd
sda                         8:0    1 119.3G  0 disk  
├─sda1                      8:1    1 119.2G  0 part  
│ └─ventoy                253:0    0   3.2G  1 dm    /mnt/cdrom
└─sda2                      8:2    1    32M  0 part  
nvme1n1                   259:0    0 476.9G  0 disk  
└─nvme1n1p1               259:1    0 476.9G  0 part  
  └─spanned_vg-spanned_lv 253:1    0   1.4T  0 lvm   
    └─cryptroot           253:2    0   1.4T  0 crypt /mnt/gentoo
nvme0n1                   259:2    0 931.5G  0 disk  
├─nvme0n1p1               259:3    0   512M  0 part  /mnt/gentoo/boot
└─nvme0n1p2               259:4    0   931G  0 part  
  └─spanned_vg-spanned_lv 253:1    0   1.4T  0 lvm   
    └─cryptroot           253:2    0   1.4T  0 crypt /mnt/gentoo

I've used systemd-boot plenty on arch with luks but never with LVM or on gentoo (and the docs do seem to use slightly different config entries) so I'm somewhat at a loss. I've tried following some examples I've found online and I've got this far with my loader entry:

tile Gentoo Linux
efi /vmlinuz-6.1.41-gentoo-x86_64
initrd /initramfs-6.1.41-gentoo-x86_64.img
options luks.name=/dev/mapper/spanned_vg-spanned_lv=cryptroot root=/dev/mapper/cryptroot init=/usr/lib/systemd/systemd ro dolvm

But when I attempt to boot I get a kernel panic because it can't find a root.

So I'm guessing one of the following is true:

  • I've screwed up generating my ramdisk, I'm used to using mkinitcpio so it's entirely possible I'm using genkernel wrong. My genkernel.conf is:
INSTALL="yes"
NOCOLOR="false"
LVM="yes"
LUKS="yes"
MICROCODE="amd"
GK_SHARE="${GK_SHARE:-/usr/share/genkernel}"
CACHE_DIR="/var/cache/genkernel"
DISTDIR="${GK_SHARE}/distfiles"
LOGFILE="/var/log/genkernel.log"
LOGLEVEL=1
DEFAULT_KERNEL_SOURCE="/usr/src/linux"
  • My lv isn't being discovered before systemd attempts to open the cryptroot. Not sure how I'd fix this?
  • What I'm doing is stupid and this layout isn't actually supported.

Any help here would be amazing, thanks!

0

1 Answer 1

0

I've not used gentoo so I may be wrong as these kernel parameters are actually interpreted by initramfs and not the kernel itself. However...

This looks like you maybe missed a step. For this to work, cryptsetup needs to unlock the LUKS drive in initramfs:

root=/dev/mapper/

In other distributions this requires you to:

  • Install a package that adds scripts to initramfs to unlock your LUKS block device. Eg in Ubuntu you can install cryptsetup-initramfs
  • Update /etc/cryptab to include a line to unlock /dev/mapper/cryptroot
  • Run a command to rebuild your initramfs (update-initramfs)

I suspect gentoo will need a similar three steps

4
  • /dev/mapper/cryptroot seems fine – the "TYPE: crypto" column indicates it is the unlocked (unencrypted) block device, i.e. a dm-crypt device. Commented Aug 9, 2023 at 6:39
  • @u1686_grawity you're right I misread the lsblk. I still suspect the issue is basically the same. Commented Aug 9, 2023 at 11:20
  • So I've never had to use cryptab before. I've always just provided a couple of options and the initrd has done its thing. I'm just wondering how/when the LVM gets mapped and if that's the root issue here Commented Aug 16, 2023 at 16:34
  • @ScottishTapWater I doubt it's a problem finding the encrypted device, since the error you've described is "can't find root". Mounting root is the last step in the sequence so somehow it's missed a step. If it's not in cryptab then it needs specifying another way. The only other way it could hypothetically work is if initramfs tried to unlock every encrypted drive it could find and that would usually be undesirable. This blog suggests adding crypt_root=... to your boot args Commented Aug 17, 2023 at 1:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .