initramfs-tools MODULES=dep causes LUKSv2 unlock to fail
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-
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-
https:/
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-
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.
description: | updated |
Changed in cryptsetup (Ubuntu): | |
status: | New → Confirmed |
description: | updated |
description: | updated |
description: | updated |