Mender Blog

Mender 2.0 beta: Application updates | Mender

Written by Admin | Apr 2, 2019 4:00:00 AM

Mender 2.0 beta is here and ready for you to try!

We are happy to see a further increase in community contributions with Mender 2.0! A big thank you to the contributors for investing your time in developing new features as well as everyone providing feedback and support! The Mender 2.0 beta release notes include all the contributor credits.

The focus for Mender 2.0 is support for Application updates, including package managers, file distributions and docker containers! The key features of Mender 2.0 beta are covered below, and you can see the detailed items in the Mender 2.0.0 beta 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 ARMv7 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.0 beta 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 beta

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

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.

Hosted Mender will be updated and fully compatible with the new Mender 2.0 beta client releases by mid-April.

Sign up and get your $120 free credit up to one year 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!

The Board Integrations category in 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, 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

Mender 2.0 beta has a couple known issues that will be addressed before the final release: