On a composefs-native sealed host (systemd-boot, UKI, Type1 BLS entries with uki keys), bootc status reports rollbackQueued: true immediately after a successful staged upgrade boot, and false when a rollback genuinely is queued. The BLSConfigType::EFI arm of the first-entry check in composefs_deployment_status_from is missing the negation that the NonEFI and GRUB UKI arms both have, so it reports a queued rollback exactly when the default entry does reference the booted deployment:
https://github.com/bootc-dev/bootc/blob/534c76ea/crates/lib/src/bootc_composefs/status.rs#L988-L995
Observed on a physical host (bootc 1.16.9-1.fc44, Fedora 44, Secure Boot, UKI):
- Staged an upgrade, verified
bootOrder: default / rollbackQueued: false, rebooted. bootc-finalize-staged.service ran at shutdown (journal-attested) and the new deployment booted (LoaderEntrySelected names the new entry; booted digest correct).
bootc status then reported bootOrder: rollback / rollbackQueued: true, while bootctl list --esp-path marked the booted deployment's entry (default) - it carries the primary sort-key, and sd-boot sorts sort-keys ascending.
- Trusting the status, we ran
bootc rollback to clear the queue. It printed "Reverting queued rollback state" and swapped the entries - making the old deployment sd-boot's real default while bootc status now read default / false. The documented remedy armed a silent regression.
- A second
bootc rollback (printing "Next boot: rollback deployment") restored the correct order - the messaging inverts together with the status.
Everything derived from the flag inverts with it: bootc rollback takes its direction and messaging from the same spec, and the guard that refuses to delete the rollback deployment while it is queued to boot (host.status.rollback_queued in delete.rs) fires in the wrong cases - a genuinely queued rollback deployment reads as safe to delete.
A/B on the same on-disk entry set (sd-boot default = booted deployment, confirmed via bootctl): stock 1.16.9 reports {"bootOrder":"rollback","rollbackQueued":true}; with the fix it reports {"bootOrder":"default","rollbackQueued":false}.
Possibly related but distinct: #2387 (soft-reboot promotion, same files).
On a composefs-native sealed host (systemd-boot, UKI, Type1 BLS entries with
ukikeys),bootc statusreportsrollbackQueued: trueimmediately after a successful staged upgrade boot, andfalsewhen a rollback genuinely is queued. TheBLSConfigType::EFIarm of the first-entry check incomposefs_deployment_status_fromis missing the negation that theNonEFIand GRUB UKI arms both have, so it reports a queued rollback exactly when the default entry does reference the booted deployment:https://github.com/bootc-dev/bootc/blob/534c76ea/crates/lib/src/bootc_composefs/status.rs#L988-L995
Observed on a physical host (bootc 1.16.9-1.fc44, Fedora 44, Secure Boot, UKI):
bootOrder: default/rollbackQueued: false, rebooted.bootc-finalize-staged.serviceran at shutdown (journal-attested) and the new deployment booted (LoaderEntrySelectednames the new entry; booted digest correct).bootc statusthen reportedbootOrder: rollback/rollbackQueued: true, whilebootctl list --esp-pathmarked the booted deployment's entry(default)- it carries the primary sort-key, and sd-boot sorts sort-keys ascending.bootc rollbackto clear the queue. It printed "Reverting queued rollback state" and swapped the entries - making the old deployment sd-boot's real default whilebootc statusnow readdefault/false. The documented remedy armed a silent regression.bootc rollback(printing "Next boot: rollback deployment") restored the correct order - the messaging inverts together with the status.Everything derived from the flag inverts with it:
bootc rollbacktakes its direction and messaging from the same spec, and the guard that refuses to delete the rollback deployment while it is queued to boot (host.status.rollback_queuedindelete.rs) fires in the wrong cases - a genuinely queued rollback deployment reads as safe to delete.A/B on the same on-disk entry set (sd-boot default = booted deployment, confirmed via
bootctl): stock 1.16.9 reports{"bootOrder":"rollback","rollbackQueued":true}; with the fix it reports{"bootOrder":"default","rollbackQueued":false}.Possibly related but distinct: #2387 (soft-reboot promotion, same files).