[bootc 1.15.2 - almalinux-bootc:10.2] Consecutive soft-reboot transitions do not activate the expected target deployment

[jmamouriaux]

Summary

Consecutive bootc operations using --apply --soft-reboot=required on a ostree-backed system trigger systemd soft-reboots, but the expected target deployment is not activated on the second transition.

This reproduces with both bootc rollback and bootc upgrade.

Environment

• Repository: bootc-dev/bootc
• Backend: ostree with composefs enabled
• Commands tested with --apply --soft-reboot=required
• bootc status --verbose showed both booted and rollback deployments as Soft-reboot: yes
• bootc --version -> 1.15.2 (almalinux-bootc:10.2)

Reproduction

Starting state:

• Booted image: my-repo/my-project/my-image:A
• Rollback image: my-repo/my-project/my-image:B
• Both entries reported Soft-reboot: yes

Then run:

1. bootc rollback --apply --soft-reboot=required
2. Verify the system is now booted into my-image:B and rollback points to my-image:A
3. Run bootc rollback --apply --soft-reboot=required again

A similar issue is observed with consecutive bootc upgrade --apply --soft-reboot=required operations.

Expected behavior

If both the current and target deployments are reported as Soft-reboot: yes, a second consecutive soft-reboot-capable transition should activate the requested target deployment.

For rollback specifically, the second rollback should return the system to the previous deployment.

Actual behavior

The second soft-reboot is triggered by systemd, but the expected target deployment seems not to be activated.

After the second rollback, bootc status --verbose still shows the same booted/rollback pair instead of flipping back.

However, the userspace filesystem seems to be the expected one. So, what is returned by bootc status doesn't match with what is actually done.

Journal output confirms that a second soft-reboot occurred:

Aug 18 14:24:08 ar-node-153 systemd[1]: Soft-rebooting.
Aug 18 14:25:01 ar-node-153 systemd[1]: Soft-reboot finished in 57.036s, counter is now at 1.
...
Aug 18 14:29:18 ar-node-153 systemd[1]: Soft-rebooting.
Aug 18 14:30:25 ar-node-153 systemd[1]: Soft-reboot finished in 1min 11.431s, counter is now at 2.

ostree admin status after preparing the second transition shows a pending soft-reboot deployment:

  default ddf9cef2ccbd4637f3f5b4fc9d366aa3273ca3c3b1d5ba9bbff0910d7f19d650.1 (pending) (soft-reboot)
    origin: <unknown origin type>
* default cbdc4faca29a53293e0f717abb4d387b89470cd5c618ff68a702de2ba99d233a.0
    origin: <unknown origin type>

So the soft-reboot appears to be prepared, but the resulting active deployment after the reboot does not match expectations.

Additional notes

This does not appear to be a generic systemd limitation, because systemd reports completing two consecutive soft-reboots successfully. The problem seems specific to how bootc prepares or consumes the pending deployment for a second consecutive soft-reboot-capable transition.

Relevant implementation areas in the repository include:

• crates/lib/src/bootc_composefs/soft_reboot.rs
• crates/lib/src/bootc_composefs/update.rs
• crates/lib/src/bootc_composefs/rollback.rs

Possible direction

Investigate consecutive soft-reboot flows for both staged upgrades and rollback/revert flows, especially cases where a new pending (soft-reboot) deployment is prepared after a previous soft-reboot has already occurred.

[jmamouriaux]

Sorry for confusion, but I'm not really in composefs-backed. I think I'm in ostree-backed with composefs enabled (/ is mounted as composefs). Kind of hybrid mode.