Cryptsetup ignoring KEYFILE_PATTERN

[Aimo Ella]

Steps to reproduce:

While installing Ubuntu (see versions below) into a LUKS1 container, I choose "Something else" for installation type and select installation-specific LVM volume for rootfs. During installation, before Grub gets installed at end, I inject support for encrypted /boot into the target rootfs by running:

echo "sda2pv UUID=$(cryptsetup luksUUID /dev/sda2) none luks" >> /target/etc/crypttab
echo 'GRUB_ENABLE_CRYPTODISK=y' >> /target/etc/default/grub

Once installation is over, I reboot into the newly installed Ubuntu. To avoid typing passphrase twice, I attempt to add a keyfile exactly as instructed:

# Add keyfile.
mkdir -p -m go=,u=rwx /etc/luks
( umask go=,u+rx && dd if=/dev/urandom of=/etc/luks/sda2.key bs=1 count=64 )
cryptsetup luksAddKey /dev/sda2 /etc/luks/sda2.key

# Deploy keyfile.
echo 'KEYFILE_PATTERN="/etc/luks/*.key"' >> /etc/initramfs-tools/conf-hook
echo 'UMASK=0077' >> /etc/initramfs-tools/initramfs.conf
sed "s|^\(sda2pv .*\) none \(.*\)$|\1 /etc/luks/sda2.key \2|" /etc/crypttab
update-initramfs -u -k all

Expected behaviour:

Loading the keyfile succeeds and Initramfs does not ask for passphrase any more (only Grub does).

Actual behaviour:

No matter how carefully I follow Cryptsetup documentation, every time I add refence to my keyfile into /etc/crypttab, update-initramfs tells me:

cryptsetup: WARNING: Skipping root target sda2pv: uses a key file

and does not load my keyfile into Initramfs, despite the matching KEYFILE_PATTERN setting.

I experience the problem both in Ubuntu 19.10 and Ubuntu 20.04 LTS (which have cryptsetup version 2.2.0 and 2.2.2, respectively). See attachment file encrypted-multi-buntu.txt for full yet brief account of my setup and motivations.

I have repeated the procedure over and over again,
 o with one single Ubuntu and two,
 o with Secure Boot disabled and not,
 o with resume from hibernation disabled and not,
 o with /boot and swap in rootfs volume and in separate volumes,
 o and more,
but have not found a solution.

My main sources:
 o documents in /usr/share/doc/cryptsetup-initramfs/
 o https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
 o https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019

I have come to the conclusion that cryptsetup does not behave as documented. Either the behaviour or the documentation has to be corrected. Which is it?

[Enrico Calrissian (enricocalrissian)]

I have the same Problem on Ubuntu Server 20.04.1 Release.

I followed the Post-Installation-Steps from https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019.

If you add the Keyfile for the root-Partition to /etc/crypttab and update the initramfs, it will Warn with th above said warning:

WARNING: Skipping root target md1_crypt: uses a key file

On a reboot, the initramfs does not even ask for a password anymore, it just fails.

Very weird that we seem to be the only people on the internet having this problem.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Taylor Armstrong (taylor++)]

I am assuming you messed up string for telling initramfs using the keyfile:

# Deploy keyfile.
echo 'KEYFILE_PATTERN="/etc/luks/*.key"' >> /etc/initramfs-tools/conf-hook

You want to setup luks-encryption so you need address 'cryptsetup':

Edit: "/etc/initramfs-tools/conf-hook" into "/etc/cryptsetup-initramfs/conf-hook"

Resulting to:

# Deploy keyfile.
echo 'KEYFILE_PATTERN="/etc/luks/*.key"' >> /etc/cryptsetup-initramfs/conf-hook

Regenerate initrd:

update-initramfs -u -k all

You should not get 'cryptsetup: WARNING...' and after rebooting you should get asked for passphrase just once. Let me know if it is working that way.

[Aimo Ella (aimo-ella)]

Yes, that is it. Now, it has been three years, and I cannot remember the whole situation anymore, but I was convinced that I had followed the instructions to the tee. Since I could not understand where the problem was, I did not include links to the specific pieces of documentation, so now I cannot check if the problem was there or if I just had made a mistake. Anyway, thank you for helping out.

[Taylor Armstrong (taylor++)]

This report came around the corner by googling for keyfile-topic. I just read 2022-05-28... Maybe the solutions will free somebody else from headache much faster...