Factory reset: Re-deploy last deployed software

General Discussions
1

I found this old discussion and am wondering if there are any updates in terms of out-of-the-box support for factory reset.

A couple of the hurdles to getting a fully working factory reset feature:

  • Preserving the auth key that has already been accepted. I’ve rolled my own solution by saving /var/lib/mender/mender-agent.pem to a U-boot env variable and restoring when booting up in a factory reseted state. Any better way I should be solving this problem?
  • Re-deploying all the same software and config that had been deployed to the device just prior to the factory reset. I don’t have solution for this. Does Mender provide anything to help?
  • Initiate a factory reset as a result of a config change. We use the Config Module and would like to able to start the factory reset when a certain config value changes (for example the org ID that the device is associated with)

Here is my factory-reset.sh for refrence:

#!/bin/sh

set -eo pipefail

SSD_DRIVE=/dev/nvme0n1
MENDER_AUTH_KEY_FILE=/var/lib/mender/mender-agent.pem

if [ "$1" != "--force" ]; then
    echo "This script will wipe the SSD drive ${SSD_DRIVE} and reboot the system."
    echo "Please ensure you have backed up any important data before proceeding."
    echo "To proceed, run this script with the --force option."
    exit 1
fi

if [ -e "${MENDER_AUTH_KEY_FILE}" ]; then
    echo "Preserving Mender auth key in U-Boot environment variable"
    fw_setenv -- mender_auth_key "$(cat ${MENDER_AUTH_KEY_FILE})"
fi

echo "Wiping SSD drive ${SSD_DRIVE}..."
wipefs --force --all ${SSD_DRIVE}
echo "Rebooting. SSD will be initialized on next boot."
reboot

And restore-mender-auth-key.sh:

#!/bin/sh

set -eo pipefail

MENDER_AUTH_KEY_FILE=/var/lib/mender/mender-agent.pem

if [ -e "${MENDER_AUTH_KEY_FILE}" ]; then
    echo "Mender auth key file already exists."
    exit
fi

mender_auth_key="$(fw_printenv --no-header mender_auth_key || true)"
if [ -z "${mender_auth_key}" ]; then
    echo "WARNING: No Mender auth key found in U-Boot environment. mender-client will generate a new one which must be accepted through the Mender Dashboard." >&2
    exit
fi

echo "Restoring Mender auth key from U-Boot environment"
echo "${mender_auth_key}" > "${MENDER_AUTH_KEY_FILE}"

And systemd oneshot service:

[Unit]
Description=Restore Mender Auth Key
Before=mender-client.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/restore-mender-auth-key.sh

[Install]
WantedBy=mender-client.service
2

The “Rest Device Deployment History” button seems to be the way to get Mender to re-deploy everything prior to the factory reset:

image
image1295×1018 63.6 KB

But I have two questions:

  1. This doesn’t seem to trigger a re-deploy of the device configuration. Should it? If not, what’s the right way to do this?
  2. How do I do the equivalent of “Rest Device Deployment History” with the API?
3

I should clarify question 1 above: I know a manual solution which is to:

  1. Go to the Configuration tab
  2. Click Edit (and suddenly see all the configuration that I expect to be on the device)
  3. Click “Save and apply to device”

But I would like to automate this.

4

Hola @tbraunjones,

In fact quite interesting workflow. I would claim I am not aware of any official “factory reset”.

The mender-agent.pem gets autogenerated in case there is no pem file available already in the device, but you can just inject another one and then point it from the mender.conf file as well. If you are in the enterprise plan, I would even recommend the usage of mTLS workflows as you may rely in certificates instead of having to be prompted to accept the device again when back online.

The reset button just removes the device from the queue and cleans the history of the device, it doesn’t re-apply all the past deployments.

For getting a set of new deployments you may need to develop your own logic here. Or the other approach is to rely on Dynamic Groups and then let the device to report to the server as a new brand device instead. If that is the case, maybe it will get the deployments made for Dynamic Groups where this device meets the filtering criteria.

For the config add-on, you can gather the reported JSON from the API and then submit a new change if that makes sense to you:

Retrieval: Mender API docs
Set: Mender API docs

Let me know if this makes sense

Best regards,
Luis

5

That’s not what I observed. What I see is the behavior that I want: essentially the device assumes it has not received any artifacts and starts downloading and applying each of them them in the order of the original deployments. In our case some of those live on the eMMC so they actually survive a factory reset of the SSD, but totally fine for them to be reinstalled.

So I just need to automate whatever the “Rest Device Deployment History” UI button is doing.

Thanks, makes sense. I’ll give this a try.