[Bug 1979159] Re: Cannot unlock encrypted root after upgrading to 22.04 due to use of non-standard ciphers

[Matthias Haller]

I had the same problem with my focal system. The computer ran for a few
days and meanwhile updates were installed. After a reboot, my password
for the root partition was no longer accepted.

The solution that worked for me was to convert the LUKS header to version 2.
It worked with these instructions: https://gist.github.com/Edu4rdSHL/8f97eb1bab454fb2b348f1167cee7cd2

-- 
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/1979159

Title:
  Cannot unlock encrypted root after upgrading to 22.04 due to use of
  non-standard ciphers

Status in cryptsetup package in Ubuntu:
  Fix Released
Status in cryptsetup source package in Jammy:
  Fix Released
Status in cryptsetup source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  After upgrading to Ubuntu 22.04 with an encrypted root filesystem, the
  root drive can no longer be unlocked at the "Please unlock disk
  <diskname>" prompt on boot.

  The encrypted root disk can be unlocked fine from the liveCD, but not
  from the initramfs environment on boot.

  The issue is caused by support for various luks encryption protocols
  now being missing from the initramfs environment due to changes
  introduced in OpenSSL 3.0 and Ubuntu pre-release testing not including
  a test-case of upgrading older Ubuntu versions with an encrypted root
  to the new version.

  [Test Plan]

  Test a fresh installation:

  * Use Ubuntu 22.04 installer
  * Prepare encrypted disk layout (first partition /boot, second for /) and go one step back
  * Then change hash in terminal
  ```
  sudo cryptsetup close vda2_crypt
  sudo cryptsetup luksFormat --hash=whirlpool /dev/vda2
  sudo cryptsetup luksOpen /dev/vda2 vda2_crypt
  sudo mkfs.ext4 /dev/mapper/vda2_crypt
  ```
  * Continue and complete installation
  * Ensure that /target/etc/crypttab exists (if not, create it and run "update-initramfs -u" in "chroot /target")
  * Reboot
  * The system should ask for the password during boot and successfully boot into the desktop

  Test an upgrade:

  * Install Ubuntu 20.04 (similar to above)
  * Upgrade to Ubuntu 22.04
  * Reboot
  * The system should ask for the password during boot and successfully boot into the desktop

  [Where problems could occur]

  The changed code is called when running "update-initramfs". Therefore
  generating a new initramfs could fail (and the user would stay on an
  old one). Upgrading the package will trigger "update-initramfs". So
  bugs in initramfs (or it scripts) can be triggered at that time.

  [Workaround]
  The issue can be worked-around by:
  1.  Booting from the 22.04 liveCD.
  2.  chrooting into the target system's root.
         See https://help.ubuntu.com/community/ManualFullSystemEncryption/Troubleshooting
  3.  Creating a file /etc/initramfs-tools/hooks/custom-add-openssl-compat.conf containing:
  ---
  . /usr/share/initramfs-tools/hook-functions
  copy_exec /usr/lib/x86_64-linux-gnu/ossl-modules/legacy.so /usr/lib/x86_64-linux-gnu/ossl-modules/
  ---
  4.  Mark the file as executable: chmod +x /etc/initramfs-tools/hooks/custom-add-openssl-compat.conf
  5.  Regenerating the initramfs.  ie. update-initramfs -k all -u

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