Can't unlock luks since fedora 34 5.13.10

Hello,
First, i still have the 5.13.9 kernel, so i can still boot.
But since the 5.13.10, including 5.13.11 et 5.13.12 kernel release, i can’t unlock my luks drive during boot (just keep asking 3 time).
I made sure the keyboard layout didn’t change already.

This is my drive.
image
As you can see, /boot and /boot/efi aren’t encrypted, only the main partition.
I run BTRFS on top, and all of this was created a couple month ago only, directly from fedora 34 ISO.

Does anyone have the same issue ?
I haven’t look much into luks, so i don’t know what could go wrong.
there is this bug i found but it only talk about 5.13.0, and at the end mention btrfs.

Thank for any clue

I am running a similar Fedora 34 setup and have not experienced this problem. My install is also encrypted, uses Btrfs, and has a similar partition layout with an encrypted partition containing an LVM PV.

Sorry that doesn’t offer any help on diagnosis or solution, but it may be useful to know not everyone with a similar setup has the issue.

1 Like

Thank you :slight_smile: can you share your running kernel ?
uname -rv

I also am able to unlock my F34 with kernel 5.13.12 so this might be a rare issue, maybe specific to your setup.

This might not help at all in this case but might be worth a shot: there is a known issue where users of some keyboard layouts need to install the kbd-legacy package and then rebuild the initramfs.

Did you let Anaconda pick your partition scheme or did you customize it at all?

If no one here can help then you may want to try the Fedora users’ mailing list. In my experience there are some very knowledgeable people there.

Thank you for this link.
I am using a french layout, so not listed, but i should try to anyway.
The passphrase i used to encrypt my disk is way to hard to type blindly on a layout i don’t master, but i can always change it to something simple for testing.

i believe i customized it all in order to have that first 138Gb empty partition (slc cache for later).

Weirdly i cannot change the passphrase, even on the kernel that work
image

I am sure of the passphrase because it’s saved on keepass … but is it possible that something wrong is beeing done with the keymap during boot ? and that same thing happened on the livecd the first time i stetted it up ?

Kernel 5.13.12

1 Like

I managed after a lot of try to set up a second key

[root@f32 vlycop]# cryptsetup luksAddKey /dev/nvme0n1p4
Enter any existing passphrase: 
Enter new passphrase for key slot: 
Verify passphrase: 
[root@f32 vlycop]#

but … it doesn’t show up

[root@f32 vlycop]# sudo cryptsetup luksDump /dev/nvme0n1p4
LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	fd5cc08c-f008-4249-a408-adeaf09863ba
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Time cost:  13
	Memory:     1048576
	Threads:    4
	Salt:       9a 3b a2 3d 6e be 12 a0 4e ec 21 fc 7a 83 38 27 
	            a4 18 d1 a6 18 55 4b 3c a6 96 ee b8 3d 55 7f b5 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 371308
	Salt:       c8 7b 7a 91 35 d3 10 cf b1 87 dd 62 12 df 4b 12 
	            6b d5 ba 94 8d dc 09 e8 cd 9c f9 55 3c 93 3d bd 
	Digest:     cd 4f 41 7b f8 09 49 e5 ab 09 5f f3 1b d3 79 eb 
	            31 27 c9 fe 60 a3 14 9d 74 6d 60 05 12 dc de de 
[root@f32 vlycop]# 

Does cyptsetup fake a correct access when you spam it Oo

I wonder if your drive may be faulty. Seems like a good time to make sure backups are current.

You might check whether there is a firmware update for your NVME drive (yup, that’s a thing!).

Any chance you could switch to another drive, perhaps smaller & cheaper, to see whether the problem clears up? Of course, that would mean re-installing Fedora, so not trivial.

the pain in reinstalling is mostly dnf, mountpoint and symlink… Plus while i work from home i use this computer, so i won’t have time to set up everything until Monday (Saturday is over already here)

I don’t think this nvme is dead, or i would have way more issue than just luks (plus it’s a couple month old)

I don’t see any firmware on enmotus website.

i’ll wait for this to hang at some point, and see if the additional key fixed my issue :man_shrugging: