Changes/BootLoaderSpecByDefault

Make BootLoaderSpec-style configuration files the default

Summary

This change enables the use of per-boot-entry configuration files, similar to those described in Boot Loader Specification (BLS), to populate the bootloader's menu entries.

Owner

• Name: Javier Martinez Canillas
• Email: javierm@redhat.com

• Name: Peter Jones
• Email: pjones@redhat.com

• Release notes owner:

Current status

• Targeted release: Fedora 29
• Last updated: 2018-06-18
• Tracker bug:
• Release Notes tracking:

Detailed Description

The Boot Loader Specification (BLS) defines a scheme and file format to manage boot loader configuration for each boot option in a drop-in directory, without the need to manipulate bootloader configuration files. Directories of individual drop-in configuration files are standard for many purposes on Linux nowadays, so the goal is to also extend this concept for boot menu entries. This proposal does not include full implementation of that specification, which is not widely adopted, but merely refers loosely to the format and general layout of the configuration files.

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.

The current component that does this work is grubby, that has support for all the different bootloader configuration file formats and manipulates them on kernel installation or uninstallation. Besides manipulating the bootloader configuration files, grubby also does other things like running dracut to create an initial ramdisk image.

Fedora already has a lot of infrastructure in place to not require modifying bootloader configuration files for boot menu entries. Fedora's grub2 includes a "blscfg" command to load and build menus from configuration files, which the Fedora kernel packages provide, and the kernel-install script can do any additional task that is currently done by grubby. The kernel-install script has a pluggable design that uses a drop-in directory for scripts to extend its functionality, so if needed, any bootloader specific logic can be implemented as kernel-install scripts. With this setup the core bootloader configuration files can be static and not modified after installation.

The missing piece was the lack of support in our bootloaders, but our default bootloaders now have support to parse BLS-like configuration files now. So we can default to install BLS files on kernel installation and drop grubby.

Benefit to Fedora

grubby is a monolithic C program with thousands lines of code that grew organically over the last 17 years. So it has became complex and hard to maintain, it also has a lot of legacy code for bootloaders and architectures that are no longer supported by Fedora such as lilo (x86), elilo (IA64), silo (SPARC) and yaboot (PowerPC).

Getting rid of grubby and using BLS fragments will simplify the kernel installation process significantly and make it more consistent across the different architectures. This will also make it easier for automation tools to manage the bootloader menu options since it will just be a matter of adding, removing or editing individual boot entry files in a directory.

Scope

• Proposal owners:
  • Generate BLS snippets at kernel build time and ship in the kernel packages.
  • Make kernel-install scripts to copy the BLS, kernel and initramfs images and do any architecture specific task.
  • Make GRUB 2, zipl and Petitboot bootloaders to populate their boot menu entries from the information in BLS files.
  • Have a grubby wrapper for backward compatbility that manipulates BLS files.
  • Modify packages that use grubby to instead install BLS fragments (memtest86+, tuned).
  • Make sure this is all properly documented in release-notes, etc.

• Other developers:
  • The anaconda developers will need to review and merge the patches to change the default to BLS.
  • Test and watch for regressions.

• Release engineering:

RelEng review ticket: #7572

• • List of deliverables: N/A

• Policies and guidelines: The policies and guidelines do not need to be updated.

• Trademark approval: No changes needed.

Upgrade/compatibility impact

The changes are in the bootloader configuration files (grub.cfg, zipl.conf) that are generated at install time, so users upgrading from a previous version of Fedora will keep the old behaviour.

Users can manually enable BLS support by using a helper script that switches from the current configuration to one using BLS. This helper script is grub2-switch-to-blscfg for GRUB 2 and Petitboot and zipl-switch-to-blscfg for zipl. The helper script is automatically executed on grubby uninstallation, so another way for users to switch to a BLS based configuration is by removing the grubby package.

Users can also switch back to a non-BLS configuration by restoring the old configuration from a backup file. Proper documentation will be provided with detailed instructions on how to switch back and forth between the two types of configurations. Something to keep in mind is that kernels installed after switching to a BLS configuration won't be present in the old configuration backup file. On platforms using grub, users can also switch back by re-installing grubby, removing "GRUB_ENABLE_BLSCFG=true" from /etc/default/grub , and using grub2-mkconfig to re-generate their configuration file.

Another program is also provided for compatibility with other functions of grubby, such as determining or setting the next kernel to boot, and other functionality.

How To Test

• Architectures using the GRUB 2 or Petitboot bootloaders

Run the grub2-switch-to-blscfg script

 $ grub2-switch-to-blscfg

• Architectures using the zipl bootloader

Run the zipl-switch-to-blscfg script

 $ zipl-switch-to-blscfg

or

• Any architecture

Remove the grubby package

 $ sudo dnf remove grubby

When the system is rebooted, the boot menu entries would had been populated from the information contained in the BLS fragments files.

User Experience

No visible changes are expected, the bootloaders will populate the same boot menu entries. The only thing that changes is from where this information is taken.

Dependencies

None

Contingency Plan

• Contingency mechanism: Revert the anaconda changes
• Contingency deadline: Beta Freeze
• Blocks release? No
• Blocks product? None

Release Notes

TODO