"Failed to open key file" at boot, after GRUB

Thanks for your reply. I don’t know how to decrypt the root partition however. Can this be done from the Live USB environment? If yes, do you have a resource explaining how to do this? I couldn’t find anything online.

sudo cryptsetup open /dev/path/to/device luksdevicename

Replace /dev/path/to/device with the actual path to your device. For example, /dev/sda2. You can use lsblk to find that if you don’t know it.

Replace luksdevicename with whatever you want to call it. It shouldn’t matter. You can even leave it luksdevicename if you want to.


Arch Wiki.


cryptsetup is the command you need to learn to manage luks / dm-crypt partition encryption.

Thanks for your help. I decrypted the root partition of the system I’m trying to fix, and found the following directories at its root:

@ @cache @home @log

… which is weird, as I would expect to find the usual linux directory strucure there (/usr /home ...), but this directory structure is present in /@/. I found the crypttab file in @/etc/crypttab which references the crypto_keyfile.bin file with path /crypto_keyfile.bin, NOT /@/crypto_keyfile.bin (where the file actually is).

So I guess I now need to figure out why my encrypted partition ended up so messed up. Does anybody know what’s going on here?

It isn’t messed up. That is what a btrfs root looks like. The root filesystem is in @.

To mount it so you can chroot, use sudo mount /dev/path/to/device /mnt -o subvol=@

these are your BTRFS subvols they got created from the scheme we set in calamares on autopartition with BTRFS:

A nice view will be produced with duf:
sudo pacman -S duf


Thank you, I didn’t know that. Using this mount command, the crypto_keyfile.bin file is present at the root of subvolume @ and the file path in /etc/crypttab is correct. As for the contents of crypto_keyfile.bin, I don’t know how to check if they are correct or not.

I see, any chance the system might be mounting the partition incorrectly as I did, thus prefixing the actual path of the crypto_keyfile.bin file with /@?

Not likely. Since this started when you installed video drivers I would recommend resolving that issue first. The key message you are seeing may have just been the last thing on the screen before the driver problem manifested. It may not even be an issue. If the initramfs can’t use your keyfile to unlock it should just ask you for a passphrase.

I can confirm this issue after a fresh install (endeavouros-2021.08.27-x86_64.iso) with btrfs and encryption.

BTRFS and encryption. Fresh install too.

“Failed to open keyfile”

However causes no problem and I can still continue as normal, so I have ignored for now.

I can also confirm this, but the boot process is really slow after entering the password.

That is normal. Grub is very slow at unlocking the luks volume. The kernel isn’t loaded yet and it does pure software decryption.

1 Like

@dalto thx for clarification

Ah “Failed to open keyfile” is normal then, so can safely ignore.

Many thanks for confirming.

It is likely harmless but I am not sure that is normal. I would look at the keys on your luks volume and make sure there isn’t an extra one. There should be only 2.

Yup only 2. Thanks, just going to leave as it is as not production mac

Yup. 2 key slots per luks volume. Not a big deal I’ll deal with it if it becomes a real problem. As they say… “Don’t fix unless its broken” :smiley:


Having two key slots is normal. One is your passphrase and the other is the keyfile.

1 Like

What i would do is if you can boot into a tty or chroot into the system otherwise is uninstall the nvidia drivers with sudo nvidia-installer-dkms -n

This will remove the nividia drivers and install the opensource nouveau drivers


Update, I did a reinstall using calamares. This time I used a swapfile. No keyfile error.

So it’s the swap partition.

I’m gonna just chill with the swapfile. But at least I’ve narrowed it down to a partition

I’m starting to think it may be the mounting of subvolumes that is the issue.

Ie it’s looking for a keyfile prior to the subvolumes being mounted and accessible… Or at least that’s what I’m going with.

Correct me this assumption is wrong, but if say the keyfile was deleted, wouldn’t the system hang on decryption post grub unlock?

It’s odd as I neevr had this problem using the copy and paste instructions. This was however my first go using the installer with btrfs