Suddenly can't unlock LUKS drive

Ask Fedora
, ,
1

Hi all,

I’m a new Linux/Fedora KDE user, been using it for the past couple of months.

Today, after I tried logging into my Fedora 37 system, all of a sudden it will not accept the passcode to unlock the LUKS-secured drive where my Linux installation and files are located. I ran dnf-update yesterday so I’m not sure if that affected anything. Otherwise, nothing else has changed.

What I have tried to fix it
I have spent a couple of hours trying to fix this and found some odd things.

Firstly I booted Fedora off a USB to try to access the drive. I tried unlocking it with the passcode but no luck.

Then I rebooted again into the same USB system. I tried a couple more times to unlock the drive and they all failed. Then on about the 4th or 5th try, all of a sudden the passcode worked and I was into the drive. I had a look and all of my files were still there and the drive seemed fine.

All good, right? Well not after I rebooted again. Now it’s back to what it was and I can’t unlock the drive.

After a lot of forum searching, one of the solutions I have tried is running testdisk and it has found no errors in the partitions or drive. I can see the three partitions created in KDE Partition Manager.

I am 110% sure that this is the correct passphrase. I checked my keyboard layout and it has not changed.

There has been no hardware change.

System specs and relevant info

  • 2TB WD Black SN770 (Linux)
  • 1TB SPCC (Windows 10)
  • 2TB WD Blue HDD (large file storage)
  • Prime B650-Plus Motherboard
  • Dual boot Windows 10 and Fedora 37 KDE on separate SSDs (as above)

As I mentioned I’m new to Linux and not experienced with this OS so any help or points would be greatly appreciated.

2

As a test, can you boot a Fedora 37 live image and see if you can decrypt and mount the drive from there?

(if you are not familiar with sudo cryptsetup luksOpen <device>, you can use Gnome Disks to unlock the volume)

3

have you tried booting an older kernel? Maybe for the most recent one, initramfs did not get built correctly.

4

Thanks for the quick reply.

I booted a Fedora 37 live image and tested that out. I got the error No key available with this passphrase.

Although, again strangely, after a couple of attempts trying to unlock it just through Dolphin, it successfully unlocked it just once. All of the other 10-15 subsequent times that I’ve tried have all failed, including trying to add additional passkeys via sudo cryptsetup luksAddKey.

I should have mentioned that I tried booting into all older kernels, including the recovery one, all with the same result.

Now that I’m in I am making another backup of all of my files on the drive. But I would still like to understand what has happened here.

1 Like
5

Take a look at this thread:
After upgrading I cannot unlock and boot from my luks encrypted disk
This may not be a Fedora specific issue.

6

Some follow up for another thing that I have now tried.

I have run cryptsetup isLuks on the relevant partition and it shows up as yes. I have also run cryptsetup luksDump and it shows what looks like a standard header (from what I can tell).

1 Like
7

Thanks I’ll give that a go now

8

Thanks for that information. I’ve had a read through and gone down some rabbit holes, here’s what I found.

I ran sudo btrfs rescue chunk-recover /dev/nvme0n1 which came up with:
read super block error recover prepare error

I then ran sudo btrfsck /dev/nvme0n1 which came up with: Opening filesystem to check... No valid Btrfs found on /dev/nvme0n1

Does this help at all? Is the btrfs broken in some way?

9

If I understand correctly, /dev/nvme0n1 should be your physical drive.
Then something like /dev/nvme0n1p3 should be your LUKS partition.
And Btrfs should be inside the decrypted LUKS volume.

So, it is confusing why you run filesystem check on the physical drive.
Be aware, that careless use of this kind of command is dangerous.
In the worst case, it can irreversibly corrupt your LUKS volume.

10

Sorry I got them mixed up, as I mentioned I’m new to Linux and getting my head around this.

I just ran both checks on /dev/nvme0n1p3 with the same results

I should also mention that in KDE Partition Manager /dev/nvme01n1p3 is showing up as ‘btrfs [Encrypted]’

11

This is still wrong and dangerous.
You can only run filesystem check on a decrypted LUKS volume.
It should be /dev/mapper/DECRYPTED_VOLUME_NAME.
Never run filesystem check on an encrypted LUKS volume.

12

If it’s dangerous or incorrect, what should I be doing instead?

13 
sudo cryptsetup isLuks /dev/nvme0n1p3 && echo yes || echo no
sudo cryptsetup luksOpen /dev/nvme0n1p3 fedora --debug
14

Thanks, here are the results:

sudo cryptsetup isLuks /dev/nvme0n1p3 && echo yes || echo no
yes
sudo cryptsetup luksOpen /dev/nvme0n1p3 fedora --debug
# cryptsetup 2.5.0 processing "cryptsetup luksOpen /dev/nvme0n1p3 fedora --debug"
# Verifying parameters for command open.
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/nvme0n1p3.
# Trying to open and read device /dev/nvme0n1p3 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/nvme0n1p3.
# Crypto backend (OpenSSL 3.0.5 5 Jul 2022 [default][legacy]) initialized in cryptsetup library version 2.5.0.
# Detected kernel Linux 6.0.7-301.fc37.x86_64 x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device /dev/nvme0n1p3.
# Opening lock resource file /run/cryptsetup/L_259:3
# Verifying lock handle for /dev/nvme0n1p3.
# Device /dev/nvme0n1p3 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/nvme0n1p3
# Verifying locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:cf33b5bbe635bca2bc486c874e581ed97619481bd95b928e3175084a87739d67 (on-disk)
# Checksum:cf33b5bbe635bca2bc486c874e581ed97619481bd95b928e3175084a87739d67 (in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device /dev/nvme0n1p3
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:bad578e38f4ff378503800fa04a3e112f13e7cf67478d9b88c6ea09a1f6ad868 (on-disk)
# Checksum:bad578e38f4ff378503800fa04a3e112f13e7cf67478d9b88c6ea09a1f6ad868 (in-memory)
# Device size 1998694907904, offset 16777216.
# Device /dev/nvme0n1p3 READ lock released.
# PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# Activating volume fedora using token (any type) -1.
# dm version   [ opencount flush ]   [16384] (*1)
# dm versions   [ opencount flush ]   [16384] (*1)
# Detected dm-ioctl version 4.47.0.
# Detected dm-crypt version 1.24.0.
# Detected dm-zero version 1.1.0.
# Device-mapper backend running with UDEV support enabled.
# dm status fedora  [ opencount noflush ]   [16384] (*1)
No usable token is available.
# Interactive passphrase entry requested.
Enter passphrase for /dev/nvme0n1p3: 
# Activating volume fedora [keyslot -1] using passphrase.
# dm versions   [ opencount flush ]   [16384] (*1)
# dm status fedora  [ opencount noflush ]   [16384] (*1)
# Keyslot 0 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Running keyslot key derivation.
# Reading keyslot area [0x8000].
# Acquiring read lock for device /dev/nvme0n1p3.
# Opening lock resource file /run/cryptsetup/L_259:3
# Verifying lock handle for /dev/nvme0n1p3.
# Device /dev/nvme0n1p3 READ lock taken.
# Reusing open ro fd on device /dev/nvme0n1p3
# Device /dev/nvme0n1p3 READ lock released.
# Verifying key from keyslot 0, digest 0.
# Digest 0 (pbkdf2) verify failed with -1.
No key available with this passphrase.
# Interactive passphrase entry requested.
15

Another update on this.

Once again I was randomly able to log in to the drive when logging into Fedora 37 as usual. But when I go to run cryptsetup luksAddKey or execute other commands requiring a passcode, the same errors as before come up.

It don’t understand why my passcode only works ~sometimes~ If it never worked, I’d assume something has corrupted or whatever, but this is making no sense whatsoever.

EDIT:

Today I have also run:

sudo smartctl -H /dev/nvme0n1p3
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.2.7-200.fc37.x86_64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

I also noticed that an update for Upgrade to new version 2:1.34-6.fc37 Release notes: Fix for CVE-2022-48303 has not been installed. When I try to install it I get this error: <html>Internal error:<br/><br/>Error running transaction: package tar-2:1.34-6.fc37.x86_64 is already installed</html>

Not sure if any of this is relevant or not just putting it here just in case.

16

I would try changing the passphrase just to see what happens, and at the same time use characters not present in current passphrase just to rule out the physical keyboard.

17

That is on the partition. It should be on the device
sudo smartctl -H /dev/nvme0n1 would be the command for that device.

18

It looks more like a hardware failure, probably the keyboard or the disk.
Keyboard related issues can be isolated by reading the passphrase from a file.
Disk related issues require to analyze SMART diagnostics and run the relevant tests.

19

Thank you all very much for your help.

Turns out that after most of a day deconstructing my entire PC and removing, isolating and troubleshooting each individual component, I had a faulty RAM stick. As soon as I removed this, everything started working fine and I could unlock the drive with no issues.

I have no idea how faulty RAM affects whether or not I can unlock a SSD but there you go.

5 Likes