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
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
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?
I’ve seen this thread: Mender 2.0 - How to get the update progress from standalone mender? but we’re not interested in the download progress, and D-Bus is not an option as far as I can see in Mender standalone mode. Is this correct?
Any help is appreciated, thanks in advance, best regards,
Your assumption is correct. Currently I’m afraid there is no other way than using state scripts and recording the state somewhere.
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
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.
Thanks all very much for the responses. We have used state scripts to solve this now.