[SOLVED] EFI Boot with LUKS encrypted btrfs root using grub2

So I've been giving myself a heck of a headache here: I am pretty well versed in installing and configuring arch, but I am having serious trouble getting UEFI to work when I have a LUKS encrypted root, formatted btrfs, using a subvolume for root (with other subvolumes for /home, /var, and /usr).

At first I had /dev/sda1 mounted at /boot/efi, and the system would boot into grub but was unable to load the kernel, saying that it could not find the root device (which should have been my cryptouuid device /dev/sda2, which grub.cfg seemed to point to correctly)

So, I moved the mountpoint of /dev/sda1 to /boot, moved the files accordingly, reinstalled grub... and now when I select arch_grub from the boot options on my laptop, it just goes right back to the boot options...

I am pretty sure that btrfs in LUKS is set up correctly, and I'm pretty sure my grub.cfg is being generated correctly, and I'm pretty sure my fstab is correct, so I'm lost as to what to check next. Especially now that /boot has the unencrypted kernel and initramfs...

lists a different uuid for __active... but the uuid fstab and grub are referring to is my btrfs-root, which I believe is correct (rather than specifying the UUID of __active). Does anyone know if that is true?

Re: [SOLVED] EFI Boot with LUKS encrypted btrfs root using grub2

jakh wrote:

changing the boot flag for /dev/sda1 did not matter (and shouldn't for EFI, it does not rely on boot flags)

That's not entirely true, at least not when referring to what parted calls a "boot flag." When using parted on GPT disks, the "boot flag" actually refers to a partition type code of C12A7328-F81F-11D2-BA4B-00A0C93EC93B -- in other words, the EFI System Partition (ESP). When you remove that flag from a FAT partition, its type code will be changed to EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -- a Microsoft Basic Data partition. The EFI spec is pretty clear that boot loaders are supposed to appear on ESPs, not on other partition types. That said, most EFI implementations will boot from other partitions, so long as they contain FAT filesystems. I can't promise that this will be true of all EFIs, though, so you'd do well to set the boot flag (using parted or GParted) or change the type code to EF00 (using gdisk; "EF00" is gdisk's stand-in for the much more awkward C12A7328-F81F-11D2-BA4B-00A0C93EC93B) so as to ensure your partitions are set up properly. If you don't, you might make another change that should fix things, but still run into a boot failure because of the improper partition type code, which would make you think that your correct change was ineffective.

So, I moved the mountpoint of /dev/sda1 to /boot, moved the files accordingly, reinstalled grub....../boot/efi/EFI/grub/grub.cfg

If the /boot/efi/EFI/grub/ path is the path after you moved /dev/sda1's mount point to /boot, then it's probably incorrect, and that could be a symptom of the problem. The EFI doesn't know a thing about Linux mount points; it just knows the partition's GUID and a file path within that filesystem. Thus, if you had GRUB installed at /boot/efi/EFI/grub/grub.efi, with /boot/efi being the ESP, and if you then changed the ESP's mount point to /boot, GRUB should now be at /boot/EFI/grub/grub.efi. If you've adjusted the paths so that GRUB remains at /boot/efi/EFI/grub/grub.efi in Linux, then from the ESP's perspective it will have moved -- from EFI\grub\grub.efi to efi\EFI\grub\grub.efi. This would render the NVRAM entry pointing to GRUB inaccurate and useless, and when the EFI tried to run GRUB, it would fail and you'd end up back at an EFI menu.

I can't be sure that this is what's happening, though. For more diagnostic information, please boot a Linux emergency system in EFI mode, mount /dev/sda1 to /mnt (or some other convenient location), and post the output of the following two commands, typed as root:

efibootmgr -v
ls -l `find /mnt -iname "*.efi"`

If you mount the ESP somewhere other than /mnt, adjust the second command appropriately.

Re: [SOLVED] EFI Boot with LUKS encrypted btrfs root using grub2

So, I moved the mountpoint of /dev/sda1 to /boot, moved the files accordingly, reinstalled grub....../boot/efi/EFI/grub/grub.cfg

If the /boot/efi/EFI/grub/ path is the path after you moved /dev/sda1's mount point to /boot, then it's probably incorrect, and that could be a symptom of the problem. The EFI doesn't know a thing about Linux mount points; it just knows the partition's GUID and a file path within that filesystem. Thus, if you had GRUB installed at /boot/efi/EFI/grub/grub.efi, with /boot/efi being the ESP, and if you then changed the ESP's mount point to /boot, GRUB should now be at /boot/EFI/grub/grub.efi. If you've adjusted the paths so that GRUB remains at /boot/efi/EFI/grub/grub.efi in Linux, then from the ESP's perspective it will have moved -- from EFI\grub\grub.efi to efi\EFI\grub\grub.efi. This would render the NVRAM entry pointing to GRUB inaccurate and useless, and when the EFI tried to run GRUB, it would fail and you'd end up back at an EFI menu.

Okay, this makes sense (and my brain is telling me I knew it or something...).

Reinstalled grub, moved the grub.cfg (didn't need to remake it, no paths it referred to had changed), rebooted and restarted into grub, asked for my passphrase to decrypt /, and I am now looking at a fresh root terminal.