[Bug 1979159] Re: Cannot unlock encrypted root after upgrading to 22.04

Thu Aug 11 16:21:09 UTC 2022

This bug was fixed in the package cryptsetup - 2:2.5.0-1ubuntu1

---------------
cryptsetup (2:2.5.0-1ubuntu1) kinetic; urgency=medium

  * Merge from Debian unstable. Remaining changes:
    - debian/control:
      + Recommend plymouth.
      + Depend on busybox-initramfs instead of busybox | busybox-static.
      + Move cryptsetup-initramfs back to cryptsetup's Recommends.
      + Do not build cryptsetup-suspend binary package on i386.
    - Fix cryptroot-unlock for busybox compatibility.
    - Fix warning and error when running on ZFS on root: (LP: #1830110)
      - d/functions: Return an empty devno for ZFS devices as they don't have
        major:minor device numbers.
      - d/initramfs/hooks/cryptroot: Ignore and don't print an error message
        when devices don't have a devno.
    - debian/patches/decrease_memlock_ulimit.patch
      Fixed FTBFS due to a restricted build environment
    - Stop building the udeb on request.
  * d/initramfs/hooks/cryptroot: Include OpenSSL legacy.so for ripemd160 and
    whirlpool hash algorithms (LP: #1979159)
  * Disable failing Debian-tailored cryptroot-* autopkgtests, see bug #1983522

cryptsetup (2:2.5.0-1) unstable; urgency=medium

  * d/copyright: Fix licence for tokens/ssh/cryptsetup-ssh.c.
  * Remove patches applied upstream.
  * Rename 'ssh-plugin-test' to 'ssh-test-plugin'.
  * Add DEP-8 tests for cryptroot unlocking at early boot stage.

cryptsetup (2:2.5.0~rc1-3) experimental; urgency=medium

  * DEP-8: Add 'Features: test-name=' in order to name inline tests.
  * d/t/control: Add 'Restrictions: rw-build-tree' to upstream-testsuite.
  * d/control: Remove cryptsetup-reencrypt from cryptsetup-bin package
    description since the utility was removed upstream in v2.5.0-rc1.
  * d/changelog: Retroactively correct 2:2.4.0~rc0-1+exp1 entry.
  * Update d/patches with what's landed upstream since v2.5.0-rc1.
  * d/patches, d/rules: Pass $(LDFLAGS) when building fake_token_path.so and
    no longer silence blhc(1) for test files.
  * Move SSH token plugin stuff into new binary package 'cryptsetup-ssh'.
    That plugin is arguably not useful for everyone and we can save the
    'Depends: libssh-4' on cryptsetup-bin by moving cryptsetup-ssh(8) and
    libcryptsetup-token-ssh.so to a separate package.  Since LUKS2 SSH token
    support was added after the Bullseye release, and since it is still in
    experimental stage, we don't let cryptsetup-bin or cryptsetup depend on
    the new binary package.  Users who need that feature will need to install
    it manually.

cryptsetup (2:2.5.0~rc1-2) experimental; urgency=medium

  * localtest: Treat skipped tests as failure for full coverage.
  * d/watch: Add uversionmangle option for release candidates.
  * unit-wipe-test: Skip DIO tests when the file system doesn't support
    O_DIRECT.  This is needed on the buildds where the source tree appears to
    be on a tmpfs.

cryptsetup (2:2.5.0~rc1-1) experimental; urgency=low

  * New upstream release candidate 2.5.0.  Highlights include:
    + Remove cryptsetup-reencrypt(8) executable, use `cryptsetup reencrypt`
      instead (for both LUKS1 and LUKS2).
    + Split manual pages into per-action pages, for instance cryptsetup-open.8
      which can be consulted with `man cryptsetup open`.
    + Add LUKS2 encryption removal support with `cryptsetup reencrypt
      --decrypt`.
    + Preserve unknown metadata option (features implemented in more recent
      cryptsetup releases) during reencryption.
  * Salsa CI's deploy stage: Use a Bullseye image.
  * Salsa CI's deploy stage: Use apt-get(8) not apt(8).
  * Salsa CI's deploy stage: Replace `cp` with `install`.
  * Salsa CI's reprotest job: Remove '--no-diffoscope' flag.
  * Salsa CI's reprotest job: Update reason for running under 'nocheck' build
    profile.
  * d/README.source: Update text to reflect current practices.
  * DEP-8: Run installed binaries and libraries through the full upstream test
    suite (needs machine-level isolation).
  * Retroactivately add NEWS.Debian for #949336.
  * d/t/control: Add 'Depends: xxd' for 'Tests: cryptdisks' stanza.
  * foreach_cryptdev(): Process each device *after* its slaves.
  * do_stop(): Remove device holders beforehand. (Closes: #1006802)
  * Fix space damage.
  * d/u/metadata: Add FAQ URL.
  * Refresh lintian overrides to accommodate lintian v2.115.
  * d/control: New Build-Depends: asciidoctor (unless under 'nodoc' build
    profile).
  * d/cryptsetup.docs: Fix FAQ filename.
  * Move usr/share/man/*/* glob to debian/*.manpages where it belongs.
  * Update d/libcryptsetup12.symbols.
  * Bump Standards-Version to 4.6.1 (no changes needed).
  * Update d/copyright.

 -- Benjamin Drung <bdrung at ubuntu.com>  Thu, 04 Aug 2022 12:30:02 +0200

** Changed in: cryptsetup (Ubuntu Kinetic)
       Status: Fix Committed => Fix Released

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

Status in cryptsetup package in Ubuntu:
  Fix Released
Status in cryptsetup source package in Jammy:
  Fix Committed
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