LUKS+BTRFS Grub Access Denied


I reinstalled my system (it was from an older iso, with LUKS+ext4 filesystem).
I choose btrfs this time. No swap partition or file, but the whole system encrypte with LUKS+btrfs using EFI boot loader.
The issue is, sometimes when the grub ask the crypt password its access denied me. The password is correct, i try over and and over again few times, then its eventually let me in.
This happens randomly. Sometimes when i reboot accept my password, other times not. Sometimes after a few retry its let me in sometimes i need to ctrl+alt+del and type my password 10-20 times until let me in.
Its a quite annoying issue, since im worried after every reboot that its let me in or not.
The issue was not happened with LUKS+ext4.

I dont see anything in dmesg or any log obviously.
The grub said: access denied or cryptodisk not found.

Any ideas?
Regards, Peter

1 Like

Do you use automatic partition or manually create partitions?
And always keep in mind that grub is only using default us keyboard layout so having a password with signs e.t.c. can be troublesome.

I used the automatic partitioning nothing manual. I use a simple password which is not confused with keyboard layouts. Plus when the grub access denied and drop my to the rescue shell i can type and see, so i double check and the typed password are correct.

I have the same setup (LUKS+ext4 automatic partitioning) and the only downside is that it takes almost 40 secs to boot after the password is typed, never had a problem where I had to type the password correctly several times so it let me in.

I had the same setup before (LUKS+ext4). It was worked for me too. Now i changed to LUKS+Btrfs (with subvolumes) and only this have the issue.

I may find the solution.

In /etc/default/grub changed this line:

GRUB_PRELOAD_MODULES="part_gpt part_msdos"

to this:

GRUB_PRELOAD_MODULES="part_gpt part_msdos cryptodisk luks"

rerun grub-install and grub-mkconfig seems to solved the issue.
I test more and will see.

Okay, SOLUTION is this:

In /etc/default/grub:
GRUB_PRELOAD_MODULES=“part_gpt part_msdos cryptodisk luks btrfs”

In /etc/mkinitcpio.conf

rerun grub-install and mkinitcpio.

Not a single issue since then after many reboot.

1 Like

do you have a link about this?
I was wondering if the reason is some change on BTRFS that is new, i will try to reproduce this here also to see the same happens.

Everything is mentioned here:
Mainly the btrfs preload module and the btrfs binary in the initcpio is needed. Otherwise in some cases casued issues. It seems not always loaded in time for some reason. But it seems only happens when its used with crypt. On some forum users recommended to using ext4 partion for the /boot, separated from the main root which is btrfs. The boot partition can be crypted but has to be ext4 not btrfs, then this issue not happened. There is some issues with luks+btrfs for sure.

done the same way you mentioned and at least on VM there is no issue with password… and any other… adding the options works too… but i will need to test on real hardware tomorrow
And thanks for the info…

If I remember correctly, this is how Fedora sets it up when you choose full disk encryption in the installer:

ESP vFat
/boot EXT4

Yes, i find the same on many forum. /boot should be a separated partition and with ext2/3/4. It seems crypted btrfs subvolumes not works well together with grub. I may reinstall my system like this: 512MB ESP vfat, 512MB ext4 /boot, the rest is btrfs.

1 Like

Quick update: No issues since i did the modifications in the default grub and mkinitcpio files.
It seems resolved the issue.

Also works fine with:
fat32 at /boot and /efi
luks + btrfs at /

welcome @lal
And if using /boot outside the BTRFS “pool” is a working solution i do not see why this should not be used per default… could also solve the issue for grub/os-probe to not find BTRFS installs on probing.

Its related to the btrfs. For some reason grub cant load the btrfs modules or not load properly if subvolumes used, or even without it. I think its safer to use regular ext partition for the /boot or not using subvolumes in it. Using fat under grub is not a good idea and cause problems, so thats not an option.
There is definetly some issues here with grub+btrfs. I dont know luks interfered with this or the issue is with btrfs only.

For me the ultimate solution would be a native ZFS encrypted install. But thats still needs a lot of handwork since its not default in any linux coz of licensing issues. :frowning:

@joekamprad, this is used per default. I mean, this is exactly what Calamares did when selected “use entire device” with encryption and btrfs.

@ArchanfelHUN, if you think fat for /boot is not a good idea, this is something that should be discussed with developers.

No. Entire device uses a separated EFI partition (usually 512MB) with vfat(32) filesystem. Thats for the EFI boot loader files only. This mounted in /boot/efi. /boot is always a linux filesystem by default. /boot can be on the same partition like the main root (/) parition, or in a separated partition (this is also usually 512MB) but if EFI used, only need the vfat partition. Grub cant be install in a fat32 partition during install. You can reformat the boot parition after the system install and copy the files back, but this is generally not recommended. No distro did this on default.

Making /boot a separate partition has pros and cons. One significant downside is that recovering a snapshot becomes significantly more complicated and booting off a snapshot becomes mostly impossible on Arch. This is because you are now storing your kernel outside of btrfs so your kernel and initramfs will not be restored as part of the snapshot. However, your kernel modules will get restored which will almost always result in machine that won’t boot.

It isn’t the end of the world, you just need to boot off an ISO, chroot into the installation and reinstall your kernels. That being said, since we have a lot of people that like the convenience of being able to boot off a snapshot using grub, I don’t think this should be the default

Fedora manages kernels quite a bit differently. Since they retain a number of older kernels(I think 3 by default), it is more likely that you would have the matching modules for one of the kernels installed.

I really don’t think that it is a good idea to make /boot fat32. You will lose the ability to manage permissions on each file and if anything tries to write case sensitive files to /boot it may result in breakage. I am little surprised that even works to be honest.

1 Like