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"
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.
I need to confirm which modules but currently it looks like af_alg, algif_skcipher, algif_hash.