You are browsing documentation for a version other than the latest stable release. Switch to the latest stable release, 1.2.

System requirements

If you would like assistance supporting your device and OS, please refer to the commercial board support offering.

Yocto Project

Although it is possible to compile and install Mender independently, we have optimized the installation experience for those who build their Linux images using Yocto Project.

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 release 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.

Other build systems

Mender has no official support for other build systems. However, by following the right steps, it is possible to adapt other build systems to Mender's needs. Please see this blog post for an example (note that some of Mender's needs may have changed since the blog post was made).

Device capacity

The client binaries, which are written in Go, are around 7 MiB in size.

Our physical reference device, the BeagleBone Black, comes with a 1 GHz ARM Cortex-A8 processor, with 512 MiB of RAM. Mender also has a virtual QEMU-based reference device using the vexpress-qemu machine type. We use both these devices in our continuous integration process so they are well supported.

Bootloader support

To support atomic rootfs rollback, Mender integrates with the bootloader of the device. Currently Mender supports U-Boot. See U-Boot integration for more information.

Kernel support

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.

If you run the Mender client in standalone mode, you can avoid this dependency by disabling Mender as a system service .

Partition layout

Please see Partition layout.

Correct clock

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.

Before the time is set properly, either by systemd or the RTC, the time will default to the Unix Epoch. Note that the Mender client connections will be rejected by the server until this situation is resolved.