Fedora May Make It Easier To Switch To systemd-boot, Making A GRUB-Free System

[phoronix]

Phoronix: Fedora May Make It Easier To Switch To systemd-boot, Making A GRUB-Free System

A change proposal that hopes to take place for Fedora 39 would make it easier to have an optionally GRUB-free system by instead performing a clean install with systemd-boot for booting on EFI platforms...

https://www.phoronix.com/news/Fedora-GRUB-Free-Proposal

[q2dg]

Please, Fedora engineers, do this too:
*Move UEFI's mount point to "/efi" instead of "/boot/efi" (at least, let us define it in Anaconda as an alternative mount point)
*Let Anaconda follow DPS (https://uapi-group.org/specification..._specification)
Thanks!

[mb_q]

One of the advantages of UEFI is that it can fully replace bootloader and just boot linux image with initramfs from EFS, also that the OS can alter the boot list & kernel command line via efivars. This is the way to go, not replacing GRUB with dumber GRUB.

[stan]

Removing GRUB is a planned-obsolescence, NIH, anti-feature in my book, meant to kick BIOS computers to the curb. From a user’s perspective, GRUB provides everything a bootloader should have, including ability to load on any firmware imaginable (Openfirmware for IBM/Sun/ARM/old Mac, BIOS, Coreboot, Uboot, and of course EFI) and backwards compatibility with pretty much any system in existence. And Fedora wants to throw it all away, for what? I say keep GRUB the veritable standard that it already is, and build on it!

The Fedora developer saying that the goal is not to remove GRUB is a bit disingenuous, because when the user testing pool is split, you end up with more bugs going undiscovered and unfixed in multiple mediocre bootloaders, when you could have had the bugs fixed in a single, kickass bootloader.

[clippy]

One of the advantages of UEFI is that it can fully replace bootloader and just boot linux image with initramfs from EFS, also that the OS can alter the boot list & kernel command line via efivars. This is the way to go, not replacing GRUB with dumber GRUB.

AFAICT, this setup does not allow for the command line to be edited prior to booting the kernel. For it to work, you'd need to chainload some EFI application between firmware an kernel, which pretty much what systemd-boot is. More importantly, EFI implementations found on regular devices are often buggy and outdated. Problems such as a limited number of allowed boot entries or the inability to change the boot order are way too common, sadly. It's just not feasible to roll out direct UEFI booting across a vast range of devices such as the Fedora install base.

[shmerl]

Does systemd-boot support booting without putting the kernel into UEFI partition while decrypting root? GRUB supports that, but it's super slow.

[iavael]

One of the advantages of UEFI is that it can fully replace bootloader and just boot linux image with initramfs from EFS, also that the OS can alter the boot list & kernel command line via efivars. This is the way to go, not replacing GRUB with dumber GRUB.

I wouldn't like efi vars being touched on every Kerner update: nvram write resource is limited and whst's more important some smart-ass UEFis rearrange boot order to their own liking after adding or removing boot entry.
So having small yet predictable bootloader with text configs (and handy features like hotkeys) is more preferable rather than barebone vendor-dependent and sometimes glitchy uefi boot menu.

[iavael]

Does systemd-boot support booting without putting the kernel into UEFI partition while decrypting root? GRUB supports that, but it's super slow.

No, it works only with filesystems that your uefi firmware understands (in most cases that's only fat32). If you want to avoid using esp for storing kernels then there's a common practice of creating XBOOTLDR partition with fat32 and mounting it as /boot

[shmerl]

No, it works only with filesystems that your uefi firmware understands (in most cases that's only fat32). If you want to avoid using esp for storing kernels then there's a common practice of creating XBOOTLDR partition with fat32 and mounting it as /boot

Yeah, I don't want an extra /boot partition. GRUB supports neat EFI + root set up, where kernel sits in the root and root itself is encrypted (GRUB sits in the EFI partition). The problem is that GRUB has really poor implementation of LUKS and decryption takes half a minute or more which is ridiculous.

[iavael]

Yeah, I don't want an extra /boot partition. GRUB supports neat EFI + root set up, where kernel sits in the root and root itself is encrypted (GRUB sits in the EFI partition). The problem is that GRUB has really poor implementation of LUKS and decryption takes half a minute or more which is ridiculous.

You can try to add support for luks in https://github.com/pbatard/efifs project (that essentially recompiles grub2 drivers for uefi) and fix low performance of luks driver in grub.