Simple standalone update procedure / Manual rollback possible?

General Discussions
1

Hi everyone,

I am integrating mender 1.7 (with rocko meta-layer) in standalone mode on my devices. Due to very limited time, I am looking for the simplest - but robust - way of doing.
The main constraint is that devices may reboot at any time (no control over it). There is no network connection but there is a protocol to send files and the possibility to execute bash scripts onto devices.

So far, I set up the following procedure:

  1. Artifact is embedded into an installation bash script and uploaded to device /data partition ;
  2. Script executes and extracts artifact when successfully uploaded ;
  3. Script triggers deployment (mender –rootfs <artifact_path>) ;
  4. Script triggers reboot on successful deployment ;
  5. Last init script calls automatically mender –commit.

Explanation of 5.: There is no automated way to check if the version is sane yet, it has to be done manually through some interactions with the device, and it may reboot spontaneously during the process… that is why I chose to commit automatically the deployment.
The obvious problem is that if we find that the version does not work properly, we cannot rollback…

=> Is there a clean way to force a rollback to passive partition ? (like setting some u-boot env variables?)
=> Or if I don’t call mender -commit and it reboots, can I perform a ‘retry’ on updated partition ? (could be the same logic)

2

one option is to use “fw_printenv” and “fw_setenv” userspace tools to change
“mender_boot_part” and “mender_boot_part_hex” uboot variables, make sure to change both to same alternate value

3

Thank you, I initially thought that it was not a clean way, one that put mender in an corrupted state but after trying it seems to do the trick transparently !
I could embed on my devices a script which parses current part number, set both mender_boot_part and mender_boot_part_hex then reboot.

Of course, I still think that automatically committing updates is arguable, I should probably perform a sanity check before that.
According to state scripts documentation, it seems that it would have addressed most of my issues, no ? They are not managed in standalone mode in 1.7. Would it be possible to use mender as a daemon even without network connection ?

4

With Mender version 2.0.0 and onward it will execute state-scripts in standalone mode as well.

But the concept of state scripts is really only useful when you are running in managed mode, in standalone mode you have some kind of script that runs mender -commit just do the necessary sanity checks in the same script before executing the mender -commit, on failure reboot which will trigger an rollback