Update failures have nothing to do with mount errors. Am running afoul of bootlimit (=1), and a crucial missing piece in mender docs: linux mainline MUST clear bootcount to signal successful boot, for u-boot, next boot, else:
I now do “fw_setenv bootcount 0” in rc.local and verify it is actually cleared.
but, next boot uboot: bootcount=2, Warning: Bootlimit (1) exceeded. Using altbootcmd, which swaps boot partition, effectively reverting update.
The desired event chain breaks between “fw_setenv bootcount 0” in rc.local and u-boot seeing bootcount as 2, despite clearing in linux mainline.
This is done by the Mender client when it marks the update as successful or when you run mender -commit if you are running in stand-alone mode. Manually clearing this is a hack and not recommended as it will interfere with the Mender state-machine.
It is alos mentioned in the docs for the stand-alone mode,
Do you mean that you do this on each boot or that you do this after each Mender update?
If you are trying to do tree reboots while trying to do an Mender update, that will definitely fail. Mender only expects to reboot once and anything else will be considered as a failure and it will roll-back.
re-org’ing so only one boot. rc.local (at firstboot, whether initial flash or booting new rootfs) does all package installation, configuration then replaces itself with normal rc.local for subsequent boots
thus, mender running during first and subsequent boots, no reboots unless watchdog, power, or mender managed. Thus, do not have to worry about post-update timing issues as mender client completes handshake with server.
If not private key is present on the device it will generate a new one, which eventually ends up in /var/lib/mender/mender-agent.pem. This is what above log means and this can take a while, minutes if your device is “slowish”.
Are you sure that the process exists?
You can generate a key pair and provision the device with it (just put the private.key it at /var/lib/mender/mender-agent.pem ),
Since mender appears to behave thusly (post install)
first start: log: generating keys, exit (process no exist)
wait indeterminate time
second start (manual). Key appears after some time,mender keeps running
So I need a reliable firstboot startup algorithm. This does not work (sleeps forever):