Mender's meta layer, meta-mender, has several branches that map to given releases of the Yocto Project. However, note that Mender is tested and maintained against the latest LTS branch of the Yocto Project only.
Older branches for the Yocto Project are still kept in meta-mender, but they might not work seamlessly as they are not continuously tested by Mender. If you need support for older branches we recommend subscribing to Mender commercial software support.
For compatibility reasons, not all branches for the Yocto Project install the latest client by
default. To make sure the latest client is installed, and you have access to all the latest
features, see the
PREFERRED_VERSION setting when configuring the
The client binaries are about 7 MB in size, or about 4 MB when debug symbols are
stripped (using the
strip tool). This includes most of the dependencies for
the client, such as the http, TLS, and JSON libraries.
The client depends on the LZMA library for Artifact compression, which is present in most Linux distributions, including those based on the Yocto Project.
While Mender itself does not have any specific kernel requirements beyond what a normal Linux kernel provides, it relies on systemd, which does have one such requirement: The
CONFIG_FHANDLE feature must be enabled in the kernel. The symptom if this feature is unavailable is that systemd hangs during boot looking for device files.
In order to support robust rollback, Mender requires the device to have a certain partition layout. At least four different partitions are needed:
Mender marks one of the root filesystem partitions as active, making the partition the boot target. The other, inactive partition, holds the previous root file system update. The client may either overwrite the inactive partition on a new update or roll back if the active partition does not boot. On a successful update, the partitions swaps roles.
The persistent data partition stores data requiring preservation through system updates.
The following figure illustrates an example partition layout:
Certificate verification requires the device clock to be running correctly at all times. Make sure to either have a reliable clock or use network time synchronization. Note that the default setup of systemd will use network time synchronization to maintain the clock in a running system. This may take a few minutes to stabilize on system boot so it is possible to have a few connection rejections from the server until this process is complete and the time is correct. Please see certificate troubleshooting for more information about the symptoms of this issue.
If your device does not have an active internet connection, then systemd will be unable to configure the system time as it will be unable to connect to the network time servers. In this case you will need to arrange other methods to set a proper system time. Many standard Linux features can be used for this. If your system includes a real-time clock chip, that will maintain the time across power down situations and the network connectivity needs of systemd will only be relevant on the system boots before the RTC is properly initialized.
Note that on startup, the system initializes the time to the Unix Epoch, before either systemd or the RTC corrects it, which implies that the server rejects all incoming TLS connections from the client until this happens.
Mender has official support for the Yocto build system and binary OS images based on the Debian family. It is possible to adapt to other build systems. Please see this community post for a concrete description.
For help from the community, as well as links to board integrations, visit Mender Hub.
Found errors? Think you can improve this documentation? Simply click the Edit link at the top of the page, and then the icon on Github to submit changes.
© 2021 Northern.tech AS