What Is a Mender Update Module, How It Works and Why Use It?

In Mender taxonomy, an Update Module is essentially a method for deploying over-the-air (OTA) software updates with the advantage of customizability and flexibility at its core. See Two Ways to Update Embedded Devices Over-The-Air.

Before getting into Update Modules, let’s refresh what Mender Client and Mender Artifact are. Mender Client is a process that runs in user space on top of an embedded Linux operating system which talks to the Mender server and applies the update. The Mender client needs to be integrated with the device so it can install software updates to it. This integration also adds functionality to work with a Mender server such as provisioning, authentication, inventory monitoring and deployment reporting. When integrated, all images built for this device supports robust OTA updates. For a robust update process, Mender defines and uses a file format with .mender suffix, called Mender Artifact to handle additional metadata alongside the raw bits of the image file system namely, the Name of the software build, compatibility with device type, and checksum of the root file system for controllability during transit or storage.

There are two outputs when building an image for the target device:

• A disk image that can be flashed to device storage containing multiple partitions including the active and passive root filesystem as well as the persistent data partition.
• A Mender Artifact containing the rootfs filesystem image file that the Mender server can deploy to the provisioned device

What is a Mender Update Module? An Update Module is a piece of user-written code that defines how the Mender client installs an update to a device. They are customizable and can be written in any programming language, so it can be tailored to meet the specific needs of a device or environment. Mender comes with reference Update Modules for the most common application package types:

• Docker containers
• .deb packages
• .rpm packages
• .Files and directories

Figures below illustrate three distinct use case examples of Update Modules. Use case 1 deploys rootfs image file, container and file updates at system and application level and they can each be deployed independently of each other at different time intervals. OS level updates may be needed every 2-3 months whereas application level and certain file updates may require more frequent updates.

Use case 2, is another scenario where package updates using .rpm or .deb can be deployed independently of rootfs image file update.

Use case 3 illustrates rootfs image file, package and other custom updates for software and firmware deployment to peripheral components and/or devices such as microcontrollers (MCU), sensor processors, storage devices, cameras, etc.

How it works? In order to start using an Update Module, you need to create a Mender Artifact payload that contains a software type that the Update Module supports by using the mender-artifact utility. The diagram below shows an example of the main attributes and structure of a Mender Artifact file.

For example, the deb Update Module supports Debian packages (.deb files) where a Mender Artifact can be created with a Payload of type .deb by the following command:

ARTIFACT_NAME="my-update-1.0"
DEVICE_TYPE="my-device-type"
OUTPUT_PATH="my-update-1.0.mender"
PACKAGES="my-package-1.deb my-package-2.deb"
mender-artifact write module-image -T deb -n ${ARTIFACT_NAME} -t ${DEVICE_TYPE} -o ${OUTPUT_PATH} -f $(echo "$PACKAGES" | sed -e 's/ / -f /g')

When the new software is downloaded, the Mender Client will run the Update Module executable associated with this .deb type Payload. Then the Update Module is responsible for carrying out the steps needed to install the software of this type.

The most relevant states for developing a customized Update Module in the workflow are (with an example of .deb package update):

• ArtifactInstallstate should be used to install the update into its final destination. For example, an Update Module of type .deb would invoke the dpkg command to install any provided package files.
• ArtifactCommit state should be used to make the update permanent, in cases where it is still possible to roll back. The .deb Update Module would verify that the dpkg command succeeded and there are no obvious issues such as corrupted databases.
• ArtifactRollback state should be used to roll back to the previously known good state, normally by restoring some kind of backup. In the case of the .deb Update Module, this state can reinstall the older package versions directly using

Why use a Mender Update Module? As the advantages alongside disadvantages, are described in Method 2: Application updates applications are usually much smaller than the full system updates - so by only updating the application, the downtime and network usage during the update is kept to a minimum. So yes, one can update applications with a rootfs mechanism mentioned earlier in this post, but one would probably not do this frequently, and likely bundle some other things e.g. a linux security fix) that are perhaps updated 4-6 times per year. Then using rootfs updates to deploy weekly application changes only become inefficient use of resources.

Therefore, the combination of system and application level capabilities enable a set of flexible and powerful mechanisms to solve all OTA firmware and software update needs for the embedded IoT and connected device in the field. More frequent feature updates and application bug fixes can take advantage of targeted application-level deployments whereas security patches and OS level deployments that are less frequent (usually 2-3 months) can take advantage of system updates.

See Remotely update Raspberry Pi applications with Mender, for how to do a file update with a Raspberry Pi.