aboot support followup by alexlarsson · Pull Request #2593 · bootc-dev/bootc

alexlarsson · 2026-10-27T15:27:34Z

There were some remaining comments in #2490 and these are handled in this PR.

Changes:

Check that deployed aboot images have aboot-deploy so we don't end up in s setup where we can't further update
Track the bootloader in the origin file so that we can correctly report this in the status
Use tracked bootloader to ensure that we don't update to an aboot image with the wrong bootloader
After failed update, allow later update/switch to replace the existing failed pending update.

alexlarsson · 2026-10-27T15:29:00Z

@jmarrero moved the followup here

Johan-Liebert1 · 2026-10-28T08:43:07Z

        .section(ORIGIN_KEY_BOOT)
-        .item(ORIGIN_KEY_BOOT_TYPE, boot_type);
+        .item(ORIGIN_KEY_BOOT_TYPE, boot_type)
+        .item(ORIGIN_KEY_BOOTLOADER, bootloader);


We've been refraining from storing the bootloader in the origin file. Is there a way to determine this at runtime as we do with other bootloaders?

Its a bit tricky, as it will have to encode some internal knowledge, like config files. But, I'll give it a go.

Ok, I replaced this with reading /etc/aboot.cfg

hmm... this is also pretty weird. So the reason for us not storing bootloader info in origin file is we can easily figure it out at runtime, by reading efivars, which also helps us again some accidental file corruption. I think the origin file approach is much better than storing this in /etc. But, ideally we'd want to read some sort of system variable to figure it out

We're already storing this in /etc though. That is how aboot-deploy knows how do do the update for the current system. This is just reading that data.

Copilot

🟡 Changes recommended

An unchanged-spec shortcut can make bootc switch --apply report success without restaging or rebooting when retrying a failed mutable-tag upgrade.

1 open issue

Retry mutable-tag upgrade after failed candidate is discarded · New

What changed in this PR

This follow-up strengthens composefs Android boot support with deployment checks, bootloader reporting, and explicit recovery from failed updates.

Changes:

Require aboot-deploy in target images and validate bootloader compatibility.
Derive the host bootloader from aboot configuration for deployment status.
Allow failed updates to be discarded and retried after reboot, with documentation and test coverage.

File	Description
`tmt/tests/booted/test-aboot-update-rollback.py`	Tests failed deployment retention, explicit retry, and rollback.
`tmt/tests/booted/aboot_testlib.py`	Checks bootloader identity and supports expected staged deployments.
`docs/src/bootc-experimental-composefs-aboot.7.md`	Documents failed-update recovery and retry behavior.
`crates/lib/src/bootc_composefs/update.rs`	Adds target validation and failed-update cleanup during upgrades.
`crates/lib/src/bootc_composefs/switch.rs`	Clears failed aboot attempts before preparing switches.
`crates/lib/src/bootc_composefs/status.rs`	Reports the configured host bootloader for aboot deployments.
`crates/lib/src/bootc_composefs/boot.rs`	Requires deployment tooling during installation and exposes bootloader validation.
`crates/lib/src/bootc_composefs/aboot.rs`	Adds bootloader detection, tooling checks, and failed-attempt cleanup with unit tests.

_{Review effort: Balanced}

+    if discard_failed_aboot_update(storage, &host)? {
+        host = get_composefs_status(storage, booted_cfs).await?;
+    }


jmarrero-bot

Looks right overall; one bug to fix in the switch retry path (inline), and the PR body is stale: it says the bootloader is tracked in the origin file, but this revision reads the host's /etc/aboot.cfg instead. Commit 2's "VM regression test was extended but not run" line is also out of date now that CI ran it.

Tested at efaa310: cargo test -p bootc-lib --lib (336 passed) and just test-ukiboot on a Fedora 44 base (plan-61 and plan-62 pass, all five reboot stages of plan-62).

Test gaps worth covering: the switch retry, a target image without aboot-deploy being rejected (e.g. a v3 image built with rm /usr/bin/aboot-deploy), and the bootloader-change rejection on update (a unit test on a small helper is probably the realistic option without an Android image in CI).

Generated-by: https://github.com/jmarrero-bot#llms

jmarrero-bot · 2026-10-30T09:24:00Z

        delta.validate_image_reference(&target)?;
    }

+    if discard_failed_aboot_update(storage, &host)? {


After a failed upgrade of a mutable tag, bootc switch <same ref> discards the attempt here, the status reload puts spec.image back to the booted ref, and then it hits "Image specification is unchanged" and stages nothing (exit 0, and --apply doesn't reboot). Copilot raised this too (r4421862897).

Related: here and in update.rs (upgrade_composefs) the discard happens before the target is pulled or validated, so a typo'd ref or a registry outage throws away the attempt the docs say is kept for inspection, and the command fails anyway. Could the discard happen only once the target is resolved, and skip the unchanged-spec shortcut when something was discarded?

Fixed this in a new commit.

Without this, later updates will fail, so ensure we don't get into this bad state. Signed-off-by: Alexander Larsson <alexl@redhat.com>

Retaining an attempted aboot deployment currently blocks further updates and switches after a failed flash or firmware fallback. Instead we allow an explicit update or switch to discard it after reboot, preserving the selected image source and refreshing status before checking deployment collisions. Keep the same-boot guard and leave failed attempts disarmed across ordinary reboots. Rollback can also discard an older failed attempt when a valid rollback deployment remains available. Document recovery and extend the unit and VM tests to cover failed finalization, repeated reboots without reflashing, and explicit retry. Assisted-by: AI Signed-off-by: Alexander Larsson <alexl@redhat.com>

We're currently always showing "bootloader None" in the aboot entires, this is not right for ukiboot hosts. Read BOOT_TYPE from the running system's /etc/aboot.cfg instead, reporting ukiboot for ukiboot configurations and none for other values. Assisted-by: AI Signed-off-by: Alexander Larsson <alexl@redhat.com>

Android aboot and ukiboot share the Aboot boot type but require different bootloaders. Checking only the boot type allows updates across incompatible layouts. Reuse the install validator against the running host's detected bootloader before staging an update. Assisted-by: AI Signed-off-by: Alexander Larsson <alexl@redhat.com>

alexlarsson · 2026-11-02T09:26:38Z

I fixed the switch on failed case, remaining comments are imho not applicable.

A failed aboot update can have the same image reference as the booted (i.e. last working) deployment. In this case switch would consider the spec unchanged and returns without staging the requested retry. We no instead discard the old update and queue a new one. Assisted-by: AI Signed-off-by: Alexander Larsson <alexl@redhat.com>

bootc-bot Bot requested a review from henrywang October 27, 2026 15:28

github-actions Bot added the area/documentation Updates to the documentation label Oct 27, 2026

Johan-Liebert1 reviewed Oct 28, 2026

View reviewed changes

alexlarsson force-pushed the aboot-followup branch from 7c5d3bb to efaa310 Compare October 28, 2026 09:13

jmarrero self-assigned this Oct 30, 2026

jmarrero requested a balanced review from Copilot October 30, 2026 08:39

Copilot started reviewing on behalf of jmarrero October 30, 2026 08:39

View session

Copilot AI reviewed Oct 30, 2026

View reviewed changes

Comment thread crates/lib/src/bootc_composefs/switch.rs Outdated

Comment on lines +52 to +54

if discard_failed_aboot_update(storage, &host)? {

host = get_composefs_status(storage, booted_cfs).await?;

}

jmarrero-bot reviewed Oct 30, 2026

View reviewed changes

alexlarsson added 4 commits November 2, 2026 10:23

aboot: Require aboot-deploy in images at install/update

709f0c4

Without this, later updates will fail, so ensure we don't get into this bad state. Signed-off-by: Alexander Larsson <alexl@redhat.com>

alexlarsson force-pushed the aboot-followup branch from efaa310 to 3c8d9c1 Compare November 2, 2026 09:23

alexlarsson force-pushed the aboot-followup branch from 3c8d9c1 to 58ca6d9 Compare November 2, 2026 14:38

Conversation

alexlarsson commented Oct 27, 2026

Uh oh!

alexlarsson commented Oct 27, 2026

Uh oh!

Johan-Liebert1 Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

alexlarsson Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

alexlarsson Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

Johan-Liebert1 Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

alexlarsson Oct 28, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

jmarrero-bot left a comment

Choose a reason for hiding this comment

Uh oh!

jmarrero-bot Oct 30, 2026

Choose a reason for hiding this comment

Uh oh!

alexlarsson Nov 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alexlarsson commented Nov 2, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants