Bug 1783257
Summary: | 5.4: cannot boot, LUKS unlocking fails | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tomasz Torcz <tomek> | ||||||
Component: | dracut | Assignee: | dracut-maint-list | ||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 31 | CC: | airlied, bskeggs, danielsun3164, dracut-maint-list, dstolte, hdegoede, howl.nsp, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, kkakini, linville, masami256, mchehab, mike, mjg59, obrer, steved, zbyszek | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2020-11-24 15:46:59 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Tomasz Torcz
2019-12-13 13:04:09 UTC
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. |