Aborting a deployment purposely stalled in the ArtifactReboot_Enter state

[kadler]

Hi all,

I’m looking to delay rootfs updates until the user power cycles their device. My approach is based on the Power loss section of the state scripts documentation.

Tip: Since a power loss in ArtifactReboot_Enter will not be marked as a failure, this enables the user to stall the daemon in ArtifactReboot_Enter state forever, and thus an install will only be installed on a power-cycle of the device.

I figured I’d create ArtifactReboot_Enter state script that either sleeps for days, or always returns 21 to retry later. This approach seems to work, but I noticed that if I abort the deployment from the Mender server, the Mender client continues executing the state script with either implementation.

Is there any way to get the Mender client to check on the status of, and abort, a deployment while waiting for the user to power cycle their device?

Thanks,
Kris

[kacf]

Yes, there is! You should look into the Update Control framework. You can set the device to pause either using the server or using DBus on the client. It can pause before the reboot indefinitely until a user reboots the device.

Your described approach with using ArtifactReboot_Enter won’t pause indefinitely, because the client will eventually time out the script, even if repeatedly returning 21. This is to prevent loops bricking the device. The DBus API has other ways to handle this though.

[kadler]

Thanks for the suggestion. It looks like the Update Control framework should work well for most update flows. If the user initiates reboot or shutdown, a hook can use the DBus API to tell Mender client to continue to ArtifactReboot. The only case I can think of where the use of a pause prior to ArtifactReboot will not work is if the user abruptly cuts power to the device – in that scenario, Mender client will rollback the update.

A related question – do you know when Mender client 3.3 will be released? I’d like to build pauses into deployments via Mender server, but I’m seeing failures related to issue MEN-5421 in versions 3.0 and 3.1, and unrelated failures in version 3.2, which may be related to problems described in this Mender Hub thread:

Mender keeps rolloing back after update

Im having the same Problem. Downgrading to version 3.1.0 solves the issue. This forces me to use mender-connect 1.2 which has a bug losing connection to the server quite often.

[kacf]

@kadler

Thanks for the suggestion. It looks like the Update Control framework should work well for most update flows. If the user initiates reboot or shutdown, a hook can use the DBus API to tell Mender client to continue to ArtifactReboot. The only case I can think of where the use of a pause prior to ArtifactReboot will not work is if the user abruptly cuts power to the device – in that scenario, Mender client will rollback the update.

That’s correct. You can use the Retry function on the server to mitigate that though. The device will have to re-download the artifact, but it will at least be automatic.

@kadler

A related question – do you know when Mender client 3.3 will be released? I’d like to build pauses into deployments via Mender server, but I’m seeing failures related to issue MEN-5421 in versions 3.0 and 3.1, and unrelated failures in version 3.2, which may be related to problems described in this Mender Hub thread:

3.3.0 was tagged today, as a matter of fact! There is still some work to make sure that Yocto, website, etc. is up to date, but it’s just a matter of a short time now.