Forcing an update to a device that already has the same release


Is there a way to force push an update to a device that already has that same deployment on it? For instance I have a unit I updated last week to version “1.2.0” and it had a weird failure so I want to update it clean again to the same “1.2.0” version. The only thing I have figured out to let me do this is to downgrade it to “1.1.0” and then upgrade it to “1.2.0” which is not ideal since it takes way longer and sometimes we have state scripts that may not handle downgrades very well.


This should be possible, but not with the exact same artifact.

But if you create an Artifact with the same payload, and a different name, this should work just fine :slight_smile:

Yes, that is possible but that’s also a bunch of extra work to build another artifact and upload it with the way our build system is setup.

I don’t see a technical reason why what I am looking to do should not be possible or would cause problems for our use case.

Hi @kevlan, understood but with the current implementation there is no way to do this. The server will detect that you are already running the version in question and call the deployment complete.

I have, in some demo cases, manually edited the /etc/mender/artifact_info file on a target to fake it out. Basically, edit that file, change the currently installed artifact name and rerun your deployment. I don’t recommend that as an ongoing thing but for a one-off fix, it may get you past this issue.


Thanks @drewmoseley! I will give the editing of the artifact_info a try next time we need to do this.

Hi @kevlan

There is also the possibility to use the modify command in the Mender Artfiact tool:

This will take an existing artifact, and change its name to whatever is desired :slight_smile:

Note that this will not work on Mender 2.0 and later unless the device is freshly installed. Once the first Artifact is installed, the name is stored in the database, not in /etc/mender/artifact_info. There is unfortunately no convenient way to change this database at the moment, so oleorhagen’s suggestion may be more appropriate in that case.

Thanks for the clarification @kacf. I thought that was going to become the case at some point but it still worked for me. I guess I was always running on freshly installed systems.