Dracut /etc/crypttab Support in Initramfs

[nick_0189]

Hello everyone,

In summary: Generally, when will Dracut use a crypttab file in the initramfs?

I'm trying to understand the documentation for Dracut and how I should configure it for my installation. Specifically, I don't understand the relationship between `/etc/crypttab` and Dracut. Dracut includes an option for parsing a crypttab file (`man dracut.cmdline`, `rd.luks.crypttab`), but crypttab seems to really be more of a systemd thing and I can't get Dracut to unlock root with a crypttab file embedded in the initramfs at `/etc/crypttab` - a custom module or cmdline arguments are required to unlock it. Does it unlocking root from information in a crypttab file work for anyone else? How much support does Dracut actually have for a crypttab file, since it is mentioned only briefly in the documentation and in the code?

In the source code here it looks like Dracut parses a crypttab file when the `rd.hostonly` option is passed, but why does it seem like it actually doesn't support a crypttab file the way I think it does?

I can't find anything specifically stating that Dracut doesn't support a crypttab file, and I can't find anything specifically outlining the extent to which Dracut supports a crypttab file. It's confusing to me. Any clarification would be helpful.


Thank you.

[sMueggli]

Generally Dracut does not need/read the /etc/crypttab. But that is only "generally" the case.

[grknight]

In the general sense, cryptroot-ask.sh is triggered by the bootup process via a udev rule and it will read crypttab if it exists.
However, it only reads it for your defined name of the device mapper location (e.g. /dev/mapper/gentoo-crypt) once the device has already been scheduled to open.
All the devices to query and open are done via one of the rd.luks command options.

[nick_0189]

Hi grknight,

Thank you for your response. So Dracut only uses crypttab to open volumes specified with a `rd.luks` cmdline option? So if I wanted to open two disks `cryptdisk1` and `cryptdisk2`, I would need to add the following to my configuration at `/etc/dracut.conf.d/luks.conf`:

[sMueggli]

Let's assume you have two LUKS containers. One of them contains your system (FDE, no unencrypted /boot) and the other contains sensitive work stuff. Having a kind of FDE with an unencrypted /boot makes the life easier for Grub, but not for the kernel or Dracut.

When your system boots it needs to unlock the system and mount it to /. The firmware (UEFI nowadays) loads the bootloader from the (unencrypted) ESP (or from the hard disk in case of BIOS boot mode).

The bootloader needs to load kernel and initramfs. Because /boot resides inside a LUKS container Grub needs to unlock the container (no need for /etc/crypttab), read and execute the /boot/grub/grub.cfg and load the kernel and initramfs.

The loaded kernel needs to mount the system to /. Because the system resides inside a LUKS container the kernel needs to unlock the system first with the help of an initramfs, but again, the crypttab is not needed. If that happened the kernel can start and do other stuff like mounting the second LUKS container.

The job of Dracut is to generate a "useful" initramfs (being able to unlock a LUKS container and mount it and provide kernel modules and firmware).

The LUKS container with the system does not need to be part of the crypttab (my FDE does not even have a crypttab). And crypttab is read later, after the "Dracut magic" happened.

Please note that it is not good practice to use the same LUKS key for several LUKS containers. If you only want one key, you should also put everything into the same LUKS container. If you have several LUKS container, you should also use different keys.
And because you are adding the LUKS key to the initramfs you need to have an encrypted /boot. Otherwise you do not need encryption because everyone (including attackers) can unlock your container with the help of the LUKS key in the unencrypted initramfs.