Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by johanb View Post
    Most of these are due to a shitty UEFI payload, better Coreboot/Libreboot support for modern hardware can't come soon enough.
    It's going to be a long wait, Intel has basically locked down that and made it obsolete with the FSP firmwares (that are of course not available unless you are a large OEM that can pay for the privilege)

    Leave a comment:


  • wizard69
    replied
    Interesting. I would have supported EFI booting myself. There will always be failure points and this includes files on disk. However therecappears ao be much simplification and improvement here so maybe it is the right path.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by nanonyme View Post
    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
    If they don't drop btrfs alltogether in the meantime...

    Leave a comment:


  • johanb
    replied
    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:

    Why not simply rely on the EFI boot menu logic?

    The EFI specification provides a boot options logic that can offer similar functionality. Here's why we think that it is not enough for our uses:
    • 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.
    • 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.
    • 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.
    • EFI is not universal yet (especially on non-x86 platforms), this specification is useful both for EFI and non-EFI boot loaders.
    • 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.
    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.

    Leave a comment:


  • nanonyme
    replied
    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

    Leave a comment:


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

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

    Adding to the growing list of features for Fedora 29 is a plan to fully support the FreeDesktop.org Boot Loader Specification and making use of their defined fragment files to populate boot-loader boot menu entries, including the kernel entries...

    http://www.phoronix.com/scan.php?pag...ot-Loader-Spec
Working...
X