Today I updated system , after reboot , i am unable to decrypt my root partition
Although i can decrypt partition using chroot from live iso
Logs:
cryptsetup luksDump <device>
http://paste.debian.net/1259733
cat /etc/default/grub
http://paste.debian.net/1259734
cat /etc/mkinitcpio.conf
http://paste.debian.net/1259735
--
Help me to diagnose
Tell me which logs do I provide
You can have a look inside pacman.log in /var/log/
Notice which packages you upgraded lately that may have caused the problem. From what i know cryptsetup package is responsible for encryption and i saw was 2 days ago pushed from testing repo to core so you can start from there.
Another fix you can try is using an external keyboard that can rule out a keyboard issue so you'll know for sure your passphrase isn't messed up.
I just had a similar issue. A new openssl version was pushed (and a openssl-1.1 package was introduced) as well as updates to cryptsetup and friends were made. Today my encrypted boot/root failed to start and it was due to those updates. cryptsetup complained that it was missing the whirlpool hashing algorithm when I was trying to decrypt my root partition from within the rescure prompt.
I just used the better part of the last 3h to debug this issue, installed "downgrade" and reverted to older package versions as well as installed openssl-1.1 and lib32-openssl-1.1 which apparently are REALLY the owners of /usr/lib/libcrypto.* while pacman claims it's part of libxcrypt-compat package? Something is very wrong.
ALSO. Someone though its a good idea to replace /etc/default/grub with a new version and move the original to grub.pacsave. Who though that was a good idea I cannot fathom. But this is bad. Very bad.
Did cryptsetup give any kind of specific error like with eNTi's stating missing support for an algorithm?
Also I would recommend checking if the kernel that you're using has support for your algorithm just to be sure.
On a live system, do a
gunzip -c /proc/config.gz | grep -Fi serpent to see if support for it even exits ( it exists on my system in the form of
CONFIG_CRYPTO_SERPENT=m ).
But since I'm assuming you can't even boot this will not work and I could not find a way to get info out of the kernel image in /boot.
⚠ First thing first you have to start making a backup for important files ⚠
I think we are now on openssl 3.0.7-2 not on 1.1
If i were you i would reinstall grub . My opinion is that even if you upgraded only cryptsetup and openssl i guess grub did not took them into consideration. So first downgrade as
@eNTi suggested reboot into a working system than upgrade cryptsetup + openssl again but before restart reinstall grub so this time grub will take into consideration all those changes made on cryptsetup and openssl 3.0.7-2
I think even cryptsetup and openssl make those necessary hooks into grub, secrets are not refreshed and have to be hooked properly with those essentials upgrades made by reinstalling grub again. Grain of salt included
mkinitcpio was complaining about not finding the libcrypt.so.1.1 BINARY and it's provided by openssl-1.1.
system/openssl-1.1 1.1.1.s-2 (1.8 MiB 5.5 MiB) (Installed)
The Open Source toolkit for Secure Sockets Layer and Transport Layer Security
system/openssl-1.0 1.0.2.u-1.1 (1.6 MiB 5.8 MiB) (Installed)
The Open Source toolkit for Secure Sockets Layer and Transport Layer Security
system/openssl 3.0.7-2 (5.1 MiB 10.7 MiB) (Installed)
The Open Source toolkit for Secure Sockets Layer and Transport Layer Security
My guess is that the encrypt HOOK in mkinitcpio.conf is requiring those versions? I'm guessing there isn't many people running a fully encrypted artix system with boot and root encrypted. Hence why this fell through the cracks and made my system unboobatle.
I've now to figure out why this happens. Another guess would be that whirlpool cipher has been removed for security reasons?
yes , it was whril pool removal was planned for openssl version 3
https://github.com/openssl/openssl/issues/5118
I guess users will have to re-encrypt.
There might be another solution, I took a look at the configure script at the cryptsetup source directory and found this:
--enable-static[=PKGS] build static libraries [default=no]
--enable-static-cryptsetup
enable build of static version of tools
My guess is that you can build a static cryptsetup with the specific openssl version that you need so you can keep your current encryption scheme.
I just would like to know why this affects users only just now? The change was done ages ago. There must be something else to this.
i have found this migration guide for hash
https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Migrating_from_Whirlpool_Hash_on_LUKS
I am able to sucessfully boot my system with data lost
this guide works
Quick observation: I just changed hash for root partition , home partition hash is still whirlpool and it booted without any issue
you need to change for all LUKS partition
Thank you for help to diagnose this problem
@eNTi @Surf3r @Lancia
Hi
@Arch_user, may I ask you to be more specific? Will the instructions in the guide you provided work, at the price of losing your data?
I have recovered my system without data loss , it worked for me
edit: Also read here https://bugs.archlinux.org/task/76440#comment212678
As usually, it's the users that get to pull the snake out of its hole. Thanks to everybody who troubleshot this. Pinning.
Arch Linux upstream added support for legacy algorithm support in cryptsetup (https://github.com/archlinux/svntogit-packages/commit/3cfa78fe78d335ddb406b388a7f85e2939b776c4) package. But I think migration is easy process. User should do migration instead sticking to vulnerable algorithm