Encrypting root with dracut, grub & systemd-cryptsetup-generator

I use a grub endeavouros install. I am looking to encrypt that system, with /boot and /boot/efi on unencrypted partitions, while root and swap live on encrypted partions.

It should be possible with systemd-cryptsetup-generator, dracut + grub, but I can’t find suitable documentation.

(see below for my setup)

  1. Does dracut figure out the root partition based on fstab and crypttab automatically, or do I need to explicitly configure it? How do I do that? mk-grub produces root=UID=roo-luks, but that points to the luks container, not to its parent partition roo. I assume that is wrong?

  2. I assume that crypttab.initramfs special treatment is respected?

  3. I accidentally lost my EFI partition, I regenerated it with grub-install --no-nvram. Thats ok?

My setup

├─sda1   vfat      FAT32                 efi           /boot/efi
├─sda2   crypto_LU 2                     roo                                   
│ └─root ext4      1.0                   roo-luks      /
├─sda3   crypto_LU 2                     swa                                       
│ └─swap swap      1                     swa-luks                                          
└─sda4   ext4      1.0        boot       boo          /boot

$ cat /etc/crypttab.initramfs
root          UUID=roo  root          timeout=180
swap          UUID=swa  none          timeout=180

$ cat /etc/fstab
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=boo                    /boot
UUID=efi                    /boot/efi             vfat    defaults,noatime 0 2
/dev/mapper/root                   /              ext4   defaults,noatime 0 1
/dev/mapper/swap                   swap           swap    default 0 0
tmpfs                             /tmp            tmpfs   defaults,noatime,mode=1777 0 0

$ cat /etc/dracut.conf.d/luks.conf
install_items+=" /etc/crypttab.initramfs "
add_device+=" /dev/disk/by-uuid/swa "

$ cat /etc/default/grub 
GRUB_CMDLINE_LINUX_DEFAULT='nowatchdog nvme_load=YES resume=UUID=swa loglevel=3'

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices

This looks particularly wrong:

$ cat /boot/grub/grub.cfg 
    echo    'Loading Linux linux ...'
    linux   /vmlinuz-linux root=UUID=roo-luks rw  nowatchdog nvme_load=YES resume=UUID=swa loglevel=3

As I see, your setup and config output are completely wrong.

roo-luks is not real UUID identifier.

I never heard it.

roo and swa are not real UUID identifier.

Nobody can help you if you do not want to give real output here.

I simplified the UUIDs, thats all. :slightly_smiling_face:

That one is copied verbatim though, but rest assured that this is correct.

Still, they confuse us, for example:

Both do not match or not. That is hard to know.

Thanks for trying though! I think we should rest that and keep it to the three questions from the OP so that others could chime in as well.
My confusion mainly stems from the scope of dracut, I think the choice for dracut was understandable back in the days, but I dread it since the arch wiki really is centered around mkinitcpio and the docs for dracut are extremely poor imho.

I have the feeling that I still need to specify the root partiton manually in GRUB_CMDLINE_LINUX_DEFAULT for dracut. (But then, what is dracut --print-cmdline doing? Is that only applicable to systemd-boot?).

I was hoping someone could tell me how dracut and grub are supposed to work together. I will go with an explicit root param in GRUB_CMDLINE_LINUX_DEFAULT if no one can tell me that.

dracut itself is flexible. It can take the kernel options from the bootloader or it can manage the kernel options itself.

EndeavourOS uses the bootloader to manage kernel options so if you want to stay close to what we do the correct place would be to change GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.

I have never tested using /etc/crypttab.initramfs so I don’t know if that is mkinitcpio-specific or not.

That being said, in the situation you are describing is there a reason to use that instead of /etc/crypttab directly?

That should be fine.


Well, I like the distinction being made where systemd-cryptsetup-generator will pick up all stuff from crypttab.initramfs for stuff that needs to be really early, and crypttab for stuff during the booting process/on demand.

I like the idea, but I am like you not sure if only mkinitcpio supports this. I saw in the arch wiki talk that crypttab.initramfs did not work for dracut, but I am not sure if that is due to an older version of dracut, or that one needs to explicitly have this as an install_file too for dracut.

Is that something I can check before I boot into a broken system?

Yes, rebuild your boot images and then look inside the image and examine the contents of /etc/crypttab and see if the contents were replaced.

I can see that crypttab is not there, but crypttab.initramfs is. So, this won’t work?

from arch wiki:

If the file /etc/crypttab.initramfs exists, it will be added to the initramfs as /etc/crypttab,

Since that is not what we observe with dracut, it seems that this is really specific for mkinitcpio I think.

1 Like

One more question, dracut-rebuild seems to not pick up my changed crypttab. I am in arch-chroot via a livecd, I am confused how I could build the initramfs earlier on. Any help?

EDIT: dracut --regenerate-all --force does work, not sure why dracut-rebuild doesn’t,

dracut --regenerate-all --force generates something equivalent to our fallback images.

If you want /etc/crypttab added you need to do it explicitly. The installer adds config for this if you choose encryption during the install. Honestly, the installer handles all this stuff for you.

Yes, but this was done to see if I could get an existing system to be encrypted. If I change crypttab and it is part of install_file+=" /etc/crypttab ", I should thus not expect drabut-rebuild to pick that changed file up for the initramfs build, correct?
I will stick with racut --regenerate-all --force in that case.

No, if you have config to pull in that file. It definitely should pull it in. Can you share the full contents of the conf file you created to pull that file in? What you have above is not correct. It should be:

install_items+=" /etc/crypttab "

Be aware that dracut --regenerate-all --force probably won’t generate the fallback images so those will be out of date. Also, when a new kernel gets installed, it won’t be called.

This was an experiment so its not critical. I got the encryption for the root device working.
I had copied its contents with cp, so currently the system is a mess and fixing the permissions is a never ending story, so I only can share a screenshot

I believe add_dracutmodules is not needed, but anyways: