When installing EndeavourOS I selected BTRFS, a swap partition for hibernate, and also turned on the encryption feature. This created two LUKS partitions: one is the root partition and the other one is my swap partition.
Unfortunately this is extremely slow at startup.
Looking into this, I’ve read that the problem may be GRUB: apparently it has very slow code for decoding (no AVX extensions) and given that EndeavourOS encrypts the entire disk it relies on GRUB to do this.
Apparently if you create a separate /boot partition that is not encrypted, you can load the kernel quickly and then leave it to Linux to decrypt the root partition once it is loaded (which should be significantly faster).
Is this theory correct?
If yes, how do I resize my LUKS partition to create a separate /boot? I suppose I can boot into the live environment and use gparted to do the resize and create a separate partition, but once that is done how do I change my system to mount it into /boot? Do I copy the contents from my existing /boot folder, mount the new partition to /boot and then re-run grub? Is that sane?
Thank you for all your assistance. When I tried running mkinitcpio it complained the the kernel was missing:
[root@labrat boot]# mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
-> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-linux'
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
-> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-linux'
So I ended up copying the files from the original location into the newly mounted /boot and then ran mkinitcpio -P and that worked fine. I then ran grub-mkconfig -o /boot/grub/grub.cfg followed by grub-install /dev/sda and rebooted.
This had the desirable effect of having grub run without asking for a password. I got the menu immediately and selected the default entry: just as you predicted, the system would automatically unlock the disk and boot straight into the login screen. (I skipped removing the key slot as I did not know anything about luks).
I then took another snapshot before proceeding to the second stage: after a bit of reading and realizing that there are two key slots in use (with cryptsetup luksDump /dev/sda1) I assumed that one is for auto-unlock and the other will remain if I remove the auto-unlock one. I was not sure which of the two to remove, but ended up using: cryptsetup luksRemoveKey /dev/sda1 /crypto_keyfile.bin which removed key slot 1 (leaving key slot 0). I then repeated the mkinitcpio/grub-mkconfig/grub-install ceremony and now my system works as expected:
Grub shows up immediately on start
Selecting the kernel loads it immediately (and the initial ram disk)
At this point the kernel prompts for the root partition password
After entering the password, root unlocks perceptively faster
I think this setup should be the default really, when the installer is told to “use the entire disk” but I guess there may be security repercussions I am not aware of.
I also wonder now what it means for system stability: when you take a snapshot of the btrfs partition WITH the boot stuff inside it, that includes the kernel as well. Now if I take a snapshot and then want to revert back to recover, that will not include the kernel right? So if I run into an issue with a kernel update, I would have to manually downgrade the kernel?
Thanks again for helping me with the setup. Really interested on getting some perspective on the points I raised about btrfs snapshots and potential security issues.
I thought it was mkinitcpio that installed the kernel there but I guess it is actually the mkinitcpio alpm hook that does that. I should have had you reinstall the kernel instead of running mkinitcpio.
You probably want to do that in that opposite order as a general rule.
I don’t think it should be the default for two reasons:
There are some (minor) security concerns because now your initrams are unencrypted which would allow an attacker with physical access to your machine additional information about your system to help them attack it.
Even if the kernel isn’t the cause of the problems, the kernel in /boot and the kernel modules in /usr/lib will have mismatched versions. If you restore a snapshot with a different kernel you will need to do one of two things:
chroot in and reinstall a kernel
After you restore the snapshot, copy the needed kernel modules from the other snapshot. In order to do this, you need to use a non-destructive snapshot restore method.
Since you need to boot off of something else to restore the snapshot anyway, I would probably just chroot in reinstall the kernel.
I believe the slow boot issue is not a grub issue but an issue with the number of iterations LUKS is doing. The number of iterations is set for each key slot in the LUKS header. Per default LUKS is setting millions of iterations. That can take a long time to decrypt the first key slot and start booting.
cryptsetup luksDump /dev/device
This will tell you the number of iterations per key slot. If it is more than 1 mio iterations you probably found the root cause for the slow boot. You then might want to change key slot 1 and use less iterations.
In theory boot encryption helps protect from something called an evil maid attack, when someone with physical access could, for example, tamper with your kernel/initramfs in order to obtain your passphrase the next time your type it. But again, in theory they could still mess with the unencrypted portion of grub or even the firmware even when boot is encrypted.
Exactly! This is why I think that in combination with btrfs the default should be an encrypted boot.
After careful consideration, I decided to forego some boot speed in favor of proper snapshot ability. Still, this thread has been very educational for me, so thank you everyone for your help.
Thx for the answer! But I have to admit that I still don’t get it. What do you mean by mounted on /boot? How can it be mounted on /boot if there is no /boot?
(Sorry, still a noob at Linux But I try to learn!)
edit: I just DDG’d “Install linux without boot partition” and all results are about dual boot systems.
Is it the default when you use BTRFS? Because it wasn’t the default for me with Ext4. Anyway, that seems to be the easiest way to get full disk encryption.
edit: Do I maybe confuse this with the ESP partition? Was that the small partition that has to be FAT32?