Mender blog

Mender 1.7 released: Raspbian and broader Linux support

We are happy to announce the production releases Mender 1.7.0 and 1.6.1!

The key features of Mender 1.7 are covered below, and you can see the detailed items in the release notes of Mender 1.7.0 and Mender 1.6.1.

We are happy to see an increase in community contributions with Mender 1.7! A big thank you to the contributors for investing your time in developing new features as well as everyone providing feedback and support! To give due credit, the changelog for Mender 1.7 and later includes contributor statistics.

The focus for Mender 1.7 is to make Linux support much easier, including binary Linux distributions! The key features of Mender 1.7 are covered below, and you can see the detailed items in the Mender 1.7.0 release notes.

mender-convert: Binary integration of Mender

Imagine you are working on an exciting new IoT product and getting ready for release. The release date is rapidly approaching and of course there are outstanding issues in the device software. What if you could release a basic version of the software and do an over-the-air update when the product reaches your customers -- which would buy you 4 more months?

There is just one problem: there is no time to start working on integrating a robust over-the-air update manager either...

This is why a new tool mender-convert joins the Mender family! With mender-convert you can take an existing Linux disk image and convert it into a disk image with dual A/B rootfs OTA update capability using Mender! Provision your devices with this disk image, and they can be remotely updated with Mender.

This conversion all happens on the binary image level - there is no need to integrate with a bootloader or rebuild any of your device software! After provisioning with the converted image, you can build Mender Artifacts with the exact same process.

Raspbian

mender-convert is part of a larger goal of broadening Mender to all Linux distributions and making OTA updates available to everyone. This initial release works on Raspberry Pi 3 and BeagleBone Black, both with official distributions (Raspbian and Debian, respectively). It will be expanded and tested on a broader set of boards and distributions; as always testing and contributions are very welcome!

To make testing easy, a docker container can be used to carry out the conversion process. If you have a Raspberry Pi 3, you can test it all out in the Mender Hub topic on Raspbian with Mender.

The official documentation also has a new section on Building a Mender Debian image to get started, or take a look at the mender-convert GitHub repository.

As with all the tools of Mender, mender-convert is licensed under the permissive Apache License v2.

Yocto Project thud (2.6) support

meta-mender has a brand new thud branch, so you can integrate Mender with this newest stable release of the Yocto Project!

Automated Mender integration as default in thud

Mender 1.6 and Yocto Project's sumo branch introduced support for automatic integration for most ARM-based devices.

With the new thud branch in meta-mender, this automated integration using GRUB and UEFI branch is now the default. This removes the need to integrate Mender into most ARM-based devices!

If you already have Mender integrated and want to continue to use your direct UBoot integration with thud, add the following configuration to local.conf:

MENDER_FEATURES_ENABLE_append = " mender-uboot mender-image-sd"
MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"

Stable partition identifiers with PARTUUID support

In some cases the path to device partitions can change depending on storage type (e.g. SD card, eMMC, USB) as well as Linux kernel version and configuration. This has created issues because Mender needs to reference which partitions on the device it should update.

Mender 1.7 resolves this issue with support for using PARTUUID to reference partitions. Please note that this is supported on integrations where GRUB is used as the bootloader (either x86 or the new GRUB and UEFI ARM integration covered above).

Auth APIv2: Simplified device authorization

Mender 1.6 and earlier had two services responsible for authorizing devices, with slightly different purposes, deviceauth and deviceadm; they were meant to synchronize authorization data. Unfortunately, this lead to confusion and several bugs in the authorization state of devices, in particular when a device was "reflashed" with a new key (but same identity).

To address the issues surrounding device authorization, we are happy to announce that Mender 1.7 only has one service responsible for this: deviceauth. As part of this overall simplification, a new management API is introduced for device authentication, so this service is moving from APIv1 to APIv2.

The Mender UI is also updated to take advantage of this simplified API, so it will be easier to understand and change the authorization states of devices!

Deprecation of auth APIv1

Mender 1.7 will support both auth APIv1 and APIv2, but please migrate to APIv2, as support for APIv1 will be removed in the next release of Mender and Hosted Mender in Q1 2019. Note that this only affects the device authentication management APIs, typically where you would use a script to accept/reject devices.

All other management API endpoints will remain on APIv1. The device APIs will not change as part of this either, so devices will still communicate with the server using the same API and do not need to be updated.

UI scalability improvements

As Mender users keep scaling up their infrastructure, the Mender UI is receiving improvements to handle larger environments.

Artifact selector

Scaling not only relates to the number of devices, but also the number of Artifacts. Mender 1.7 introduces autocomplete for the Artifact name when you create deployments:

Artifact selector autocomplete

Filtering finished deployments

Managing larger amounts of deployments also becomes easier with Mender 1.7! You can now fitler finished deployments based on time or device group:

Finished deployments filtering

Retry deployment

When you create a deployment and one or more devices in it fails to update, the Mender client automatically performs a rollback so your device continues to be operational. However, in some cases the failure is intermittent (e.g. unreliable network), so you might want to retry the deployment later:

Retry deployment

This new feature will create a new deployment with the same Artifact and Devices being part of it. Note that devices that are already on this Artifact, e.g. since they were successfully updated in the previous deployment, will skip the deployment; Mender never updates devices that are on the same Artifact that is being deployed.

Mender client usability improvements

Several general usability improvements made it into Mender 1.7!

The Mender client now supports two locations for mender.conf:

  • /etc/mender/mender.conf
  • /var/lib/mender.conf

Both of these can be present, in which case the Mender client will load /var/lib/mender.conf first, then override any settings with what is in /etc/mender/mender.conf. As the former is normally backed by a persistent data partition, this is very convenient to specify any settings that you want to "survive" across updates. Examples include TenantToken (mainly for Hosted Mender) or polling intervals which could be different on different sets of devices. See the configuration file documentation for more information.

Note that meta-mender support for this feature is still under development, but the Mender client supports it.

Also notable, new device inventory for os, rootfs type and and bootloader integration type is available out of the box!

Device inventory

Try Mender 1.7

The documentation has a new 1.7 section that includes all the resources you need to get going. To test the new features, you can start with these pages:

Upgrading to Mender 1.7

If you are using Mender 1.6, follow the Mender 1.7 upgrade documentation to upgrade to Mender 1.7.0.

It will likely work to use the same document to upgrade older releases of Mender as well, but please note that the official and tested upgrade path is always from the previous minor or patch release (i.e. 1.6.x releases for 1.7.0).

Sign up for Hosted Mender: now free for up to one year!

Hosted Mender is a secure Mender server we host for you, so you do not have to spend time maintaining scalability, security, certificates, uptime, upgrades and compatibility of the Mender server. Simply point your Mender clients to our server! It is inexpensive and priced very competitively with the cost of self-hosting a Mender server.

To better support testing and evaluation, we just introduced an increase and extension to the free credit! You can now use Hosted Mender for free for up to one year or $120 value (whichever comes first)!

Hosted Mender is already updated and fully compatible with the new Mender 1.7 client releases.

Sign up and get your $120 free credit for Hosted Mender today.

Support for your board

If you are getting started with OTA updates or do not have time to integrate the Mender client with your board, there are several resources available to you!

Mender Hub is a dedicated place to contribute, reuse and maintain Mender board integrations.

We are also happy to help with professional services to enable verified Mender support for your board!

Share your feedback

We are happy to continue to see your general feedback on Mender, be it positive or need for improvement, on the Mender mailing list. Your continued feedback ensures Mender will meet your needs even better in the future!

If you believe you have encountered a bug, please submit your report at the Mender JIRA issue tracker.

We hope you enjoy the new features and are looking forward to hearing from you!

Recent articles

The scope of EU Cyber Resilience Act (CRA) compliance

The scope of EU Cyber Resilience Act (CRA) compliance

Explore the scope of the EU Cyber Resilience Act (CRA). Learn about the CRA's scope, and why secure OTA updates are essential for compliance.
An overview of EU Cyber Resilience Act (CRA) compliance

An overview of EU Cyber Resilience Act (CRA) compliance

Learn how the EU Cyber Resilience Act (CRA) enforces stringent cybersecurity requirements for PDEs. Explore compliance essentials in part 1 of a 4-part series.
Challenges in complying with the EU Cyber Resilience Act (CRA)

Challenges in complying with the EU Cyber Resilience Act (CRA)

Discover how manufacturers can achieve Cyber Resilience Act (CRA) compliance by tackling secure updates, SBOM management, and vulnerability tracking with robust OTA solutions.
View more articles

Learn why leading companies choose Mender

Discover how Mender empowers both you and your customers with secure and reliable over-the-air updates for IoT devices. Focus on your product, and benefit from specialized OTA expertise and best practices.

 
sales-pipeline_295756365