Fedora 29 To Fully Embrace The FreeDesktop.org Boot Loader Specification

[jpg44]

If they don't drop btrfs alltogether in the meantime...

btrfs is in the kernel mainline. So they would have to go out of their way to remove it from their build. I have no idea why since a COW filesystem with snapshots and multiple volumes at the filesystem level is the way to go. I think btrfs is the way to go. The idea of running xfs on devicemapper is kind of a kludge. Better idea: try Suse or Ubuntu.

[DrYak]

Most of these are due to a shitty UEFI payload, better Coreboot/Libreboot support for modern hardware can't come soon enough.

Except that a sizeable chunk of the criticism won't be solved.

A lot of them boil down to :
- Linux kernel needs parameters.

Linux-EFI expects them from the command line *only*. So the only way is to save them into the boot entry in the EFIvars. (If you move the same harddisk to a different machine, or clear the settings on this machine, you lose the kernel boot parameters).

GRUB2 (and almost every other boot loader) expects to find the parameters into a separate file (here: grub.cfg). You can straight boot into the bootloader as an EFI executable, the boot loader will take care of loading the parameters and passing them to the kernel.

Whether running on some shitty UEFI implementation or on the most modern and best Coreboot + Tianocore won't change a thing.
What you would need is a standard way for the Linux-EFI to load its parameters from a config file.

But still, Coreboot will fix the "shitty UEFI" part, guaranteeing that there *is* a menu to pick one possible boot entry (instead of only trying them in-order), and guaranteeing that there's a sane EFIvars editor that will help you re-add the boot menu entry if it is missing (because you switched machines or erased the settings).

[brrrrttttt]

All desktop motherboards and most laptops have these features, but some x86 tablets do not and pretty much all non-x86 platforms do not care about these features in their payload.
If we had coreboot on those devices we could choose any payload we want on these devices such as tianocore/seabios or even develop your own.

Yep, I gave 1 for that.

I have had this issue on my previous motherboard after a EFI upgrade, completely removed all boot entries except for my windows entry.
Had to get a live-usb to be able to boot my linux distro again.
When I updated my current AMD motherboard I did not have that issue though so at least it doesn't seem like it's common practice on most EFI implementations.

If we had coreboot we could choose to not use payloads which do not do such a critical thing without warning you.

0.5 for this one. The other half is related to the next one...

Would be nice to be have a feature to be able to export and import the EFI boot entry list (as well possibly also other EFI settings).

0 for this... maybe I was a bit harsh. The disk image needs to be bootable on another system without fluffing around setting EFI vars (regardless of how you do it).

Example of how EFI is not mature enough on non-x86 platforms.
There's not any coreboot support at all for non-x86 platforms as far as I know so it's hard for free software developers to improve this.

0 for this. Eh, keep EFI away from platforms it hasn't infected yet!

IMO it is insane to be to not be able to easily choose boot drive, an example of a bad EFI implementation.

1 for this.

[RahulSundaram]

wtf?! grubby?!

why the heck do they even need to use an abstraction layer to manipulate their own distro's bootloder? Does fedora even use more than one bootloader? I thought GRUB2 could run on any architecture.

Read the feature proposal

https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault

"This is especially important in Fedora because the same bootloader is not used in all architectures. GRUB 2 is used in most of them, but there are others such as zipl for s390x and Petitboot for ppc64le. Not all bootloaders have the same configuration file format, so there is a need for an indirection level and per bootloader specific logic to edit these configuration files, when adding or removing a boot entry."

This was discussed before here

https://www.phoronix.com/scan.php?pa...cuss-No-Grubby

[RahulSundaram]

If they don't drop btrfs alltogether in the meantime...

As long as Btrfs is available upstream, it might be fine to just keep it since the work to support it is already done in the installer and is not expected to change substantially for it to be a burden. RHEL is different because of commercial support obligations

[starshipeleven]

Example of how EFI is not mature enough on non-x86 platforms.
There's not any coreboot support at all for non-x86 platforms as far as I know so it's hard for free software developers to improve this.

Coreboot is just the hardware init phase, most other architectures deal with that using a bootROM (which is the best way imho), or some kind of bootloader (in many cases some u-boot fork).

Since 2016 the u-boot (one of the most common bootloader in embedded) can provide EFI too, it's an optional feature. https://www.cnx-software.com/2016/08...arm-platforms/

[starshipeleven]

By most, you mean 2.5/5?

Only one that can be seen as unrelated is 4 (EFI is not universal), and imho isn't a bad thing to begin with.
BIOS could (and did) do fine on all other points.
uboot is 100% better than UEFI even on x86 (if it was even possible at all outside of specific x86-based products)

[johanb]

By most, you mean 2.5/5?

Well, pretty much all of them are related to some extent IMO.

• The various EFI implementations implement the boot order/boot item logic to different levels. Some firmware implementations do not offer a boot menu at all and instead unconditionally follow the EFI boot order, booting the first item that is working.

All desktop motherboards and most laptops have these features, but some x86 tablets do not and pretty much all non-x86 platforms do not care about these features in their payload.
If we had coreboot on those devices we could choose any payload we want on these devices such as tianocore/seabios or even develop your own.

• If the firmware setup is used to reset all data usually all EFI boot entries are lost, making the system entirely unbootable, as the firmware setups generally do not offer a UI to define additional boot items. By placing the menu item information on disk it is always available, regardless if the BIOS setup data is lost.

I have had this issue on my previous motherboard after a EFI upgrade, completely removed all boot entries except for my windows entry.
Had to get a live-usb to be able to boot my linux distro again.
When I updated my current AMD motherboard I did not have that issue though so at least it doesn't seem like it's common practice on most EFI implementations.

If we had coreboot we could choose to not use payloads which do not do such a critical thing without warning you.

• Harddisk images should be moveable between machines and be bootable without requiring explicit EFI variables to be set. This also requires that the list of boot options is defined on disk, and not in EFI variables alone.

Would be nice to be have a feature to be able to export and import the EFI boot entry list (as well possibly also other EFI settings).

• EFI is not universal yet (especially on non-x86 platforms), this specification is useful both for EFI and non-EFI boot loaders.

Example of how EFI is not mature enough on non-x86 platforms.
There's not any coreboot support at all for non-x86 platforms as far as I know so it's hard for free software developers to improve this.

• Many EFI systems disable USB support during early boot to optimize boot times, thus making keyboard input unavailable in the EFI menu. It is thus useful if the OS UI has a standardized way to discover available boot options which can be booted to.

IMO it is insane to be to not be able to easily choose boot drive, an example of a bad EFI implementation.

[brrrrttttt]

I was about to say that bootloaders are obsolete nowadays since you can just skip them and boot straight into Linux from UEFI, then I read this section:



Most of these are due to a shitty UEFI payload, better Coreboot/Libreboot support for modern hardware can't come soon enough.
Really looking forward to when tianocore is more mature and has more features.

By most, you mean 2.5/5?

[starshipeleven]

Wow, so after this change the limitation that /boot cannot be on a Btrfs partition can possibly be lifted since Grub2 already supported booting from Btrfs default subvolume and grubby was the bottleneck

wtf?! grubby?!

why the heck do they even need to use an abstraction layer to manipulate their own distro's bootloder? Does fedora even use more than one bootloader? I thought GRUB2 could run on any architecture.