Repository navigation
Support locking an existing staged deployment with --download-only #2425
Description
Activity
This does seem like a bug, basically the command line options aren't being taken into account in the change detection.
@HarshwardhanPatil07 Could you elaborate on the commands you're running? This is what I get on ostree backend
[root@fedora var]# ./bootc switch --download-only --transport containers-storage localhost/switch Deploying: done (4 seconds) Staged but not queued for next boot: ostree-unverified-image:containers-storage:localhost/switch Version: 44.20260824.0 Digest: sha256:0c87dbe3aec74edaa4c1ab18da7c5a26db5a2c6b85fa6aff4df969cbb4d247d5 [root@fedora var]# [root@fedora var]# [root@fedora var]# [root@fedora var]# ./bootc switch --from-downloaded Staged deployment will now be applied on reboot
This feels like it should be a separate operation altogether. Switching and then switching with
bootc switch --download-only <same_imge>again to "lock" the finalization feels kinda weird.@Johan-Liebert1
here is what I could find. I switch to new laptop due to some issues in software and my previous cmd ran history in terminal got deleted- Same image and already protected -> doing nothing is expected.
- Same image but queued for reboot -> bootc should protect it or return an error.
but it was
ostree admin statusbefore and after showed something different herethe difference was in ostree admin status
it was showing something scheduled for next boot but the image was same so ideally it shouldn't schedule for reboot
Problem
Running bootc switch --download-only for the same image that is already
staged does not convert the staged deployment from unlocked to download-only.
Instead, bootc exits successfully without changing the staged deployment:
The staged deployment continues to report:
This means management software cannot safely enable a policy requiring an
explicit apply operation after the image has already been staged.
The result was reproduced on both:
Both returned
Image specification is unchanged. with exit status 0, and bothleft
status.staged.downloadOnlyset tofalse.The OSTree-specific
ostree admin lock-finalizationcommand may provide alow-level workaround, but it is not a backend-independent bootc interface.
Background Why this matters bootc-dev/bootc-operator#151
While implementing
RequireSoftRebootsupport in bootc-operator, we need toguarantee that a staged deployment cannot be applied by an ordinary reboot
before the operator explicitly applies it.
For
RequireSoftReboot, the operator must ensure that an ordinary rebootcannot accidentally apply the staged image.
If
RequireSoftRebootis enabled after an update was staged normally,bootc-operator currently cannot safely lock that existing stage. It must reject
the policy transition and report SoftRebootStageUnlocked.
Expected Behavior:
If changing the state is unsupported, the command should return a clear error
instead of successfully reporting that the image specification is unchanged.
The operation should ideally be idempotent:
A backend-independent bootc operation would let the operator safely adopt the
existing stage instead.