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.
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.
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: https://wiki.archlinux.org/title/btrfs
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…
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.
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.
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.
