[Bug 1813295] Re: initramfs-tools MODULES=dep causes LUKSv2 unlock to fail

[TJ]

** Description changed:

  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.
+ 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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/1813295

Title:
  initramfs-tools MODULES=dep causes LUKSv2 unlock to fail

Status in cryptsetup package in Ubuntu:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1813295/+subscriptions