5

I was running 20.04 and used sudo do-release-upgrade -d to upgrade to 22.04.

Everything seemed good and I was prompted to reboot, upon doing so I get the usual encrypted password entry screen but upon entering my password I get the message:

sda3_crypt: cryptsetup failed, bad password or options?

Pressing F1 shows:

Volume group vgubuntu not found

Cannot process volume group vgubuntu

The password is definitely correct, it's short and numeric so can't see it being a keyboard language issue.

After entering the password it says:

No key available with this passphrase

Any help here to try to get me back in?

kenorb
  • 10,944
bigdaveygeorge
  • 471

4 Answers4

2

I am currently experiencing the exact same problem, after doing the exact same upgrade. Good news! Your data is safe.

Setup: Encrypted LUKS partition containing LVM with root and swap partition. Boot partition unencrypted.

Problem: After do-release-upgrade -d (20.04 -> 22.04) unlocking LUKS during boot fails ("bad password or options" error) When booting with recovery mode I get a more useful error. Right before the prompt for cryptsetup appears there is the following error

/sbin/cryptsetup: symbol lookup error: /lib/x86_64-linux-gnu/libcryptsetup.so.12: undefined symbol: EVP_MD_get_size, version OPENSSL_3.0.0

Any password fails and the same error appears right before the new prompt appears. Similar to bidaveygeorge "vgubuntu not found" and similar messages appear Before the first prompt is shown.

My theory: The initramfs contains a cryptsetup which was compiled against openssl. The compiletime version differs from the version included in the initramfs. Disclaimer: I have no experience with the crypto ecosystem of Ubuntu. My programming experience would suggest such an error. The cryptsetup manpage mentions compiled-in backends.

Further research: As a temporary solution I downloaded a live USB Image of 22.04. I was able to mount my disk and analyze the initrd.img

root@ubuntu-mate:/# lsinitramfs /boot/initrd.img | grep ssl
etc/ld.so.conf.d/openssl-3.0.0-alpha14.conf
usr/local/ssl
usr/local/ssl/lib
usr/local/ssl/lib/libcrypto.so.3
root@ubuntu-mate:/# lsinitramfs /boot/initrd.img | grep cryptsetup
usr/lib/cryptsetup
usr/lib/cryptsetup/askpass
usr/lib/cryptsetup/functions
usr/lib/x86_64-linux-gnu/libcryptsetup.so.12
usr/lib/x86_64-linux-gnu/libcryptsetup.so.12.7.0
usr/sbin/cryptsetup

All following commands were executed as root:

cryptsetup open /dev/sda3 sda3_crypt

IMPORTANT the sda3_crypt part should be the same as the name used in your /etc/crypttab. Otherwise chroot wont work properly.

This automatically opened the LVM within the encrypted LUKS. If there is a plain FS behind LUKS, sda3_crypt should be the fs to mount.

mount /dev/mapper/my-vg--root /mnt
# No data is lost. Password works fine.

prepare chroot

mount --rbind /dev /mnt/dev
mount --rbind /run /mnt/run
mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys

sda2 is my boot partition

mount /dev/sda2 /mnt/boot

Chroot to be able to run commands on the non-bootable system

chroot /mnt

System fully up to date as of this post

apt update
apt upgrade
apt dist-upgrade
do-release-upgrade -d

Reinstalling has no effect

apt reinstall openssl cryptsetup cryptsetup-initramfs

Installing a new initramfs does not change anything.

update-initramfs -c -k all
slimy-development
  • 21
1

My previous comment confirming the given issue has been deleted. None of the given answers solves the underlying problem though.

The problem and solution is given in an ubuntu bug report.

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

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

Pilot6
  • 92,041
jdkbx
  • 11
0

No idea how I got around this but I found if I put a usb drive into the computer and then retried the password multiple times from the F1 screen it eventually let me in.

I then reset the encrypted password via the disks utility on the encrypted partition once in (the password was definitely correct as it flagged this when trying to reset it).

Since then it now works fine.

Now to just figure out a way to disable GNOMEs all applications menu from manually sorting applications and make it sort by A-Z.

bigdaveygeorge
  • 471
0

I've performed exactly the same steps to upgrade from 20.04 to 22.04 and ran into the very same issue. I have no idea what is the cause of it yet I was able to work around it by decrypting the partition using the old passphrase by booting from ubuntu live usb and adding a new one.

  1. Boot from the ubuntu live usb. I've used the 22.04 from the official downloads page.
  2. Using the UI I've unlocked the partition. - just try open the disk from file manager
  3. Determine which partition is the encrypted one. the partition UUID is stored on the /etc/crypttab relative to your drive. For example cat /media/GUID/ubuntu/etc/crypttab. Then use blkid | grep PARTITION_GUID <- change the guid to determine the partition name. In my case it was /dev/nvme0n1p3
  4. Add a new additional passphrase sudo cryptsetup luksAddKey /dev/nvme0n1p3 <- change the partition name. You will be prompted twice for a new passphrase.
  5. Reboot into your primary os

The old passphrase was still not working but the new one did the trick.

It is very likely that there is a more optimal way to achieve this but this one worked for me :p

Operatorius
  • 101