From Fedora Project Wiki
 
Line 41: Line 41:
 
Also see this [https://lists.freedesktop.org/archives/systemd-devel/2020-June/044800.html mailinglist discussion].
 
Also see this [https://lists.freedesktop.org/archives/systemd-devel/2020-June/044800.html mailinglist discussion].
  
Status update: 1. has been successfully implemented for Fedora 33, allowing us to drop most of our downstream GNOME patches. 2. require more upstream discussion so that has been delayed to a future Fedora release.
+
Status update: 1. has been successfully implemented for Fedora 33, allowing us to drop most of our downstream GNOME patches. 2. requires more upstream discussion so that has been delayed to a future Fedora release.
  
 
== Feedback ==
 
== Feedback ==

Latest revision as of 16:07, 11 August 2020

Cleanup GNOME Hidden Boot Menu Integration

Summary

GNOME integrates with Fedora's hidden boot menu feature to signal to the bootloader that boot was successful and to request the menu to be shown the next boot when "Boot Options" is selected in the Shutdown/Reboot dialog. Currently Fedora carries downstream patches for this, which directly call the Fedora specific grub2-set-bootflag helper. The goal of this change is to replace these downstream patches with a clean bootloader agnostic solution which can be submitted upstream.

Owner

Current status

Detailed Description

GNOME has 2 integration points with the hidden boot menu feature:

  1. Requesting the menu to be shown the next boot when "Boot Options" is selected in the Shutdown/Reboot dialog.
  2. Signalling the bootloader that the boot was successful.

To replace our downstream patches for 1. we can use the new(ish) systemd DBUS API used by "systemctl reboot --boot-loader-menu=60". This currently only works with sd-boot, but systemd has hooks to allow integration with other bootloaders, see the SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU env. variable documentation. So we can support this in grub2 with some relatively simply changes and then replace our downstream patches for this with new patches using the systemd DBUS API for this.

Replacing our downstream patches for 2. with an upstreamable bootloader agnostic solution is somewhat involved. systemd has its Automatic Boot Assessment feature, which is somewhat similar in that it to deals with boot success detection, but its behavior on failure is different (auto fallback to an older kernel) and it is a sd-boot specific feature. Still we can use some parts of this. The boot-complete.target and the concept of having a systemd-bless-boot.service which Requires that target to be reached before it runs. So replacing out downstream patches for 2. will consists of 2 parts:

  1. grub2 changes: Add a grub2-bless-boot.service which Requires boot-complete.target and which does the equivalent of "grub2-set-bootflag boot_success" when that target is reached
  2. GNOME changes: Add a oneshot gnome-wait-for-boot-success.service to boot-complete.target, this will start a simple helper which listens on a unix socket until signalled, thus delaying the completion of boot-complete.target until it is signalled; and in the places where the downstream patches are currently directly calling "grub2-set-bootflag boot_success" signal (write a byte) this unix socket instead.

Also see this mailinglist discussion.

Status update: 1. has been successfully implemented for Fedora 33, allowing us to drop most of our downstream GNOME patches. 2. requires more upstream discussion so that has been delayed to a future Fedora release.

Feedback

Benefit to Fedora

This change will remove some technical-debt in the form of a couple of quick-and-dirty downstream patches from Fedora and will align GNOME's integration with the hidden boot menu feature with our upstream first policy.

Scope

  • Proposal owners:

Create the necessary changes ASAP and submit these to Fedora's grub2 and GNOME upstreams.

  • Other developers:

The bootloader team needs to do a new grub2 build with the changes added and the desktop team needs to add the GNOME changes to the GNOME packages. I will coordinate this with both teams.

  • Release engineering: #9557 (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

This change does not impact upgrades, the interface between the OS and grub2 still goes through the same unmodified grubenv settings. The only changes are in how we make the grubenv changes and all parts involved in that will be updated together.

How To Test

  1. Tests
    1. Install Fedora Workstation in a fresh vm or select reclaim diskspace -> delete all in the installer (do a single os install).
    2. Boot the system the grub menu should NOT show
    3. Login, wait 2 minutes then presss "CTRL + ALT + F6" followed by "CTRL + ALT + DEL" to do a reboot from the text-console without going through the GNOME reboot dialog. The grub menu should NOT show on the new boot.
    4. Reboot from the GNOME reboot dialog inside gdm. The grub menu should NOT show on the new boot.
    5. Open the GNOME reboot dialog, then press alt to change the "Reboot" button into "Boot Options" and click the "Boot Options" button (while keeping alt pressed). You should now get the grub menu, with a countdown of 60 seconds.
    6. Boot the system and then press "CTRL + ALT + F6" followed by "CTRL + ALT + DEL" to do a reboot from the text-console without logging in, this counts as a failed boot, so the menu should now show.
  2. EFI vs Classic PC BIOS boot
    1. All above tests should be done twice, once on an EFI system and once on a system using Classic PC BIOS boot

User Experience

The user experience will be unchanged, the goal of this change is to remove some technical debt and reduce the number of downstream changes Fedora carries.

Dependencies

There are no dependencies outside of the grub2 and GNOME changes.

Contingency Plan

  • Contingency mechanism: If this is not ready / complete when we near the beta freeze, then revert to using our downstream patches
  • Blocks release? No (assuming we do the revert so we do not regress)

Documentation

There are no functional changes, so no documentation changes are necessary.

Release Notes