Merge ~arraybolt3/grub:ubuntu into ~ubuntu-uefi-team/grub/+git/ubuntu:ubuntu
Status: | Needs review |
---|---|
Proposed branch: | ~arraybolt3/grub:ubuntu |
Merge into: | ~ubuntu-uefi-team/grub/+git/ubuntu:ubuntu |
Diff against target: |
318 lines (+254/-3) 7 files modified
debian/control (+1/-0) debian/grub-common-run (+33/-0) debian/grub-common.install.in (+1/-0) debian/grub-common.service (+1/-3) debian/patches/enable-grubenv-on-esp.patch (+214/-0) debian/patches/series (+1/-0) debian/update-grub (+3/-0) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Julian Andres Klode | Needs Fixing | ||
Steve Langasek | Abstain | ||
Mate Kukri | Pending | ||
Review via email: mp+462445@code.launchpad.net |
This proposal supersedes a proposal from 2024-03-14.
Description of the change
This patch enables the GRUB environment block to be used even if the /boot partition's filesystem cannot be written to by GRUB.
When /boot is a filesystem that GRUB cannot write to (such as BTRFS) on an EFI system, the current behavior is to disable recordfail support entirely and always show the boot menu. This is a non-ideal situation for some users. This patch works around the issue by detecting when /boot cannot be written to by GRUB and the system is EFI-based, and if both are true it saves and loads the environment block from the EFI System Partition if this is the case.
The way this is done is by detecting unwritable /boot and the use of EFI at grub.cfg generation time. If the conditions are met, grub.cfg is adjusted to search for the FS that is mounted at /boot/efi at boot time. It then saves and loads environment variables to and from (efi filesystem)
How this code handles some edge cases:
* Multiple EFI System Partitions with RAID - Only the filesystem used by /boot/efi is ever used for grubenv storage. GRUB and grub-common.service should always find and handle the correct file.
* Multiple Ubuntu versions and/or flavors on the same system - This will result in some versions of Ubuntu occasionally "taking control" of the EFI system partition during GRUB bootloader upgrades. In the event the format of grubenv changes between versions of GRUB, this could theoretically lead to boot failure after a GRUB update. To work around this, on every update-grub invocation, the grubenv file is deleted and a blank one generated. Assuming update-grub is called when GRUB is updated (**which I did not verify was the case!!!**), this will ensure that grubenv is always compatible with the GRUB installed at EFI/ubuntu.
* User wants to have their own grubenv and/or grub.cfg - The user can modify EFI/ubuntu/grub.cfg to point to their own custom grub.cfg, which can point at their desired custom grubenv. This code should not override that as it only changes the generation of /boot/grub/
* GRUB is installed to EFI/BOOT, not EFI/ubuntu - The EFI/ubuntu directory is automatically created by update-grub and grub-common.serivce if needed. It does not require GRUB to be installed there to work.
* Multiple operating systems other than Ubuntu are installed - grubenv is saved to EFI/ubuntu/grubenv, and should not affect any non-Ubuntu flavors except for Ubuntu derivatives (which presumably will also be using this change).
* EFI installation is converted to a legacy BIOS installation - the EFI system partition is only modified to include grubenv if the system if EFI-based. Even if /boot is unwritable by GRUB, grubenv will still be located at /boot/grub/grubenv on a BIOS system, rather than /boot/efi/
* Legacy BIOS installation is converted to an EFI installation - See above - the logic will start reading and writing grubenv to/from /boot/efi/
Shoot, I proposed this against the wrong branch.