We are happy to announce the production releases of Mender 2.0.0 and 1.7.1!
The focus for Mender 2.0 is support for Application updates, with full control and customizability over how a software is installed. This makes Mender unique for providing both robust system- and application level updates and it is this combination that enables Mender to solve all your needs for OTA updates.
Targeted application-level updates, which can be just a few kilobytes in size (compared to potentially hundreds of megabytes for system-level updates), enables much lower bandwidth usage, faster updates and more frequent deployments.
The key features of Mender 2.0 are covered below, and you can see the detailed items in the Mender 2.0 release notes.
Support for application updates
Mender 2.0 introduces support for Update Modules, which makes Mender extensible to application updates and new use cases beyond dual A/B image updates.
An Update Module is an executable that extends the Mender client to support new types of software updates. Mender 2.0 comes with support for these new types of updates out-of-the-box:
- Packages (deb and rpm)
- Containers (docker)
- Files (directory copy/sync)
Check out the existing Update Modules at the new Mender Hub Update Modules forum category.
Technically, an Update Module implements one or more of the actions that the Mender client carries out when installing an Artifact payload. The core action all Update Modules must implement is the Install action, which implements how an Artifact payload is installed on the device. However, there are other actions that may be implemented depending on the desired functionality and use case for an Update Module, such as Rollback.
And yes, you can easily write your own Update Module to achieve your own custom OTA update use case! See how at the official documentation for Update Modules!
Mender as Debian packages
In order to make Mender easy to install and use with application-based updates, we will maintain a Debian package for the Mender client! With its support for ARMv6 (and newer) and Debian family OSes, it will work on most development boards using Debian, Ubuntu and Raspbian.
Check out the new documentation on installing the Mender client to see how easy it now is to install Mender!
Secondly, Mender is being packaged into official Debian repositories:
This means Mender will soon be available in official repositories of Debian, Ubuntu and Raspbian! We are looking for help from the Mender community to maintain these official packages -- so please email contact@mender.io if you have experience or interest in this!
Lower bandwidth use: LZMA compression
Mender 2.0 support LZMA as an alternative compression method in addition to the gzip. This is a fully community-contributed feature!
The table below summarizes a comparison done on a 1.6 GB root file system image:
| Algorithm | Size compressed (MB) | Decompression time (seconds) |
|---|---|---|
| gzip | 985 | 23 |
| lzma | 735 | 23 |
In this test the decompression time was the same, while LZMA produced a 25% smaller file than gzip. This should lead to some nice bandwidth savings when you are deploying updates!
gzip compression is still the default in Mender 2.0. Also note that Mender 2.0 introduces support for using no compression, which is suitable for lower-powered devices.
To start using LZMA or no compression, take a look at the documentation on Mender Artifact compression.
Releases and Artifact Payloads
Two new concepts -- Releases and Payloads -- are introduced with Mender 2.0. A release is simply a set of Mender Artifacts with the same Artifact Name.
The purpose of Releases is that you can build software for different types of hardware and transparently deploy the right software to the compatible hardware. In Mender this means that a Release contains Mender Artifacts with the same name but with different Device types compatible. When a device checks for updates, the Mender server will map its device type to the right Artifact in a Release.
Also note that you can now expand an Artifact to see the Payloads inside the Artifact. This can be a full root file system, or in the case of using Update Modules, it can be a package, container or any other Payload the Update Module supports!
Accept multiple pending devices at one time
If you connect devices in your lab and manually accept them before sending them out to the field, Mender 2.0 introduces a new timesaver to you: accept multiple devices with one click!
Show ungrouped devices
Not sure if you have assigned all your devices to a group during device registration?
Mender 2.0 introduces a new out-of-the-box "meta" group called "Ungrouped" devices:
mender-convert fully containerized
mender-convert, which makes it easy to support robust image updates on Debian family platforms, had its initial release in December 2018.
With Mender 2.0 it fully supports conversion from within the docker-mender-convert container, so almost no dependencies are required on the host system. Support for Raspberry Pi Zero has also been contributed! And of course, this new release of mender-convert supports Update Modules and comes with the out-of-the-box ones as well, so you can update packages, containers and more.
To get started with mender-convert, we recommend you first check if your board and OS is already supported in the Mender Hub Debian family integrations. Otherwise, you can follow the official Debian family documentation to integrate your board!
Dependencies updated
Mender 2.0 comes with its dependencies updated across the board, including libraries used in the client, server and UI. This ensures Mender's dependencies have received their latest security, performance and stability enhancements.
Deprecations and removal
Mender follows semantic versioning, so with Mender 2.0, some deprecated functionality has been removed.
Some of the important changes are highlighted below but we recommend you skim through the full Mender 2.0 release notes to ensure you are aware of any changes to functionality you are using.
Standalone mode argument changes
When using Mender in standalone mode, the Mender client is triggered from the command line rather than being connected to a Mender server.
In Mender 1.7 and earlier versions, you would install a new Mender Artifact by running mender -rootfs <URI>.
With Mender 2.0 and later, this argument has been changed to mender -install <URI> in order to make it more intuitive and align with the arguments used with Update Modules.
In addition, any state scripts are now also run in standalone mode, so all Mender installations can benefit from them! As part of this the -f argument, which used to force installation of Artifacts with state scripts without running them, has been removed because the state scripts are actually being run now.
If you are using Mender in standalone mode please make sure to adjust accordingly when upgrading to Mender 2.0.
State script retry configuration name changes
The configuration file of the Mender client, by default stored at /etc/mender/mender.conf, has two settings called StateScriptTimeoutSeconds and StateScriptRetryIntervalSeconds.
If you have any of these two settings in your Mender configuration, please be advised that their behavior has been swapped in Mender 2.0. This was how it was originally intended, but by mistake their name became confusing.
See the documentation on configuration options for more information.
Auth APIv1 removed
Mender 2.0 removed support for a deprecated auth APIv1 endpoint.
The API in question is used to manage the authentication status of devices. It is typically used by scripts to auto-accept devices that are pending in the Mender server.
These API paths are removed in Mender 2.0:
The replacement APIv2 path for both these is:
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.
Mender 1.7 supports both auth APIv1 and APIv2, so we recommend you migrate any usage to auth APIv2 in Mender 1.7 before upgrading to 2.0. Please see the Mender 1.7 release blog post for more information.
Mender Artifact format v1 removed
Mender Artifact format v2 was introduced as the default with Mender 1.1 in June 2017. Since we are introducing Mender Artifact format v3 in Mender 2.0, we decided to drop Mender Artifact format v1 in this release.
Unless you are using Mender 1.0 you should not be affected by this.
Try Mender 2.0
The documentation has a new 2.0 section that includes all the resources you need to get going. To test the new features, you can start with these pages:
Sign up for Hosted Mender, a secure Mender server we host for you, so you don’t have to spend time maintaining scalability, security, certificates, uptime, upgrades and compatibility of the Mender server. Simply point your Mender clients to the Hosted Mender server! It is inexpensive and priced very competitively with the cost of self-hosting a Mender server. You will also get a $120 free credit, which expires after one year.
Upgrade to Mender 2.0
If you are using Mender 2.0, follow the Mender 2.0 upgrade documentation to upgrade to Mender 2.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.7.x releases for 2.0.0).
Share your feedback
We are happy to continue to see your general feedback on Mender, be it positive or need for improvement, in the Mender Hub General Discussions forum. 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!
Known issues
All known issues from Mender 2.0.0 beta have been resolved.
However Mender 2.0.0 is released with some known issues:
- Preauthorizing devices using the UI does not work, please use the preauthorize API directly for now.
- 2.0.0 is not the default in any stable Yocto branch, because it is backwards incompatible. See the changelog for meta-mender/thud-v2019.05 for how to enable it. It will be the default in Yocto Project's "warrior" branch, but this branch is not released in meta-mender yet.
- In the 2.0 beta, the Mender client deb package was called "mender". Now it's called "mender-client", and will conflict with "mender", so if you have the 2.0 beta installed, you need to to uninstall it explicitly before installing the final 2.0 release.
Recent articles
How over-the-air (OTA) updates help emergency response teams
What’s hot in the open source and embedded community?
How to leverage over-the-air (OTA) updates with NVIDIA Microservices for Jetson
Learn more about Mender
Explore our Resource Center to discover more about how Mender empowers both you and your customers with secure and reliable over-the-air updates for IoT devices.
