From Fedora Project Wiki
(Add trackers)
 
Line 20: Line 20:
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* FESCo issue: [https://pagure.io/fesco/issue/2543 #2543]
* FESCo issue: [https://pagure.io/fesco/issue/2543 #2543]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1918817 #1918817]
* Release Notes tracking: <will be assigned by the Wrangler>
* Release Notes tracking: [https://pagure.io/fedora-docs/release-notes/issue/639 #639]


== Detailed Description ==
== Detailed Description ==

Latest revision as of 15:54, 21 January 2021

Unify the GRUB configuration files location across all supported architectures

Summary

This change makes the GRUB configuration files layout to be consistent across all the supported architectures. Currently EFI is a special case since the GRUB configuration file and environment variables block are stored in the EFI System Partition (ESP) instead of the boot partition (or /boot directory if no boot partition is used).

Owner

Current status

Detailed Description

The GRUB configuration files layout on EFI platforms is not consistent with the other non-EFI platforms (e.g: x86 with legacy BIOS, ppc64le with Open Firmware). On platforms using EFI the GRUB configuration file (grub.cfg) and environment variables block (grubenv) are stored in the EFI System Partition (ESP) while for non-EFI platforms these are stored in the boot partition (or /boot directory if not boot partition is used).

The reason for this is that the path where the GRUB bootloader searches for its configuration file varies depending on the firmware interface used. In most cases, GRUB searches for it in the path set in the $prefix variable. The device is not specified in that case, GRUB just searches for a configuration in this path for every detected device. But on EFI, a special $fw_path variable is used instead. This variable specifies both the device and path from where the GRUB bootloader was loaded and these are used to search for the configuration file. This is done for security reasons, to make sure that the correct GRUB configuration file is used and not just the first one found in one of the detected devices.

Since the GRUB binary is located in the ESP, it expects to find the configuration file in that location as well. But this creates the mentioned inconsistency, because the GRUB configuration file has to be stored in /boot/efi/EFI/fedora/grub.cfg while for non-EFI platforms it has to be stored in /boot/grub2/grub.cfg.

This leads to a GRUB configuration layout that is confusing for users and error prone, since either the tools that are used to manage these files have to be aware of the differences or symbolic links used to hide the fact that the pats differ depending on the platform. Also, it creates artificial constraints on the OS installation due the differences in the configuration layout used. A system installed when using EFI won't be bootable if the firmware configuration is changed to boot using legacy BIOS instead, for example enabling the EFI Compatibility Support Module or moving the disk to a BIOS machine.

The proposal is to always store the grub.cfg and grubenv files in the /boot/grub2/ directory, making /boot/efi/EFI/fedora/grub.cfg to only be a small configuration file that sets a different $prefix variable and loads the configuration file stored in /boot/grub2/grub.cfg.

The $prefix variable will be set to the device partition where /boot/grub2/grub.cfg is stored, using the partition filesystem's Universally Unique IDentifier (UUID). That way the correct GRUB configuration file will be loaded, making it as secure as the current approach where the configuration file in the ESP is used.

A drawback of the new approach is that the GRUB configuration will now depend on the boot partition (or /boot directory if no boot partition is used). But since the kernel and initramfs images are stored there too, the bootloader configuration already has this dependency anyways.

Note that the proposed configuration files layout is already used by the Fedora CoreOS Assembler (COSA) and OSBuild image builders. So this will make the systems installed with Anaconda to be consistent with the images generated by these.

Benefit to Fedora

This change will not only simplify and make less confusing the GRUB configuration but also allow the following improvements:

  • To have a consistent configuration across all the architectures using GRUB.
  • Allow the same installation to be booted with either EFI or legacy BIOS.
  • Use the same documentation and commands for all architectures instead of having EFI as a special case.
  • Make GRUB configuration tools more robust by not relying on symbolic links to be created and not having to handle platform specific cases.
  • Align with images generated by COSA and OSBuild on how the GRUB configuration files are used.
  • Align with other Linux distributions on how the GRUB configuration files are used.

Scope

  • Proposal owners:
    • Modify Anaconda to generate the grub.cfg and grubenv files in /boot/grub2/ instead of /boot/efi/EFI/fedora/ for EFI platforms.
    • Make Anaconda to generate the minimal GRUB config file in the ESP that sets the $prefix variable and loads the configuration file located in /boot/grub2/grub.cfg.
    • Modify the grub2 package scriptlets to not generate the /boot/grub2/grubenv and /etc/grub2-efi.cfg symbolic links since these will not be needed anymore.
    • Make any changes needed in tools that use these configuration files (grubby, kernel-install scripts, etc).
  • Other developers:
    • The Anaconda developers will need to review and merge the patches to change where the GRUB configuration files are created.
    • Test and watch for regressions.
  • Release engineering: #9936
  • Policies and guidelines: The policies and guidelines do not need to be updated.
  • Trademark approval: No changes needed.

Upgrade/compatibility impact

The changes will be in Anaconda to generate the GRUB configuration files in the new location. Existing installations will be updated to the new configuration scheme when upgrading to Fedora 34.

The old files will be preserved in case the new configuration cause issues to users whose GRUB config diverges too much from the default.

Proper documentation will be provided with detailed instructions on how to use the backup configuration file and switch back for users that want to revert the changes.

How To Test

  • Install Fedora 34 and verify that the GRUB configuration is correct.
  • Check that the /boot/efi/EFI/fedora/grub{.cfg,env} files are not present.
  • Check that the /boot/grub2/grub{.cfg,env} files are present.
  • Enter the GRUB prompt by pressing 'c' from the GRUB boot menu and execute the following command:
echo $prefix

and verify that the prefix is set to the partition that contains the /boot/grub2 directory.

  • Re-generate the GRUB configuration file with:
grub2-mkconfig -o /boot/grub2/grub.cfg

and verify that the GRUB configuration is still correct.

User Experience

No visible changes are expected other than the configuration files being present in a different path. This should improve the overall user experience.

Dependencies

None

Contingency Plan

  • Contingency mechanism: Revert the Anaconda and grub2 package scriptlets changes.
  • Contingency deadline: Beta Freeze
  • Blocks release? No
  • Blocks product? None

Documentation