Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sys-boot/grub: Move to portage-stable, bump to 2.12, add Red Hat patches #2301

Closed
wants to merge 1 commit into from

Conversation

chewi
Copy link
Contributor

@chewi chewi commented Sep 10, 2024

grub: Move to portage-stable, 2.12 bump, add RH patches

We can now use Gentoo's upstream ebuild, save for a few small overrides in a separate env file.

This bumps GRUB from 2.06 to 2.12, but with Red Hat's large patch set applied, which is needed for Secure Boot. The existing two Flatcar patches have been rebased. Gentoo's patches are discarded because they conflict and are not relevant to Flatcar.

How to use

Build an image and try it out. Alternatively, take an existing image, replace grubx64.efi in the first partition, and test with UEFI. You can build grubx64.efi by installing sys-boot/grub to the host and the board root (--nodeps should be okay), tweaking the grub_install.sh script, and running the following command.

--- a/build_library/grub_install.sh
+++ b/build_library/grub_install.sh
@@ -113,23 +113,9 @@ cleanup() {
 trap cleanup EXIT
 
 info "Installing GRUB ${FLAGS_target} in ${FLAGS_disk_image##*/}"
-LOOP_DEV=$(sudo losetup --find --show --partscan "${FLAGS_disk_image}")
 ESP_DIR=$(mktemp --directory)
 MOUNTED=
 
-for (( i=0; i<5; ++i )); do
-    if sudo mount -t vfat "${LOOP_DEV}p1" "${ESP_DIR}"; then
-        MOUNTED=x
-        break
-    fi
-    warn "loopback device node ${LOOP_DEV}p1 still missing, reprobing..."
-    sudo blockdev --rereadpt "${LOOP_DEV}"
-    # sleep for 0.5, then 1, then 2, then 4, then 8 seconds.
-    sleep "$(bc <<<"scale=1; (2.0 ^ ${i}) / 2.0")"
-done
-if [[ -z ${MOUNTED} ]]; then
-    failboat "${LOOP_DEV}p1 where art thou? udev has forsaken us!"
-fi
 sudo mkdir -p "${ESP_DIR}/${GRUB_DIR}"
 
 info "Compressing modules in ${GRUB_DIR}"
@@ -143,7 +129,7 @@ info "Generating ${GRUB_DIR}/load.cfg"
 # by filesystem ID in case the platform doesn't provide the boot disk.
 # $root points to memdisk here so instead use hd0,gpt1 as a hint so it is
 # searched first.
-ESP_FSID=$(sudo grub-probe -t fs_uuid -d "${LOOP_DEV}p1")
+ESP_FSID=XXXX-XXXX # Get this from guestfish with blkid /dev/sda1
 sudo_clobber "${ESP_DIR}/${GRUB_DIR}/load.cfg" <<EOF
 search.fs_uuid ${ESP_FSID} root hd0,gpt1
 set prefix=(memdisk)
sudo ./build_library/grub_install.sh --target x86_64-efi --verity --copy_efi_grub .

Instructions on how to update the Red Hat patches are included in the README.

Testing done

A Jenkins run passes and local testing with QEMU amd64 works. The amd64 image is about 621KB larger, with most of the increases in /boot, which is very concerning, but not entirely surprising.

  • Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
  • Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

@jepio
Copy link
Member

jepio commented Sep 11, 2024

Do you have local changes to build_library/grub.cfg - something equivalent to what was there before commit abb6bdb?

# UEFI uses linuxefi/initrdefi instead of linux/initrd except for arm64
if [ "$grub_platform" = efi ]; then
  if [ "$grub_cpu" != arm64 ]; then
    set suf="efi"
  fi
fi

@jepio
Copy link
Member

jepio commented Sep 11, 2024

The other point: we need a kola test to ensure that the tpm2 eventlog is present and accessible...

Copy link

github-actions bot commented Sep 11, 2024

Build action triggered: https://github.com/flatcar/scripts/actions/runs/10845879989

@chewi
Copy link
Contributor Author

chewi commented Sep 11, 2024

Do you have local changes to build_library/grub.cfg - something equivalent to what was there before commit abb6bdb?

Can you expand on this? I haven't changed the config yet, but I was vaguely aware that there's linuxefi now as well as linux. I don't really understand the difference given that it supports EFI already.

Also, do we want to make that switch right now? I was thinking we might be able to merge these changes ahead of the wider Secure Boot work.

@chewi
Copy link
Contributor Author

chewi commented Sep 11, 2024

Looking at the code, I think linuxefi is just an alias for linux that ensures you don't accidentally boot without EFI when that module can't be loaded.

  cmd_linux =
    grub_register_command ("linux", grub_cmd_linux,
                           0, N_("Load Linux."));
  cmd_linuxefi =
    grub_register_command ("linuxefi", grub_cmd_linux,
                           0, N_("Load Linux."));

We can now use Gentoo's upstream ebuild, save for a few small overrides
in a separate env file.

This bumps GRUB from 2.06 to 2.12, but with Red Hat's large patch set
applied, which is needed for Secure Boot. The existing two Flatcar
patches have been rebased. Gentoo's patches are discarded because they
conflict and are not relevant to Flatcar.

Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
@chewi
Copy link
Contributor Author

chewi commented Sep 12, 2024

We're discussing whether the Red Hat patches are actually needed in flatcar/Flatcar#630, but FWIW, Jenkins has actually passed now.

@chewi
Copy link
Contributor Author

chewi commented Sep 12, 2024

The amd64 image is now 621KB larger, with most of the increases in /boot, which is very concerning. Dropping the Red Hat patches may help, but I suspect there will still be an increase. Coupled with potential increases to the initrd (which I'm trying to lessen), this could be a real issue.

@chewi
Copy link
Contributor Author

chewi commented Sep 13, 2024

Closing in favour of #2318.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants