Bug 1783257 - 5.4: cannot boot, LUKS unlocking fails
Summary: 5.4: cannot boot, LUKS unlocking fails
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-13 13:04 UTC by Tomasz Torcz
Modified: 2020-11-24 15:46 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-24 15:46:59 UTC
Type: Bug


Attachments (Terms of Use)
boot failure (494.74 KB, image/jpeg)
2019-12-13 13:04 UTC, Tomasz Torcz
no flags Details
boot failure photo (184.09 KB, image/jpeg)
2020-01-04 15:54 UTC, Tomasz Torcz
no flags Details

Description Tomasz Torcz 2019-12-13 13:04:09 UTC
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.

Comment 1 Tomasz Torcz 2019-12-20 16:44:30 UTC
The problem persist with kernel-5.4.5-300.fc31.x86_64kernel-5.4.5-300.fc31.x86_64

Comment 2 Tomasz Torcz 2020-01-02 18:06:52 UTC
The same with 5.4.7-200.fc31.x86_64

Comment 3 Tomasz Torcz 2020-01-04 15:54:14 UTC
Created attachment 1649689 [details]
boot failure photo

Comment 4 David Santamaría Rogado 2020-01-05 14:01:22 UTC
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.

Comment 5 Tomasz Torcz 2020-01-05 14:10:36 UTC
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

Comment 6 David Santamaría Rogado 2020-01-06 12:30:52 UTC
The only noticeable difference is the cypher/hash. I have aes xts-plain64 sha512.

Comment 7 David Santamaría Rogado 2020-01-06 12:36:21 UTC
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.

Comment 8 Rob 2020-01-07 18:02:32 UTC
Same issue with me after upgrading today to kernel 5.4.7-200.fc31.x86_64 cannot boot from this kernel

Comment 9 kkakini 2020-01-09 10:19:19 UTC
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)

Comment 10 Tomasz Torcz 2020-01-09 17:08:20 UTC
I can confirm that. Bulding NON-hostonly initramfs results in successfull boot.
I guess that's a dracut bug.

Comment 11 kkakini 2020-01-10 10:48:29 UTC
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...

Comment 12 Rob 2020-01-10 12:03:32 UTC
What about kernel  x86_64 5.4.8-200.fc31 ¿has anyone tested if the luks issue is still present?

Comment 13 Dieter Stolte 2020-01-18 22:24:49 UTC
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.

Comment 14 Daniel 2020-01-19 04:09:46 UTC
(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.

Comment 15 Rob 2020-01-20 16:30:45 UTC
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

Comment 16 Ben Cotton 2020-11-03 15:59:34 UTC
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.

Comment 17 Ben Cotton 2020-11-24 15:46:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.