# Committing an update when the device is offline after the reboot

**URL:** <https://hub.mender.io/t/committing-an-update-when-the-device-is-offline-after-the-reboot/8383>\
**Category:** General Discussions\
**Tags:** yocto, mender-client, update, commit\
**Created:** [November 11, 2026, 4:02pm UTC](https://hub.mender.io/t/committing-an-update-when-the-device-is-offline-after-the-reboot/8383 "2026-11-11T16:02:55Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![mroussin](https://avatars.discourse-cdn.com/v4/letter/m/ecccb3/32.png) [@mroussin](https://hub.mender.io/u/mroussin)\
**Post date:** [November 11, 2026, 4:02pm UTC](https://hub.mender.io/t/committing-an-update-when-the-device-is-offline-after-the-reboot/8383/1 "2026-11-11T16:02:55Z")

</div>

We run mender-update 5.2.0 (A/B rootfs with GRUB) on a fleet of Jetson devices, and we hit a gap in the update flow that we could not close with state scripts alone. We have a patch that fixes it for us, and before sending it upstream, I would like to check two things: is there already a supported way to do this that we missed, and if not, is a config option the right shape for it?

### Our use case

Our devices download and install updates while they are connected (in the depot, on-site WiFi). The user decides when to reboot, so we never reboot from Mender. Our `ArtifactReboot_Enter` script returns 21 until the user reboots, with `StateScriptRetryTimeoutSeconds` set to a year so the deployment can stay parked that long.

The problem is where that reboot happens. Very often the user reboots in the field, out of network range. The device comes up on the new slot, everything is healthy, and then the update is rolled back anyway.

The reason is the status report sent after `ArtifactVerifyReboot` and before `ArtifactCommit`. It uses retry then fail: the client retries it with backoff, and when the retries run out, it rolls back. On top of that, if the device is power-cycled while it is still retrying, the saved “after reboot” state is resumed down the rollback path. So a device that reboots away from the network loses every update, even though it can judge its own health locally.

Our health decision is already local. Our `ArtifactCommit_Enter` script waits for the application containers on the new slot to be running and healthy, and exits 1 (rollback) after 120 s otherwise. We do not need the server to approve the commit; we only need the server to be told the result once the device is back online.

### What we looked at with state scripts and config

As far as we can tell, none of these solve it, but please correct me if I am wrong:

- `ArtifactCommit_Enter`: never runs; the rollback is decided before it.
- `ArtifactReboot_Leave` Returning 21 until the network is back: this only delays the report. Devices can stay offline for days, and any reboot in that window is still uncommitted, so it rolls back.
- Raising `RetryPollCount` / `RetryPollIntervalSeconds`: same problem, the window gets longer, but a power cycle during it still ends in a rollback.
- Update Control Maps: they let us pause before the commit, but I did not find a way to make them skip the server round trip before the commit.
- Standalone mode (`mender-update install` then `mender-update commit`): works offline, but we lose managed deployments and would have to rebuild deployment tracking ourselves.

Is there a hook, update module feature, or deployment setting we missed?

### What we did

We added an `AllowOfflineCommit` option to `mender.conf`, off by default, so upstream behaviour does not change:

```json
{
    "AllowOfflineCommit": true
}

```

With the option on, the status report before the commit is sent the same way as the download, install and reboot reports already are:

- If the server answers “aborted”, the client still rolls back, exactly as today.
- Any other error (no network, timeout, server unreachable) goes on to `ArtifactCommit_Enter`, so the device decides through its state scripts and the update module.
- The final status report keeps its retries, so the server learns the outcome when the device comes back online.

The trade-off is explicit: with the option on, the server can no longer abort a deployment after the device has rebooted into it while offline. For us, that is the right call, but it is why we made it opt-in.

Would you accept `AllowOfflineCommit` as a `mender.conf` option? Or would you prefer another shape, for example, a per-deployment setting chosen on the server, or something the artifact declares?

Thanks!