When testing, developing and diagnosing it is useful to be able to roll back an update, even after it is committed. This logic is the same as what is done after an update is installed and before the reboot happens (swap partitions). Note that in this case we do not necessarily know what is on the inactive partition (it might have been a while since we installed something there), but this is up to the user to figure out and decide.
Secondly, we may want to offer this feature as a coordinated "rollback" w/ server support in the future. It is already possible today by deploying the old update but this would save some time and bandwidth.
Thirdly, there is a potential use case where both rootfs partitions are provisioned before manufacturing. The provision rootfs is booted during manufacturing (it has some development/debug/provisioning tools) and then when it's done we want to swap to the production rootfs (the currently inactive partition).
- A new CLI option to mender which will reconfigure to boot the currently inactive partition
- If the reboot (triggered by user, not this option) fails, it will come back with the partition it was currently running
- Works both for managed and standalone mode