My LUKS passphrase suddenly isn't working to boot? (Atomic Sway 41)

Ask Fedora
1

Hi!

I’m using Fedora Sway Atomic 41. I don’t know what happened, but my LUKS password isn’t working to boot. It was working fine yesterday, and then this afternoon I couldn’t boot my laptop.

So, I get into GRUB2, and then there’s four options, right? I select the first one (ostree:0), and then it asks me for my passphrase. I enter it once (it doesn’t work); I enter it again (still doesn’t work); and then I enter it a third time and then it goes into a bit of a long loading screen, and then it outputs:

"Warning: /dev/disk/by-uuid/[long uuid] does not exist.

Generating "/run/initramfs/rdsosreport.txt

Entering emergency mode. Exit the shell to continue.
Type “journalctl” to view system logs.
You might want to save “/run/initramfs/rdsosreport.txt” to a USB stick or /boot
after mounting them and attach it to a bug report.

Press Enter for maintenance
(or press Control-D to continue):"

This happens also for the previous version too (ostree:1).

If I select the third option, which I assume is Safe Mode for ostree:0 (even though it doesn’t say that), it says:

"error: …/…/grub-core/script/function.c:119: can’t find command ‘linux16’.
"error: …/…/grub-core/script/function.c:119: can’t find command ‘initrd16’.

Press any key to continue…"

I booted from a Live USB, and looked around (just trying stuff, I clearly don’t know what I’m doing). I also tried to open my encrypted drive from the live USB, but my passphrase doesn’t work either [I’m pretty sure I’m typing it correctly.]

May you all please help me? Thank you so much!

3

Are you sure you are using the correct keyboard layout for you? The one you select in the installer will not be applied to Plymouth (LUKS passphrase screen). If you didn’t change anything it will use the qwerty layout by default.

See:

4

Yes, I am very, very sure I am using the correct layout. It has been working for months. And, when I was using the live USB, it was definitely the qwerty layout and I even displayed the passphrase to check it was inputting the correct letters.

5

When booting into a live session, can you open the encrypted device (with cryptsetup open, see man page for usage), and then mount the mapping?

/boot and system partitions are on the same device? Please share lsblk -f.

6

No, I am unable to open the encrypted device during a live session.

Yes, my /boot and system partitions are on the same device. Here is my lsblk-f!

2024-12-02T14_22_48,837221214-05_00
2024-12-02T14_22_48,837221214-05_00871×288 23.7 KB

Thank you all so much for your help!

7

What is the output of sudo cryptsetup open /dev/nvme0n1p3 myroot, and that of sudo cryptsetup luksDump /dev/nvme0n1p3?

It would be better if you could post your outputs as preformatted text (using the </> button), instead of screenshots, for readability and search purposes.

You could also have a look at your disk’s health. The Disks app, available in the live session, has a SMART Data&Self-Tests option in the menu.

8

sudo cryptsetup open /dev/nvme0n1p3 myroot asks for the passphrase, and when I enter it, the error is: “No key available with this passphrase”

sudo cryptsetup luksDump /dev/nvme0n1p3

LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	5c24184f-ba3a-49e9-b744-bdf8df005fcb
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:      argon2id
	Time cost:  5
	Memory:     1048576
	Threads:    4
	Salt:       db 14 a6 b2 33 96 2c c5 10 04 35 e0 90 87 06 93 
	           a3 83 3e c8 05 de ef 92 37 95 0e d7 3b 07 b6 67 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 279173
	Salt:       1a 1b ac c5 bd 50 63 54 af b5 7c 14 c8 6e 21 bc 
	           81 39 39 91 a5 f6 63 3d e7 44 8d 62 42 bb 80 08 
	Digest:     9b db 62 28 99 58 6b 16 f7 64 fb 87 ef 64 39 d9 
	           e2 2d 51 dc df df 79 2a 95 43 d6 98 cf 8e 9c 2e

As for the SMART Data & Self-Tests option in the Disks app, lt’s greyed out.

Thank you so much for your time and patience with me!

9

Given that cryptsetup luksDump command is showing the LUKS header information, at this point it only looks as if the entered passphrase is not correct.

I usually consider a good practice to create a second passphrase and/or a key file. That would have showed us if it is a forgotten password issue or something else.

The one thing that comes to my mind now is maybe some key(s) on the keyboard that don’t work correctly (e.g. need harder press etc). You could try cryptsetup open-ing again by entering the password in a separate text file, just to make sure it is correct, than copy-pasting it into the terminal, when the passkey is required.