Repository navigation
bootupd: write a grub-bls conformance marker (entries.srel) and dispatch on it #252
Description
From cgwalters on bootc-dev/bootc#2515 (bootc-dev/bootc#2515): instead of probing the bootloader offline, have bootupd write the Boot Loader Specification standard-conformance marker (https://uapi-group.org/specifications/specs/boot_loader_specification/#standard-conformance-marker-file) with grub-bls for GRUB, so tools know whether the bootloader implements the spec conformantly, and have bootc's install mount (default-entry selection, incl. GRUB's reverse filename order, bootc#2221) dispatch on it. Blocks bootc#2515, which is now a draft and off the composefs P0.
Generated-by: https://github.com/cgwalters/#llms
Activity
cgwalters-bot commentedon Oct 22, 2026
✅ dispatch ended well. Result: #252 (comment)
cgwalters-bot commentedon Oct 22, 2026
Still wanted, valid, not started, and it needs one decision from cgwalters before it can be planned: where the marker lives. A second, smaller block: no bootupd repository is in the dispatch bounds, so the first PR could not be dispatched today even with the design settled. Triage as of 21 Oct 2026.
Valid and reproducible from the code
entries.srelappears nowhere in coreos/bootupd at7b4b0c6(21 Oct) or bootc-dev/bootc atde7ae55(17 Oct).classify_bootloaderincrates/lib/src/bootc_composefs/status.rs, dispatches on theLoaderInfoEFI variable; without EFI variables, a/boot/loader/entriesdirectory with no/boot/grub2or/boot/grubmeans "systemd-boot". bootupd's ownget_bootloaderinsrc/bootloader.rsreads the same variable and falls back to GRUB. Offline, which is thebootc install mountcase in install mount: Select the deployment from the default boot entry bootc-dev/bootc#2515, there are no EFI variables, so a grub-cc system (entries on the ESP, no GRUB directory) is classified as systemd-boot. That is the failure cgwalters-bot reported on the PR and cgwalters answered with this idea.get_sorted_type1_boot_entries_helpersorts bysort-keyfor Systemd and by file name, descending, for Grub and GrubCC, because of GrubCC: Follow UPAI bootloader sorting spec bootc-dev/bootc#2221 (still open; grub-cc does not implement the spec's sorting). With one deployment it cannot matter; with several, mount picks a different deployment than GRUB boots.mainhas moved since.What fixing it takes: two PRs, bootupd first
backend install, once the EFI component is copied (efi.rsinstall), writeloader/entries.srelon that partition withgrub-blsfor Grub and GrubCC andtype1for Systemd (whatbootctl installwrites). bootupd already knows the bootloader at that point:installinsrc/bootupd.rstakes it from--bootloaderor the image's default and passes it to each component. Unit test on a temporary directory, and the e2e install test asserts the file. One small PR.get_bootloader(nine call sites) and by #2515's offline probe:grub-blsmeans GRUB ordering,type1means spec ordering, absent means today's probe, so systems installed before the marker keep working. Then #2515 rebases onto it. One PR.The decision: where the marker is written. The spec puts
entries.srelbeside theentries/directory on$BOOT, the XBOOTLDR partition if there is one and otherwise the ESP, and a value other thantype1means "another spec ownsloader/entries": systemd's kernel-install then stops writing Type 1 entries there (kernel-install.c,LAYOUT_OTHER), which is fine on bootc hosts but is a visible effect. GRUB's entries on bootc live in/boot/loader/entries, and that directory has two owners: on the ostree backend/boot/loaderis a symlink ostree re-points atloader.0/loader.1on every deploy (ostree-sysroot-deploy.c,swap_bootloader; onlyloader.N/entriesis wiped), and on composefs it is a plain directory bootc writes itself. The options: (A) the ESP'sloader/entries.srel, written by bootupd. It is the spec's$BOOTwhen there is no XBOOTLDR, bootupd already mounts and owns the ESP, bootc's install clears the ESP'sloader/before bootupd runs (clean_esp_bootloader_dirs), and it survives ostree deploys. It is not beside the entries GRUB actually reads, and BIOS-only installs have no ESP (there today's probe already says GRUB from/boot/grub2). (B)/boot/loader/entries.srel, beside the entries: bootupd would have to write it into bothloader.0andloader.1, or ostree writes it, and bootc writes it for composefs; three writers. (C) both. My recommendation is A, with bootc reading$BOOTfirst and the ESP second so B or C can come later. The second decision:.github/agentic-job/dispatch.tomllists cgwalters-forge/bootc but no bootupd repository, and the fork cgwalters-forge/bootupd exists (last push 7 Oct); add it, or say the bootupd PR is done by hand. With A chosen and a bootupd target allowed, the bootupd PR can be planned at once and the bootc PR right after.Read: this issue, bootc-dev/bootc#2515 (body, comments, reviews), bootc-dev/bootc#2221, tracker#31 and its 17 Oct triage, bootupd
src/bootupd.rs,src/efi.rs,src/bootloader.rs, bootccrates/lib/src/bootc_composefs/status.rs,bootloader.rs,install.rs,spec.rs, ostreeostree-sysroot-deploy.c, systemdkernel-install.c, the Boot Loader Specification, agent-boarddocs/job-plans.md, and the tracker'sdispatch.toml.