initramfs-tools MODULES=dep causes LUKSv2 unlock to fail

Bug #1813295 reported by TJ
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

This is affecting 18.04 and others where cryptsetup v2 is used and has created a LUKS v2 container.

If booting to a shell in initialramfs with "break=premount" and manually executing:

cryptsetup --debug open /dev/sda3 LUKS_VG
...
Userspace crypto wrapper cannot use aes-xts-plain64 (-95)
...

-95 is -EOPNOTSUPP

Critical modules required are missing from the initrd.img when /etc/initramfs-tools/initramfs.conf contains:

MODULES=dep

There is a similar bug in Debian but that is related to Debian not including the 'xts' module when the CPU doesn't support aesni. In Ubuntu 'xts' is built-in to the kernel image.

"cryptsetup-initramfs: Unbootable initrd compiled with MODULES=dep on systems lacking AES-NI"

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901884

However the underlying Debian fix may solve this case too; I've yet to get to a state where I can test that.

In the Ubuntu case it appears the modules required are the algorithm interface modules.

The workaround is adding these modules to /etc/initramfs-tools/modules:

algif_skcipher
algif_hash
algif_aed
algif_rng

Because these belong to the crypto user API I cannot see a way for the cryptsetup hook script to determine if these are needed (presumably it'd need to consider the 'luksDump' output to see what is being used).

The easiest solution might be to always ensure these modules are added by the hook in addition to the auto-detected modules.

TJ (tj)
description: updated
Changed in cryptsetup (Ubuntu):
status: New → Confirmed
description: updated
description: updated
TJ (tj)
description: updated
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.