efi: error when the requested bootloader has no component - #1144
efi: error when the requested bootloader has no component#1144LorbusChris wants to merge 1 commit into
Conversation
|
Hi @LorbusChris. Thanks for your PR. I'm waiting for a coreos member to verify that this patch is reasonable to test. If it is, they should reply with Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
There was a problem hiding this comment.
Pull request overview
Adds validation preventing EFI installation when the requested bootloader component is missing.
Changes:
- Validates the requested EFI bootloader component.
- Improves missing-component diagnostics.
- Adds Systemd bootloader discovery tests.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
get_efi_component_from_usr filters out components belonging to *other* bootloaders, but components belonging to no bootloader are never removed -- notably shim, which appears in no bootloader's to_remove set. A non-empty result therefore does not mean the requested bootloader was found. So with --bootloader systemd against an image whose systemd-boot payload is absent, or laid out somewhere other than <name>/<version>/EFI, discovery returns just [shim], install copies shim to the ESP, and the command reports success. The machine is left with a first stage and nothing behind it, and nothing in the output says so. That is not hypothetical. Fedora's systemd-boot package installs its binary at usr/lib/efi/systemd-boot/<evr>/grubx64.efi, one level above the EFI directory the walker matches on, so it is invisible today: https://src.fedoraproject.org/rpms/systemd-boot/pull-request/4 Check explicitly that a component providing the requested bootloader survived the filter, and name the components that were found when it did not, so that a package shipping its payload at the wrong path is distinguishable from one shipping no payload at all. Discovering nothing at all is now also an error for a filtered request, where before it returned None. Only unfiltered discovery keeps that: None is how the caller learns the new layout is not in use and falls back to the legacy update directory, and that directory is copied wholesale with no way to honour a bootloader selection -- so reaching it with a request for one silently installs whatever it happens to contain. Assisted-by: AI
993818c to
c64357b
Compare
get_efi_component_from_usr filters out components belonging to other bootloaders, but components belonging to no bootloader are never removed -- notably shim, which appears in no bootloader's to_remove set. A non-empty result therefore does not mean the requested bootloader was found.
So with --bootloader systemd against an image whose systemd-boot payload is absent, or laid out somewhere other than //EFI, discovery returns just [shim], install copies shim to the ESP, and the command reports success. The machine is left with a first stage and nothing behind it, and nothing in the output says so.
That is not hypothetical. Fedora's systemd-boot package installs its binary at usr/lib/efi/systemd-boot//grubx64.efi, one level above the EFI directory the walker matches on, so it is invisible today:
https://src.fedoraproject.org/rpms/systemd-boot/pull-request/4
The same issue was also reported here: bootc-dev/bootc#2265
Check explicitly that a component providing the requested bootloader survived the filter, and name the components that were found when it did not, so that a package shipping its payload at the wrong path is distinguishable from one shipping no payload at all.
Assisted-by: AI