Bug 1783257 - 5.4: cannot boot, LUKS unlocking fails
Summary: 5.4: cannot boot, LUKS unlocking fails
Keywords:
Status: NEW
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-01-20 16:30 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
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


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