We are currently working on the mender.io standalone client integration in a debian based linux basesystem (ELBE).
During this we stumbled upon a use case we have as requirement that we have a problem fulfilling (or we don’t find it). Maybe someone has a clue?
Let me give you a bit of context:
Use case:
We need a very high availability with the devices we deploy the OS on so actually no update is the best update. But of course due to security risks and feature updates we need to do updates.
As such we have the resulting feature request, that if an update was done and the device is being tested it shall be possible to rollback to the previous version to quickly fix any issue that may arise during testing. This should be possible also after reboot.
Our problem:
A rollback is theoretically possible with the mender.io client, but it is necessary to commit before reboot. After commit and reboot we did not find an “official” solution to shift the pointer to the “old” partition after the commit.
As such we currently cant find a solution for the feature as a rollback to the previous version is not possible after testing.
Did we miss a functionality of the client that would solve this problem? If not, this would be a feature request from our side:
A Command which enables to switch the bootloader to the previous version even after reboot of the device.
A rollback is theoretically possible with the mender.io client, but it is necessary to commit before reboot. After commit and reboot we did not find an “official” solution to shift the pointer to the “old” partition after the commit.
I’m not quite sure I follow? Your use-case is that you have to commit before rebooting, or is it just this is what you have been doing?
The regular workflow is to install → reboot → commit.
In any case, it is possible to manually mess around with the bootloader environment (in fact this is what the client does), through our userspace tooling.
Depending on if you are running Grub or Uboot, the tools are:
Thanks for the reply!
Sorry, I was a bit missleading I guess.
Like you said the regular workflow is to install → reboot → commit. Then a rollback is not possible anymore because you commited.
What we would like to be able to do is install → reboot → commit → rollback.
Reason is that for example after a few days of usage a unexpected problem occurs and you need a fast fix to not have much downtime.
Thanks for hinting out the tools, we will have a look into it!
The thing is, that it would be ideal to have it as a properly implemented function so that it is not in the risk of being changed in later versions for example.
I understand. It’s an interesting thought, but breaks a bit with our A/B ideology atm.
However, say you’re rolling back to the old partition, through an update, maybe something clever, like an update module using casync or similar could be a good idea?
Then the data already on the old partition would be taken into account, and you would save yourself the data transfer (if that is your concern?)
If not, a delta update would also help you save on the resource usage when rolling back to the old partition.
You could also make some sort of rollback update module I guess, but as soon as you start playing with the bootloader env yourself, Mender cannot longer guarantee that you’re not making a mistake of course.
