LUKS partition on secondary drive not decrypting after reboot

Ask Fedora
, , , ,
1

Hi all. I recently installed a new 1TB SSD in my machine and I am having difficulty with having it unlock automatically at startup.

I used KDE Partition Manager to create a 512GiB partition for Fedora, while keeping the rest available for Windows. I then used GNOME Disks to unlock it at system startup.

It seems to not work after a system reboot though.

I ran some commands to possibly help diagnose the issue here.

Running lsblk after reboot before doing anything

lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
zram0                                         251:0    0     8G  0 disk  [SWAP]
nvme0n1                                       259:0    0 894.3G  0 disk  
nvme1n1                                       259:1    0 476.9G  0 disk  
├─nvme1n1p1                                   259:2    0   600M  0 part  /boot/efi
├─nvme1n1p2                                   259:3    0    16M  0 part  
├─nvme1n1p3                                   259:4    0   256G  0 part  
├─nvme1n1p4                                   259:5    0   756M  0 part  
├─nvme1n1p5                                   259:6    0     2G  0 part  /boot
└─nvme1n1p6                                   259:7    0 217.4G  0 part  
  └─luks-73e9bfbb-8e28-4ea3-a2ae-7072febe287f 252:0    0 217.4G  0 crypt /home
                                                                         /

nvme0n1 shows up but the 512GiB LUKS2 partition isn’t visible, and it shows up as unknown partition type in the partition manager.

I tried to delete the 512GiB partition and create an identical ext4 partition in its place but KDE Partition Manager gave an error, but somehow made both the NTFS and LUKS partition visible and restored it fully(?)

Running lsblk after attempting to recreate:

lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
zram0                                         251:0    0     8G  0 disk  [SWAP]
nvme0n1                                       259:0    0 894.3G  0 disk  
├─nvme0n1p1                                   259:8    0   512G  0 part  
└─nvme0n1p2                                   259:9    0 382.3G  0 part  
nvme1n1                                       259:1    0 476.9G  0 disk  
├─nvme1n1p1                                   259:2    0   600M  0 part  /boot/efi
├─nvme1n1p2                                   259:3    0    16M  0 part  
├─nvme1n1p3                                   259:4    0   256G  0 part  
├─nvme1n1p4                                   259:5    0   756M  0 part  
├─nvme1n1p5                                   259:6    0     2G  0 part  /boot
└─nvme1n1p6                                   259:7    0 217.4G  0 part  
  └─luks-73e9bfbb-8e28-4ea3-a2ae-7072febe287f 252:0    0 217.4G  0 crypt /home
                                                                         /

Then I unlocked the partition manually in the partiton manager and this is the final output of lsblk after doing that:

lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
zram0                                         251:0    0     8G  0 disk  [SWAP]
nvme0n1                                       259:0    0 894.3G  0 disk  
├─nvme0n1p1                                   259:8    0   512G  0 part  
│ └─luks-1c43c30c-4223-4b3e-865c-21552d88161f 252:1    0   512G  0 crypt 
└─nvme0n1p2                                   259:9    0 382.3G  0 part  
nvme1n1                                       259:1    0 476.9G  0 disk  
├─nvme1n1p1                                   259:2    0   600M  0 part  /boot/efi
├─nvme1n1p2                                   259:3    0    16M  0 part  
├─nvme1n1p3                                   259:4    0   256G  0 part  
├─nvme1n1p4                                   259:5    0   756M  0 part  
├─nvme1n1p5                                   259:6    0     2G  0 part  /boot
└─nvme1n1p6                                   259:7    0 217.4G  0 part  
  └─luks-73e9bfbb-8e28-4ea3-a2ae-7072febe287f 252:0    0 217.4G  0 crypt /home
                                                                         /

/etc/fstab contains this entry:

/dev/mapper/luks-1c43c30c-4223-4b3e-865c-21552d88161f /mnt/disk/ ext4 nofail 0 0

and /etc/luks-keys/luks-1c43c30c-4223-4b3e-865c-21552d88161f contains the passphrase for the encrypted partition.

Ideally, the output of lsblk would look like that final output after doing all those steps manually, but automatically after every reboot.

Sorry for the newb post on here :smiley:

2

Are both disks using the same LUKs method to unlock? TPM or passphase.

If you are using a passphrase that is it the same on both disks?

3

I believe so. I set up the first disk to unlock using a passhrase, and I did the same thing when creating the LUKS partition on the second drive. They both use the same passphrase.

Could it be that I selected LUKS2 while partitioning the second drive? I don’t remember there being an option for LUKS/LUKS2 when I followed the installer while installing Fedora on the first drive.

4

The default is LUK2 for all new LUK you set up.

You can test the passphrase using this command, from my notes:

# Testing passphrase on a LUK2 device

cryptsetup luksOpen --test-passphrase /dev/<your-device>

Does that command work with both devices?

1 Like
5

It gave no output after entering the passphrase for either /dev/nvme0n1p1 or /dev/nvme1n1p6.

6

I forget what successful and failed output looks like try inputing a bad passphrase nd see if it prints an error. Maybe it sets the exit code? You can print thw exit code with echo $?

7

Typing in a wrong password gave this error: No key available with this passphrase.

So the command works at least.

Echo $

Returns:

$

8

The error given in KDE Partition Manager is this, in case it helps:

Delete partition ‘/dev/nvme0n1p1’ (512.00 GiB, unknown) 
Job: Delete file system on ‘/dev/nvme0n1p1’ 
Command: wipefs --all /dev/nvme0n1p1 

Failed to erase filesystem signature on partition ‘/dev/nvme0n1p1’. 


Could not delete file system on ‘/dev/nvme0n1p1’. 

Delete file system on ‘/dev/nvme0n1p1’: Error
Delete partition ‘/dev/nvme0n1p1’ (512.00 GiB, unknown): Error
9

Try echo $? (including the question mark) right after the cryptsetup luksOpen --test-passphrase /dev/<your-device>. The device needs to have FSTYPE “crypto_LUKS” for the cryptsetup command to work. You can see the FSTYPE with lsblk -f.

10

So trying echo with the question mark after running cryptsetup luksOpen ––test-passprhase returns 0. I hope this helps

$ sudo cryptsetup luksOpen --test-passphrase /dev/nvme0n1p1
(sudo passphrase prompt)
Enter passphrase for /dev/nvme0n1p1:
$ echo $?
0
11

Here is the output of lsblk -f before unlocking but after trying to delete and recreate the partition:

$ lsblk -f
NAME             FSTYPE FSVER LABEL                UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zram0            swap   1     zram0                084d7577-5510-4e06-b0cb-442e5fdceba4                [SWAP]
nvme0n1                                                                                                
├─nvme0n1p1      crypto 2                          1c43c30c-4223-4b3e-865c-21552d88161f                
└─nvme0n1p2      BitLoc 2     COFFEA D: 22/03/2026 4a820b99-4d8f-4769-9be4-0c813074b7f0                
nvme1n1                                                                                                
├─nvme1n1p1      vfat   FAT32                      0455-14F7                             535.9M    11% /boot/efi
├─nvme1n1p2                                                                                            
├─nvme1n1p3      BitLoc 2     COFFEA C: 22/02/2026 15ee7369-326b-405c-87ba-fe396da19e00                
├─nvme1n1p4      ntfs                              64249681249655C0                                    
├─nvme1n1p5      ext4   1.0                        9c88e3b2-33a7-43b1-a40c-43e9c925f9ca    1.1G    36% /boot
└─nvme1n1p6      crypto 2                          73e9bfbb-8e28-4ea3-a2ae-7072febe287f                
  └─luks-73e9bfbb-8e28-4ea3-a2ae-7072febe287f
                 btrfs        fedora               08b63d48-1a20-4c26-a375-cb610ee6ec5a    172G    19% /home
                                                                                                       /

And here is the output of lsblk -f after unlocking the 512GiB LUKS partition:

$ lsblk -f
NAME             FSTYPE FSVER LABEL                UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zram0            swap   1     zram0                084d7577-5510-4e06-b0cb-442e5fdceba4                [SWAP]
nvme0n1                                                                                                
├─nvme0n1p1      crypto 2                          1c43c30c-4223-4b3e-865c-21552d88161f                
│ └─luks-1c43c30c-4223-4b3e-865c-21552d88161f
│                ext4   1.0                        30e7946f-7883-4bc2-a555-e2f9ff54f8bd                
└─nvme0n1p2      BitLoc 2     COFFEA D: 22/03/2026 4a820b99-4d8f-4769-9be4-0c813074b7f0                
nvme1n1                                                                                                
├─nvme1n1p1      vfat   FAT32                      0455-14F7                             535.9M    11% /boot/efi
├─nvme1n1p2                                                                                            
├─nvme1n1p3      BitLoc 2     COFFEA C: 22/02/2026 15ee7369-326b-405c-87ba-fe396da19e00                
├─nvme1n1p4      ntfs                              64249681249655C0                                    
├─nvme1n1p5      ext4   1.0                        9c88e3b2-33a7-43b1-a40c-43e9c925f9ca    1.1G    36% /boot
└─nvme1n1p6      crypto 2                          73e9bfbb-8e28-4ea3-a2ae-7072febe287f                
  └─luks-73e9bfbb-8e28-4ea3-a2ae-7072febe287f
                 btrfs        fedora               08b63d48-1a20-4c26-a375-cb610ee6ec5a    172G    19% /home
                                                                                                       /
12

It’s good that you checked /etc/fstab. Also have a look at /etc/crypttab (does it need a second line?), and also /proc/cmdline. In /proc/cmdline, is there a parameter rd.luks.uuid=73e9bfbb-8e28-4ea3-a2ae-7072febe287f? For the “auto unlocking” (or rather semi-auto, as you’re still typing a password), you may want to add another one like this, with the other “crypto”-uuid. Something like this: rd.luks.uuid=1c43c30c-4223-4b3e-865c-21552d88161f.

Some more advice: You cannot edit /proc/cmdline directly. To add the command line parameter, you have to know a bit of grub . I’m not a grub guy though, so I hope someone else can fill in some details here.

13

Do you mean an entry with the uuid of the second drive? Because I think it’s there, and I pasted the full contents of /etc/crypttab below.

/proc/cmdline contains rd.luks.uuid=73e9bfbb-8e28-4ea3-a2ae-7072febe287f, so it’s not that.

I tried adding rd.luks.uuid=1c43c30c-4223-4b3e-865c-21552d88161f but it seems to cause some very weird behaviour (boots into emergency mode, then after pressing Enter I am presented with the login screen).

/etc/crypttab contains

luks-73e9bfbb-8e28-4ea3-a2ae-7072febe287f UUID=73e9bfbb-8e28-4ea3-a2ae-7072febe287f none discard
luks-1c43c30c-4223-4b3e-865c-21552d88161f UUID=1c43c30c-4223-4b3e-865c-21552d88161f /etc/luks-keys/luks-1c43c30c-4223-4b3e-865c-21552d88161f nofail

and /etc/luks-keys/luks-1c43c30c-4223-4b3e-865c-21552d88161f contains the passphrase. Is this the correct way of unlocking the secondary drive after unlocking the main LUKS partition with Fedora on it / after logging into my user?

Is it possible or even recommended to only require unlocking the main LUKS partition, and then unlocking the second drive’s partition through a passphrsae stored in plain text inside /etc/luks-keys/luks-1c43c30c-4223-4b3e-865c-21552d88161f?

14

That’s what I do. During boot, I unlock the Btrfs partition on my main NVME that contains my / and /home subvolumes with a passphrase. Then, in my encrypted / partition, I have a random keyfile for another partition. (I prefer the random bytes in the keyfile over a passphrase in this case, since I never want to type the passphrase anyway.)

My /etc/crypttab has two entries, one for the encrypted / partition itself and another one for an older SATA SSD:

luks-CT4000MX500SSD1 UUID=[redacted] none discard

Then, in /etc/cryptsetup-keys.d/luks-CT4000MX500SSD1.key I have a keyfile for this partition. This is what you are trying to achieve, but instead of an arbitrary filename, there is already a defined location and a mechanism to lookup a file. See the description for the third field in man 5 crypttab:

[...] If the field is not present or is "none" or
      "-", a key file named after the volume to unlock (i.e. the first column of the line),
      suffixed with .key is automatically loaded from the /etc/cryptsetup-keys.d/ and
      /run/cryptsetup-keys.d/ directories, if present. [...]

You can create a keyfile with 2KB of random data with

$ sudo dd bs=512 count=4 if=/dev/random of=/etc/cryptsetup-keys.d/luks-CT4000MX500SSD1.key iflag=fullblock
$ sudo chmod 440 /etc/cryptsetup-keys.d/luks-CT4000MX500SSD1.key

… and then add it as a key to your device with something like

$ sudo cryptsetup luksAddKey --pbkdf pbkdf2 --hash sha512 --pbkdf-force-iterations 1000 /dev/sda1 /etc/cryptsetup-keys.d/luks-CT4000MX500SSD1.key

WARNING: I deliberately force a very simple key derivation function here, PBKDF2 with just 1000 iterations. That is fine for a keyfile that contains random bytes (or indeed anything that has a high entropy). Do not do this for a passphrase unless you understand the implications!
The benefit is that forcing this reduces the time to derive the key, which in turn lowers the time this takes during boot. (For the passphrase of the / partition, I use Argon2id with pretty high parameters to make brute force costly.)

Additionally, I suggest you also add a recovery key and store this somewhere safe, just in case the keyfile is lost. The easiest way to do this is using systemd-cryptenroll:

$ sudo systemd-cryptenroll --recovery-key /dev/sda1
15

I think as long as both crypto-partitions use the same passphrase, the unlocking of the “secondary” partition should happen automatically (meaning you still need to enter the passphrase at boot time, but only once). In particular, I think I remember the kernel parameter rd.luks.uuid being important. Did you succeed in configuring grub to add rd.luks.uuid=1c43c30c-4223-4b3e-865c-21552d88161f? Alternatively you can test this by simply adding it at boot time, by pressing “e” in the grub menu, but of course it’s a lot of typing.

16

Thank you for your solution. I more or less followed the steps you provided and now it succesfully unlocks the partition after a reboot. Many thanks for everyone’s help, you guys rock :heart:

1 Like