So I have a script that a run after deployment to setup a device. It changes the hostname, some other settings…etc. it then reboots the system…it looks like for some reason, it makes mender think that the boot was not a success. This is a script that starts at graphical heh.
I guess I am asking, how long does the device have to be on before a -commit happens?
In managed mode the commit will occur once the mender client is able to connect to the Mender server again after a past deployment.
You might be able to utilize state-scripts to make sure to wait for the commit, and as you have noticed a “reboot” during a deployment will mark is a failure.
Though I would not recommend making changes after a Mender deployment, and optimally you would do this offline, and it would have been contained in the deployment in the first place.
I do not understand.
Do I need to use these state scripts to deploy then?
I need to change things like hostname, the unique config for the device. I emailed mender, and they told me I have to do it myself, and then a few days ago I started reading about state-scripts.
Why would a commit depend on networking? I suppose if it breaks networking, that would be bad? I think it would be easier to test networking vs everything else on the device?
All I care about is that the device boots, and a script runs…after that…I can worry about if it will connect to a network.
Can I just do a mender -commit
I mean what happens if the device sits there, for hours before it gets reconnected to the internet?
It is important when you deploy an update that the update did not break connectivity to the Mender server, otherwise you can lock you self out of deploying OTA updates.
This is why the criteria exists where the mender client will mark the update complete once it is able to connect to the Mender server after booting the “new image”
If it is expected that there will be a large delay before the network is connected after installing an update then a pre-commit state script can be used to “retry later”. It cannot be delayed indefinitely though as the server will eventually declare the deployment as failed.
One suggestion would be to have the pre-commit hook enable the networking, allow the commit, and then use the post-commit hook to disable the networking.
How fast does mender try, and connect to the server after boot. If the system reboots before committing, what happens?
Do not have any specific number, but will try connecting as soon as the service is started.
If the system reboots before committing, what happens?
This is considered a “interrupted update” and the Mender client will roll-back the update and mark it as a failure.
I was reading here: https://docs.mender.io/2.0/architecture/overview
I am in a time crunch, and lets say I did not have time to explore the mender scripting system, but already wrote some scripts that check networking.
If I am not worried about switching back, can I run the command mender -commit
Will it still report to the server that it updated?
By the looks of this it should work by running mender -commit to get an successful update.
The big reason I am asking, is that it mentioned in standalone mode, but not network/server mode…