Cryptsetup ignoring KEYFILE_PATTERN

Bug #1879146 reported by Aimo Ella
10
This bug affects 2 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
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers