Generic initrd does not work with encrypted root FS without further configuration

[LaszloGombos]

Moving downstream discussion here upstream from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029324

with an encrypted root fs, the system will end up with a configuration which looks something like this:

/etc/crypttab:
    <dev>_crypt UUID=<some_uuid> none luks,discard

/etc/fstab:
    /dev/mapper/<some_LVM_LV> / ext4 <options>

/boot/grub/grub.cfg:
    linux /vmlinuz-6.0.0-6-amd64 root=/dev/mapper/<some_LVM_LV> ro quiet

Now, after switching to dracut, the new initrd which is built will not contain the necessary configuration to actually setup the "_crypt" device, since autoconfiguration (rd.auto) is disabled and a hostonly initrd (which would include a custom /etc/crypttab in the initrd) is not built.

The result is an initrd which will hang waiting for /dev/mapper/ to show up, and which will eventually time out.

A workaround for now is to change /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet rd.auto=1"

This, however, means that the name of the crypt device will change from "_crypt" (as specified in /etc/crypttab) to "luks-", which will result in ugly error messages during boot (that's mostly cosmetic though) since systemd will fail to setup the device "_crypt".

That, in turn, can be fixed by changing /etc/crypttab from:

_crypt UUID= none luks,discard so that it reads: luks- UUID= none luks,discard A further problem with building the generic initrd is that custom crypt addons (like the fido2 support) won't be included in the initrd even if fido2 is defined in /usr/lib/dracut/modules.d/90crypt/module-setup.sh ("fido2-device=auto"). CC @Alphix

[HNA-JP]

I'm not sure what I'm doing wrong, but with more-or-less the same setup I'm finding Dracut isn't respecting /etc/crypttab.initramfs or /etc/crypttab.initrd at all.

Dropping to the emergency shell shows /etc/crypttab in the initramfs image has something like:

luks-<LVM-LV-UUID>  /dev/dm-1    none  luks,discard

This means appending rd.auto to the GRUB cmdline works as mentioned as it'll attempt rd.luks with rd.luks.crypttab=yes by default.

I found including the crypttab.initrd I had by manually by renaming it to just crypttab and running dracut -f --regenerate-all --include /etc/crypttab didn't work either as the file either isn't included or gets overwritten part way through generation.

Running dracut with --print-cmdline makes me think it would be a moot point even if I did manage to get the correct crypttab in the image however as the cmdline parameters bind to the LVM LV UUID and name luks-<LVM-LV-UUID> anyways.

My question is, is there something you need to do for dracut to respect crypttab.initramfs or crypttab.initrd?

[LaszloGombos]

@HNA-JP which version of dracut and which Linux distribution ?

Dracut isn't respecting /etc/crypttab.initramfs or /etc/crypttab.initrd

Can you please point to dracut documentation that would suggest to use crypttab.initramfs or crypttab.initrd ? Are you coming from another initrd generator where you used these before and now you expect that dracut works the same way ?

If hostonly is what you want, you can still enable hostonly for your machine even if distribution defaults to non-hostonly. In hostonly mode dracut will respect /etc/crypttab.

The point of hostonly is that it is configured for your host. The point of generic is that it does not have knowledge of your host, so it needs additional configuration to work.

[HNA-JP]

@HNA-JP which version of dracut and which Linux distribution ?

Ubuntu Mantic (23.10) with dracut-059-4ubuntu2

Can you please point to dracut documentation that would suggest to use crypttab.initramfs or crypttab.initrd ? Are you coming from another initrd generator where you used these before and now you expect that dracut works the same way ?

Apologies- I seem to have misunderstood a couple things about dracut. I wasn't aware of what hostonly would do and assumed generic meant it wasn't distro specific.

I don't know what I did, but ironically I found dracut wasn't actually creating the necessary facilities to boot the system until I created a crypttab.initramfs file. When Googling around for dracut crypttab configs I had found a whole slew of threads to suggest it, but I'm now seeing there isn't any actual documentation on any of dracut's manpages, nor direct references to dracut in relation a lot of the times. I was misunderstanding posts about systemd-cryptsetup-generator, I think.

Running dracut with hostonly does indeed result in a working initramfs image however, so thank you for pointing me in the right direction.

On another note, generating an initramfs image with hostonly seems to result in duplicate root kernel parameters

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.0-28-generic root=/dev/mapper/luks-<LVM-LV-UUID> ro init=/usr/lib/systemd/systemd rd.luks.name=<LVM-LV-UUID>=nvme0n1p5_crypt root=/dev/mapper/nvme0n1p5_crypt quiet splash vt.handoff=7

That's an issue for another thread, though.

Thanks again @LaszloGombos