rd.luks.name doesn't work without systemd

[notramo]

Describe the bug rd.luks.name kernel command line doesn't work without systemd.

Distribution used Void Linux

Dracut version 053

Init system runit

To Reproduce Install Void Linux on a LUKS v2 partition with unencrypted BTRFS /boot. Set rd.luks.name=UUID=root kernel command line. The system hangs before mounting root. It doesn't ask for the password (no prompt).

Expected behavior It asks for password and continues boot process.

[mhx]

I've just run into the same issue while installing Gentoo. The setup is similar to @notramo's with simply a LUKS root partition (btrfs) and unencrypted /boot (ext4).

I've been trying to get this to work for several hours now and and was pretty certain I was doing something wrong. So here's what I know:

I found out that I can boot the system if my kernel command line looks like this:

crypt_root=UUID=my-partition-uuid root=UUID=my-btrfs-root-uuid

With this configuration, dracut will not prompt me for a password (somewhat expectedly), so I have to wait until it times out after 200 seconds and drops me to the shell. If I do

cryptsetup open /dev/nvme... root
exit

then the system boots just fine. This is a little inconvenient, though.

I've tried a lot of combinations of dracut-specific flags (including the one suggested by dracut --print-cmdline) on the kernel command line. While adding rd.luks.uuid=luks-my-partition-uuid actually makes dracut prompt me for a password, it still fails to boot, the difference being that I can't seem to find a way to manually fix things in the shell.

I've even tried using LVM on top of LUKS, but that didn't change anything.

I'm using OpenRC instead of systemd. dracut is at version 053.

[mhx]

This may be related: https://bugs.gentoo.org/592686

[mhx]

FWIW, I eventually got it to work with the kind help of the Gentoo Forums.

I found a suspicious line in the logs:

//lib/dracut/hooks/initqueue/finished/90-crypt.sh@1(source): '[' -e '/dev/disk/by-id/dm-uuid-CRYPT-LUKS?-*9d37b7ae23e6498a835fafa53ee292f4*-*' ']'

There were no entries matching the dm-uuid-CRYPT-LUKS... pattern anywhere in /dev/disk, though, which meant dracut was stuck in an endless loop.

Someone suggested using rd.luks.partuuid=... instead of rd.luks.uuid with the appropriate partition UUID, as that would bypass the check above. And indeed, my system booted just fine after the change.

I still think this should work with rd.luks.uuid, as this is what most instructions for setting up full-disk encryption use.

Full thread here for reference: https://forums.gentoo.org/viewtopic-t-1146272.html

[notramo]

I don't use UEFI (https://lwn.net/Articles/674940/), and didn't want to bother with GPT+BIOS, so my installation don't have partuuid.

[vysdel]

On Gentoo, with OpenRC and Dracut version 057, rd.luks.name works only if rd.luks.uuid is set aswell (and rd.luks.partuuid or rd.luks.partuuid, according to /usr/lib/dracut/modules.d/90crypt/parse-crypt.sh)

Using dracut.conf with something like this:

add_dracutmodules+=" dm btrfs crypt lvm "  
kernel_cmdline="rd.luks.uuid=__UUID__HERE__ rd.luks.name=__UUID_HERE__=root rootfstype=btrfs rootflags=__MOUNT_FLAGS__"

works for me. it asks password, boots system and creates /dev/mapper/root link instead of /dev/mapper/luks-UUID