Repository navigation
store: Treat SystemNotUEFI like a missing LoaderDevicePartUUID - #2602
dustinkirkland wants to merge 2 commits into
Conversation
|
Right, even though our CI matrix is huge, we are clearly missing a BIOS + composefs case. Could probably be a postsubmit. |
There was a problem hiding this comment.
🟢 Approval recommended
There are no active review issues for the non-UEFI ESP-discovery fallback.
No open issues 🎉
What changed in this PR
This PR restores composefs operations on non-UEFI systems that store boot entries on an EFI System Partition (ESP), by allowing ESP discovery to fall back when EFI variables are unavailable.
Changes:
- Treats
SystemNotUEFIlikeMissingVar, searching the root disk’s ESPs instead of failing. - Extracts the EFI-result decision into a pure helper while preserving other error handling.
- Adds unit coverage for successful reads, both fallback conditions, and propagation of other errors.
| File | Description |
|---|---|
crates/lib/src/store/mod.rs |
Adds the non-UEFI ESP-discovery fallback, a decision helper, and unit tests. |
Review effort: Balanced
dc39745 to
15078eb
Compare
…m_esp Prep for treating SystemNotUEFI like MissingVar; splitting the decision from the I/O makes it unit-testable. No functional change. Assisted-by: AI Signed-off-by: Dustin Kirkland <dustin.kirkland@chainguard.dev>
find_booted_from_esp (3b40e99, "store: Select the booted ESP via LoaderDevicePartUUID") falls back to searching the colocated ESPs when the variable is missing, but treats SystemNotUEFI as fatal. On a system not booted via UEFI, storage init fails, and with it every composefs `bootc status`, `upgrade` and `rollback`: error: Status: Finding ESP used for booting: Reading LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f: SystemNotUEFI Seen on a Raspberry Pi 5 that boots its kernel directly from the Pi firmware with the BLS entries on an ESP-typed FAT partition, after moving from bootc 1.17.1 to 1.17.3. It has no EFI variables, but the colocated-ESP fallback finds its ESP, as find_first_colocated_esp() did before 3b40e99. classify_bootloader already treats SystemNotUEFI and MissingVar alike for EFI_LOADER_INFO. Closes: bootc-dev#2605 Assisted-by: AI Signed-off-by: Dustin Kirkland <dustin.kirkland@chainguard.dev>
15078eb to
655a94f
Compare
we don't support composefs for BIOS at all right now. We have assumptions all over the code base that and EFI partition will be present |
|
I'm happy to help identify and work through the breakages / fixes. So far, this patch is what we need. I'm happy to keep sending fixes. |
|
Oh! And to clarify: this is not BIOS. The ESP is present on the Pi 5; its firmware just doesn't provide EFI variables. |
OK right, my bad. I think we are going to need to support this though in the future so we can complete an ostree transition.
Got it. |
| fn booted_esp_partuuid(efi_var: Result<String, EfiError>) -> Result<Option<String>> { | ||
| match efi_var { | ||
| Ok(u) => Ok(Some(u)), | ||
| Err(EfiError::MissingVar) | Err(EfiError::SystemNotUEFI) => Ok(None), |
There was a problem hiding this comment.
Doesn't EfiError::SystemNotUEFI imply there's no EFI? This was treated as fatal because, currently, for composefs we hard require an ESP
There was a problem hiding this comment.
Okay, my bad, read the issue about raspberry pi. I still think we should special case this and make EfiError::SystemNotUEFI fatal
There was a problem hiding this comment.
Thanks. The ESP is still required here: for SystemNotUEFI this doesn't skip the ESP, it searches the root device's ESPs and fails with "No ESP found" (or "Failed to find bootc owned ESP") if none is ours. So a BIOS install without an ESP still errors. It's also how classify_bootloader already treats SystemNotUEFI for this same Raspberry Pi case; this makes find_booted_from_esp agree with it. (1.17.2 through 1.17.4 fail every bootc command on these boards.)
If you'd still rather keep it explicit, I can either:
- keep
SystemNotUEFIfatal unless exactly one colocated ESP holding bootc's BLS entries is found, or - keep this, and make the no-ESP error say "not booted via UEFI and no ESP found; composefs requires an ESP".
Which would you prefer?
Closes #2605.
find_booted_from_esp()(3b40e99, first in v1.17.2) falls back to searching the colocated ESPs whenLoaderDevicePartUUIDis missing, but treatsSystemNotUEFIas fatal. So on a system that isn't booted via UEFI, every composefsbootc status,upgradeandrollbackfails at storage init.Two commits:
SystemNotUEFIlikeMissingVar, the wayclassify_bootloader()already does.Verification: Raspberry Pi 5 (aarch64), kernel booted directly by the Pi firmware, composefs install with BLS entries on an ESP-typed FAT partition. With 1.17.3:
bootc statusfails withSystemNotUEFI.bootc statusandbootc upgrade --checkwork on the same boot.bootc-libunit tests pass for each commit, andcargo fmt --checkis clean.The
test-upgrade (centos-10, ostree)failure (and therequired-checksjobs that aggregate it) also fails on other open PRs right now. Its error is the signature check onregistry.access.redhat.com/ubi9/podman.Assisted-by: AI
I reviewed all of this and it makes sense to me; I've tested it extensively.