[LUKS] Keyfile could not be opened. Reverting to passphrase.

NoUsername · 2024-03-08 11:44:56

I have setup and created a keyfile for my luks drive and it simply will not open automatically at all.

Steps used:

Creating the keyfile:

1. dd if=/dev/urandom bs=1024 count=4 > PRIVATE-NAME

2. Moved Keyfile to USB.

3.sudo cryptsetup luksAddKey /dev/sdaX PRIVATE-NAME

4. Updated /etc/default/grub

4.1 GRUB_CMDLINE_LINUX="cryptdevice=UUID=ROOT-DEVICE-UUID:root cryptkey=UUID=USB-DEVICE-UUID:ext2:/PRIVATE-NAME zswap.enabled=0 rootfstype=btrfs"

5. Reboot

Immediately after rebooting the grub recognized that its looking for a usb with a UUID and keyfile. It Then outputs:

Keyfile could not be opened. Reverting to passphrase

Meaning that is located the usb device and file. It is just not able to open it for some reason.

Am I perhaps missing something ?

Last edited by NoUsername (2024-03-09 20:17:42)

spiffeeroo · 2024-03-09 14:59:31

According to the wiki page, the path needs to be the absolute path of the keyfile within the device. Have you added a "/" before PRIVATE-NAME?

cryptkey=UUID=USB-DEVICE-UUID:ext2:/PRIVATE-NAME

Last edited by spiffeeroo (2024-03-09 15:00:39)

NoUsername · 2024-03-09 20:19:11

spiffeeroo wrote:

According to the wiki page, the path needs to be the absolute path of the keyfile within the device. Have you added a "/" before PRIVATE-NAME?
cryptkey=UUID=USB-DEVICE-UUID:ext2:/PRIVATE-NAME

Yes, I have tried both ways, with and without the full path. They both return the same error.

Currently i have it set to the full path.

I have editted the post to reflect the full path. That was a typo

Last edited by NoUsername (2024-03-09 20:20:53)

NoUsername · 2024-03-11 17:41:34

bump

spiffeeroo · 2024-03-13 01:00:58

https://bbs.archlinux.org/viewtopic.php … 1#p2156831

Current mkinitcpio has problems parsing the : character in kernel parameter. Soon to be released mkinitcpio 38.1 should fix it.

nl6720 · 2024-03-13 08:09:06

spiffeeroo wrote:

Current mkinitcpio has problems parsing the : character in kernel parameter. Soon to be released mkinitcpio 38.1 should fix it.

Shouldn't really be the issue here since UUIDs don't contain a ":".

My guess would be that the initramfs lacks the ext2 kernel module.

NoUsername · 2024-03-18 13:42:06

spiffeeroo wrote:

https://bbs.archlinux.org/viewtopic.php … 1#p2156831
Current mkinitcpio has problems parsing the : character in kernel parameter. Soon to be released mkinitcpio 38.1 should fix it.

Awesome, thought I might have been the only one with this issue.

Sadly i just checked and i am already at mkinitpcio38.1-1.

So this issue might still be a problem. Im going to test the vfat format and see if that works

Last edited by NoUsername (2024-03-18 13:46:33)

NoUsername · 2024-03-18 13:43:33

nl6720 wrote:

spiffeeroo wrote:
Current mkinitcpio has problems parsing the : character in kernel parameter. Soon to be released mkinitcpio 38.1 should fix it.
Shouldn't really be the issue here since UUIDs don't contain a ":".
My guess would be that the initramfs lacks the ext2 kernel module.

Unfortunately I wish this was the case. I had the drive first set to ext4 and thats when the kernel detected an unsupported ext4 module. When switch to ext2 the drive got picked up but unable to read the keyfile. So ext2 is supported.

frostschutz · 2024-03-18 14:01:43

In terms of kernel modules, there is no distinct module for ext2 (in theory the kernel has it but it's disabled in favor of ext4, which handles all flavors of ext filesystem). So there should not be a case where ext2 is supported but ext4 isn't - you need the ext4 module in any case.

# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=m
CONFIG_EXT4_USE_FOR_EXT2=y

NoUsername · 2024-03-18 14:20:52

frostschutz wrote:

In terms of kernel modules, there is no distinct module for ext2 (in theory the kernel has it but it's disabled in favor of ext4, which handles all flavors of ext filesystem). So there should not be a case where ext2 is supported but ext4 isn't - you need the ext4 module in any case.
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=m
CONFIG_EXT4_USE_FOR_EXT2=y

Interesting. ext4 did not seem to work though. Including fat32 (vfat)

Im just going to rebuild from scratch and see if theres a difference. If theres still an error. it could then mean the machine arch is on probably has something unsupported.

Last edited by NoUsername (2024-03-18 14:22:14)

NoUsername · 2024-03-19 00:20:36

I did a clean install and found a new error. i cannot add the luks key file.

```
cryptsetup luksAddKey /dev/sdX keyfile-name
```

Responds with error: "Device /dev/sdX is not a valid luks device"

I am going to have to open another post for this error.

Its the same method except i tried both ext4 and ext2 and got the same error.

Arch Linux

#1 2024-03-08 11:44:56

[LUKS] Keyfile could not be opened. Reverting to passphrase.

#2 2024-03-09 14:59:31

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#3 2024-03-09 20:19:11

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#4 2024-03-11 17:41:34

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#5 2024-03-13 01:00:58

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#6 2024-03-13 08:09:06

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#7 2024-03-18 13:42:06

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#8 2024-03-18 13:43:33

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#9 2024-03-18 14:01:43

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#10 2024-03-18 14:20:52

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

#11 2024-03-19 00:20:36

Re: [LUKS] Keyfile could not be opened. Reverting to passphrase.

Board footer