Created attachment 1644865 [details] boot failure 1. Please describe the problem: Tried kernel 5.4.2 from Koji. Booting fails with inability to unlock rootfs on LUKS. Transcribed messages: device-mapper: table: 253:0: crypt: Error allocating crypto tpm device-mapper: ioctl: error adding target to table 2. What is the Version-Release number of the kernel: kernel-5.4.2-300.fc31.x86_64 kernel-core-5.4.2-300.fc31.x86_64 kernel-devel-5.4.2-300.fc31.x86_64 kernel-modules-5.4.2-300.fc31.x86_64 kernel-modules-extra-5.4.2-300.fc31.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Yes, with 5.3.15-300.fc31.x86_64 and previous kernel it is fine. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: a) install 5.3.2-300.fc31 kernel b) reboot 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: n/a 6. Are you running any modules that not shipped with directly Fedora's kernel?: - wireguard - kmod-acpi_call 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Can't, as booting is nor progressing past initrd. I've attached a photo of error.
The problem persist with kernel-5.4.5-300.fc31.x86_64kernel-5.4.5-300.fc31.x86_64
The same with 5.4.7-200.fc31.x86_64
Created attachment 1649689 [details] boot failure photo
Tomasz, I also also use LUKS but it works for me using 5.4.7, haven't used previous versions. Just to know differences, looking at the photo seems that both of us are using passphrase. Which format do you have LUKS v1 or LUKS v2? Mine is v1.
Mine v1, too: LUKS header information for /dev/nvme0n1p6 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 4096 MK bits: 256 MK digest: <redacted> MK salt: <redacted> <redacted> MK iterations: 44625 UUID: 77cf2cba-6cab-4622-9563-fd808d7aed4f Key Slot 0: ENABLED Iterations: 178913 Salt: <redacted> <redacted> Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED
The only noticeable difference is the cypher/hash. I have aes xts-plain64 sha512.
The change over cbc I can see in the kernel between 5.3 and 5.4 is only applicable to arm architecture but you are using x86_64.
Same issue with me after upgrading today to kernel 5.4.7-200.fc31.x86_64 cannot boot from this kernel
Howto work around: (problem also ocurs on F30) * boot into working kernel * dracut -N /boot/initramfs-5.4.7-100.fc30.x86_64.img 5.4.7-100.fc30.x86_64 (disable host-only initramfs, generate a generic one) * now you should be able to boot using the 5.4 kernel * dracut -H /boot/initramfs-5.4.7-100.fc30.x86_64.img 5.4.7-100.fc30.x86_64 (we again have a host-only initramfs) * reboot again This worked for me. the crypto/essiv and crypto/authenc module were missing (and possibly others)
I can confirm that. Bulding NON-hostonly initramfs results in successfull boot. I guess that's a dracut bug.
since my e-mail reply did not make its way to here.... I think the problem is that dracut seems to take the list of modules from the running 5.3.x kernel which is different on 5.4 After such a 'repair' further 5.4 kernel updates should work normally - not yet tried due to influenza...
What about kernel x86_64 5.4.8-200.fc31 ¿has anyone tested if the luks issue is still present?
I have the same problem with kernel-5.4.10-100.fc30.x86_64. Workaround from comments above with dracut -N, dracut -H works for me, too.
(In reply to kkakini from comment #9) > Howto work around: (problem also ocurs on F30) > * boot into working kernel > * dracut -N /boot/initramfs-5.4.7-100.fc30.x86_64.img 5.4.7-100.fc30.x86_64 > (disable host-only initramfs, generate a generic one) > * now you should be able to boot using the 5.4 kernel > * dracut -H /boot/initramfs-5.4.7-100.fc30.x86_64.img 5.4.7-100.fc30.x86_64 > (we again have a host-only initramfs) > * reboot again > > This worked for me. the crypto/essiv and crypto/authenc module were missing > (and possibly others) Fedora 31 with luks header as following: LUKS header information for /dev/sda2 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 2056 MK bits: 256 .... dracut -N and dracut -H worked for me. Thank you very much.
dracut -N /boot/initramfs-5.4.10-200.fc31.x86_64.img 5.4.10-200.fc31.x86_64 Not working for me Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 2056 MK bits: 256 Maybe I am doing something wrong
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.