Cryptsetup ignoring KEYFILE_PATTERN

Bug #1879146 reported by Aimo Ella
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

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?

Revision history for this message
Aimo Ella (aimo-ella) wrote :
Revision history for this message
Enrico Calrissian (enricocalrissian) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Revision history for this message
Taylor Armstrong (taylor++) wrote :

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.

Revision history for this message
Aimo Ella (aimo-ella) wrote :

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.

Revision history for this message
Taylor Armstrong (taylor++) wrote :

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...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.