I have a question about checking the current update state from Mender standalone mode. We are using Mender in our devices in strict standalone mode currently.
I’ve seen the mender command has some support for probing the current update state via subcommands commit and rollback, as they note: “Returns (2) if no update in progress.” However, this is not helpful when one only wants to check whether or not there currently is an update in progress. Simply running commit/rollback unconditionally is not an option, as this depends on whether the firmware is to accepted or not.
What is the idiomatic way to check if an update is in progress in Mender standalone mode? Or must we resort to state scripts for this?
Is another approach to interrogate u-boot’s persistent environment with fw_printenv and look at the status of the ‘upgrade_available’ variable? It seems to be set to “1” after an installation (and even before/after reboot) but before a commit or rollback has been issued. Seems like the 'mender_boot_part" and “mender_boot_part_hex” tell you which partition is currently active (also observed via ‘lsblk’) or will be active just after installation but before the device has been rebooted. Certainly, mender knows the state it’s in . . . it would be nice if an external application could find out as well. Perhaps using u-boot’s persistent environment is one (rather kludgy) approach to exposing this information?
Using U-Boot’s information is possible, but it’s not foolproof. If the bootloader rolls back, instead of Mender, then the environment will look like no update is in progress, but from Mender’s perspective, it still is, until you run rollback or commit (the latter of which will fail, but conclude the update). I think recording from state scripts is more robust, even though it’s more work.