Ubuntu
cryptsetup package

  1. Bug #1813295
  2. Activity log

Activity log for bug #1813295

Date Who What changed Old value New value Message
2019-01-25 13:22:11 TJ bug added bug
2019-01-25 16:06:13 TJ 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. I need to confirm which modules but currently it looks like af_alg, algif_skcipher, algif_hash. 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 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 additional to the auto-detected modules.
2019-01-25 16:06:18 TJ cryptsetup (Ubuntu): status New Confirmed
2019-01-25 16:07:12 TJ 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 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 additional to the auto-detected modules. 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 additional to the auto-detected modules.
2019-01-25 16:07:35 TJ 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 additional to the auto-detected modules. 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.
2019-01-27 17:20:05 TJ 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. 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.