Dracut, LUKS with keyfile and systemd don't work as advertised about dracut HOT 4 CLOSED

Unfortunately that is not enough when the key device is slow to initialize. Key will be probed after opening of the LUKS device starts, when dracut already waits for the passphrase.

I wish to use a key file on an SD card, but the /dev/mmcblk0 device comes online after the /dev/sda device containing the LUKS partition and the key is found too late.

The end result is still the same: the LUKS key file is not used.

from dracut.

I have experienced this problem where /dev/mmcblk0 is supposed to work but dracut doesn't state that the keyfile is found, during the first setup of my system, it worked. After that, it doesn't seem to boot with the keyfile as it is not found. I tried formatting my sd card with ext4 and f2fs, no luck.

I am not using dracut with systemd.

from dracut.

I've taken a further look at what happens when running with systemd vs running without systemd and using LUKS with a key file. The results are very different. The non-systemd mode retries once every 0.5 seconds for 10 retries to hopefully have the key file found.

I'm not proposing any changes to the non-systemd function. My out loud thoughts for the systemd process is to:

• Drop the onetime nature of crypt-run-generator
• Re-work crypt-run-generator (ignore what I've posted previously)
• Have crypt-run-generator track
  • If it should associate a key file with this device
  • If the key file has been found
  • If a hard coded retry limit has been reached for finding the key file
  • If an attempt has been made regardless of success or failure to setup the LUKS device
• Reloading of systemd and starting only the specific LUKS device will be done either:
  • If no key is required for this LUKS device
  • If the per LUKS device retry is reached
  • If the key file is found

crypt-run-generator should then run every 0.5 seconds from the settled queue inside initqueue. I'm not quite sure if crypsetup.target needs to be active for the boot process to continue, but adding another script to the queue for checking that all LUKS devices have attempted to be unlocked can cover this if required.

from dracut.

I know I'm late to the party and really needed rd.luks.key to work. At least in Fedora 30 creating a file named /etc/dracut.conf.d/hold-the-onions.conf which contains:
omit_dracutmodules+=" dracut-systemd systemd systemd-networkd systemd-initrd "
removes the systemd monkey-patching and lets dracut be dracut. This fixed it for me.

from dracut.