FS#67597 - [dracut] Linux 5.8.1 fails to decrypt LUKS drive with hostonly dracut image
Attached to Project:
Arch Linux
Opened by STPR (stpr) - Sunday, 16 August 2020, 01:38 GMT
Last edited by Jelle van der Waa (jelly) - Thursday, 14 September 2023, 17:54 GMT
Opened by STPR (stpr) - Sunday, 16 August 2020, 01:38 GMT
Last edited by Jelle van der Waa (jelly) - Thursday, 14 September 2023, 17:54 GMT
|
Details
Description:
Additional info: * Linux Zen 5.7.12 -> Linux Zen 5.8.1, Linux 5.7.12 -> Linux 5.8.1, dracut 050-1 * lsinitrd for both non-fallback and fallback attached. * unknown Steps to reproduce: - Upgrade kernel to 5.8.1. - Reboot system and try to use the non-fallback initramfs (i.e. --hostonly). - Prompts for LUKS password, but errors after entering the password, with indications that it was unable to decrypt the drives. Error messages on screen: "encrypted_key failed to alloc_cipher (-2)." "table: 254:0 crypt: unknown target type." "Failed to start Cryptography Setup for system" - Reboot and use fallback kernel (i.e. --no-hostonly). - Works fine. Now downgrade kernel to 5.7.12 and rebuilt both initramfs images. Reboot. - Non-fallback initramfs works fine. Additional notes: I can reproduce this for both zen and regular kernels. I took a quick look at the lsinitrd outputs and I did not see any obvious differences. I am lost on why it is not booting. I do not know what other logs to attach, so please let me know if you need anything else. |
This task depends upon
Closed by Jelle van der Waa (jelly)
Thursday, 14 September 2023, 17:54 GMT
Reason for closing: Deferred
Additional comments about closing: Old kernel, please retry with the latest
Thursday, 14 September 2023, 17:54 GMT
Reason for closing: Deferred
Additional comments about closing: Old kernel, please retry with the latest
Thanks
I tried adding the dm-crypt kernel module to the MODULES array in mkinitcpio, and regenerated the kernel images. On linux-lts, same (correct) decryption behavior occurred. Conversely, using linux 5.8.1-arch1, I get an additional systemd error saying that the systemd-modules-load.service unit failed upon boot, right before drive decryption.
This is looking more like a systemd issue than a dracut one.
@Leopold
Are you using a systemd based mkinitcpio initramfs or a busybox based? If you're using systemd based, and this is is indeed a systemd issue, then it would explain it affecting both dracut and (systemd base) mkinitcpio.
I have no issues decrypting luks disks on 5.8.1 with a busybox based mkinitcpio initramfs.
I also realise that there is another bug open that points to systemd having issues (https://bugs.archlinux.org/task/67517), perhaps that might explain it?
It could be that
FS#67517has something to do with it. If you can get the journal from that unit that's failing, it would be helpful to see if it's the full path issue.From there, I get that two units are failing, with the indication that the units are crypsetup units that handle the decryption of the two LUKS encrypted drives I have on my PC. I have attached the systemctl status log corresponding to the root drive here, but the other one is similar as well.
Additionally, I was able to grab the rdsosreport as well, and I have attached that here. Seems similar to journalctl logs, so I will skip attaching that here.
rdsosreport.txt (126.1 KiB)
I have the following package(s) installed:
- dracut 050-1
- systemd 246.2-1
- linux 5.7.12arch1-1
And the issue has persisted ever since kernel 5.8.0.
Following is journalctl output from recovery shell:
journalctl:
systemd-cryptsetup[324]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/<UUID>
kernel: encrypted_key: failed to alloc_cipher (-2)
kernel: encrypted_key: failed to alloc_cipher (-2)
kernel: encrypted_key: failed to alloc_cipher (-2)
systemd-cryptsetup[324]: device-mapper: reload ioctl on failed: invalid argument
kernel: device-mapper: table 254:0: crypt: unknown target type
kernel: device-mapper: ioctl: error adding target to table
kernel: encrypted_key: failed to alloc_cipher (-2)
kernel: encrypted_key: failed to alloc_cipher (-2)
systemd-cryptsetup[324]: Failed to activate with specified passphrase: Invalid argument
Downgrading systemd to 245.7 did not help. Only downgrading linux or switching to the LTS kernel helped. Does anyone know what kernel module provides these crypto functions? I'd like to check my initramfs for it?
1. Boot into a working kernel (if this kernel is 5.8.1 w/ fallback, skip to 3)
2. Create a bootloader entry for 5.8.1 with the fallback initramfs generated with `--no-hostonly`
3. Boot into the 5.8.1 fallback initramfs
4. Re-generate your initramfs with `--hostonly`
5. Reboot into the non-fallback initramfs
6. It Just Werks™
I guess this is an issue with how dracut is parsing dm_crypt modules while running from 5.7 and not finding them correctly for 5.8? I'm not sure.
/usr/lib/modules/5.8.1-arch1-1/kernel/crypto/blake2b_generic.ko.xz
/usr/lib/modules/5.8.1-arch1-1/kernel/crypto/cbc.ko.xz
/usr/lib/modules/5.8.1-arch1-1/kernel/crypto/ecc.ko.xz
/usr/lib/modules/5.8.1-arch1-1/kernel/crypto/ecdh_generic.ko.xz
There is also references to these modules in /usr/lib/modules/5.8.1-arch1-1/modules.* files, that are missing in the 5.4 built initramfs.
FS#67802for reasoning.It definitely had encrypted-keys.ko.xz in it.
I've now tried the suggestions in this thread. I installed dracut-git 050.r145.a5372b8b-1.
After manually booting from a rescue shell as described in
FS#67802and generating a new initramfs, I was able to boot without a problem. No fallback necessary.Thanks for the suggestions, guys.
What happened exactly was for another, unrelated bug I needed to spend some time in LTS (5.4.x), and I had been still updating the linux package during that time. When I built my initramfs for 5.9.9, I was on 5.4.77. After updating to 5.9.9, while still booted into 5.4.77, I rebooted and was greeted with the same error. The same steps resolved it.
1. boot into 5.9.9 fallback-initramfs
2. force rebuilt of initramfs while booted into 5.9.9
3. reboot into 5.9.9 again, with a working initramfs
None of this is new information I guess, but I wanted to mention that this bug very much still exists on the latest dracut and latest kernel. For anyone who has to switch between stable and LTS and uses encrypted disks, I hope this helps.