GRUB2 EFI Support In Fedora 31 Likely To Include New Security Modules

[starshipeleven]

You could keep the kernel in /boot, there's really no purpose to encrypting /boot anyway.

I don't see much purpose in a separate /boot when you have the EFI partition.

I don't think it supports them at the moment, but there's no reason why systemd-boot can't use EFI FS drivers (there's dozens).

It's a design choice afaik. They envisioned using it with kernels in the EFI partition because you must have that anyway, so why not using it.

[skeevy420]

Grub only supports LUKS headers (no LUKS2 yet), but AFAIK systemd-boot doesn't support either.
If so, how is systemd-boot supposed to boot from a LUKS-encrypted boot partition?
It if really supports LUKS2 and native ZFS encryption I will switch for sure.
ZFS support looks especially unlikely to me, since encryption is only supported in the highly-experimental 0.8.x branch.

With Grub, there's a patch in a ZoL issue to hack it so pools can be created in a manner where /boot is unencrypted, the rest of the disk is encrypted, and you can unlock the rest via kernel command line, a key file, passphrase, etc and systemd-boot is the same only /boot can be encrypted since the kernel and ramdisk are in the stub. Grub will complain if that patch isn't used. I've used the 0.8.x branch of ZFS from day one without issue.

I just assumed on the systemd-boot/LUKS part...I don't really keep up with it outside of Grub and LUKS2.

[Britoid]

By keeping the kernel in the EFI partition I guess. You want to be using Secure Boot in any case if you are serious about that.

Only way it could boot directly is if someone wrote a EFI driver for LUKS encryption (or ZFS). Afaik the only project providing EFI drivers (besides the ones shipped with rEFInd project) is https://efi.akeo.ie/ which is using GRUB's EFI filesystem support modules.

You could keep the kernel in /boot, there's really no purpose to encrypting /boot anyway.

I don't think it supports them at the moment, but there's no reason why systemd-boot can't use EFI FS drivers (there's dozens).

[starshipeleven]

If so, how is systemd-boot supposed to boot from a LUKS-encrypted boot partition?

By keeping the kernel in the EFI partition I guess. You want to be using Secure Boot in any case if you are serious about that.

Only way it could boot directly is if someone wrote a EFI driver for LUKS encryption (or ZFS). Afaik the only project providing EFI drivers (besides the ones shipped with rEFInd project) is https://efi.akeo.ie/ which is using GRUB's EFI filesystem support modules.

[starshipeleven]

Well if you boot multiple OS, then Grub is invaluable. if it's just the one, then yes alternatives like systemd-boot and refind are a good idea.

Edit: GRUB is also pretty useful if your system gets screwed up, and you need to change command line parameters to atleast boot to the command line and fix it.

Sorry but I have to stop you right there good sir.
rEFInd is VERY good at dealing with multiboot environments as it scans all kernels/OS/bootloaders on boot so it will autodetect everything without any mainteneance on your side.
It also allows you to edit the command line parameters (actually allows you to set up multiple sets of them in a config textfile beforehand so you can just choose another profile if you don't want to type).

It also has menu for EFI tools like memtest and EFI shell (that you need to provide and drop in the appropriate folder), and can reboot to UEFI firmware (as long as the UEFI allows this at all).

It also detects automatically the secure boot management tool things a distro installs in the EFI partition so you can also invoke them on boot to do key management.

GRUB can do all this only with extensive configuration that has to be updated manually on any kernel/OS/bootloader change.


What GRUB can do which rEFInd can't do is actually access LVM or RAID (* with metadata=0.9 it can access it but your array size is now limited to 2TB) or encrypted partitions to boot your kernel.

[darkbasic]

There is one major benefit that systemd-boot has over Grub -- booting from fully encrypted, no, completely full featured ZFS volumes. You can't do that from Grub...only from systemd-boot since Grub has to be installed to a legacy and limited dataset supporting minimal features. I think there's a similar situation with LUKS/LUKS2 with Grub and systemd-boot (Grub only supports LUKS).

Grub only supports LUKS headers (no LUKS2 yet), but AFAIK systemd-boot doesn't support either.
If so, how is systemd-boot supposed to boot from a LUKS-encrypted boot partition?
It if really supports LUKS2 and native ZFS encryption I will switch for sure.
ZFS support looks especially unlikely to me, since encryption is only supported in the highly-experimental 0.8.x branch.

[skeevy420]

None, while grub allows you to even boot from an encrypted boot partition.

There is one major benefit that systemd-boot has over Grub -- booting from fully encrypted, no, completely full featured ZFS volumes. You can't do that from Grub...only from systemd-boot since Grub has to be installed to a legacy and limited dataset supporting minimal features. I think there's a similar situation with LUKS/LUKS2 with Grub and systemd-boot (Grub only supports LUKS).

[darkbasic]

What is the benefit of systemd-boot over GRUB?

None, while grub allows you to even boot from an encrypted boot partition.

[Britoid]

Well if you boot multiple OS, then Grub is invaluable. if it's just the one, then yes alternatives like systemd-boot and refind are a good idea.

Edit: GRUB is also pretty useful if your system gets screwed up, and you need to change command line parameters to atleast boot to the command line and fix it.

Which is why you have a Boot Manager like systemd-boot/refind.

[SpyroRyder]

Well if you boot multiple OS, then Grub is invaluable. if it's just the one, then yes alternatives like systemd-boot and refind are a good idea.

Edit: GRUB is also pretty useful if your system gets screwed up, and you need to change command line parameters to atleast boot to the command line and fix it.

Most of the time you dont NEED grub to manage multiple os booting on UEFI though. There is usually a key that you hit while on the manufacturer logo to pull up a menu that includes all possible boot items. So long as both Windows and Linux have been installed right as EFI variables then both should be there. More uncommon these days are boot screens or UEFI's that dont allow some form of this as its quite literally part of the spec