Mender Blog

Mender 1.2 beta: scripting support! | Mender

Written by Admin | Aug 9, 2017 4:00:00 AM

Mender 1.2.0 beta is here and ready for you to try out!

The key features are covered below below, and you can see the detailed items in the release notes in the documentation.

State scripts

There has beeen a lot of interest in the ability to run pre- and postinstall scripts, before and after the Mender Client writes the root file system. The most common use case is to do application data migration, for example if application data like a user profile is stored in an SQLite database and a new column need to be added before starting the new version of the application. However, there are a wide variety of use cases that are covered by pre- and postinstall scripts, as most Linux users are familiar with.

Mender 1.2 not only includes support for pre- and postinstall scripts, but more generally state scripts.

The nine states

State scripts are more general and useful than pre/postinstall scripts because they can be run between any state transition, not just (before/after) the install state.

In fact, Mender 1.2 support scripts to be run before and after nine different states are reached:

  • Idle: this is a state where no communication with the server is needed nor there is any update in progress
  • Sync: communication with the server is needed (currently while checking if there is an update for the given device and when inventory data is sent to server)
  • Download: there is an update for the given device and a new image is downloaded and written (i.e. streamed) to the passive rootfs partition
  • ArtifactInstall: swapping active and inactive partitions after the download and writing is completed
  • ArtifactReboot: after the update is installed we need to reboot the device to apply new image. The Enter action runs before the reboot; the Leave actions runs after.
  • ArtifactCommit: device is up and running after rebooting with the new image, the commit happens to make the update persisitent
  • ArtifactRollback: if the new update is broken and we need to go back to the previous one
  • ArtifactRollbackReboot: if we need to reboot device after performing rollback
  • ArtifactFailure: if any of the "Artifact" states are failing, the device is entering and executing this state

State scripts can either be run as we transition in to a state; Enter, or out from a state Leave.

If a script returns 0 Mender proceeds, but if it returns 1 the update is aborted and rolled back.

Example use cases

In addition to the standard pre/postinstall use cases, there are a number of interesting use cases that are enabled by this more general state scripting support:

  • Enable network: In order to save power and bandwidth, network connectivity may not be enabled by default. However, state scripts in Sync_Enter and Download_Enter can enable network connectivity (and it can optionally be disabled in corresponding Leave scripts).
  • Custom sanity checks: Mender already automatically rolls back an update if it can not reach the Mender Server after the update is applied, in order to ensure another update can be deployed. Scripts in ArtifactCommit_Enter can do additional sanity checks to make sure that the device and applications are working as expected. For example, is the UI application running and responding?
  • Wait for user confirmation: A script may integrate with a UI framework to show a pop-up to the end user of a display-connected device and only return 0 once the user selects "Update".

Using state scripts

The documentation for state scripts is not fully completed at the time of writing, so we will cover basic usage here. The scripts follow a naming convention to determine when they should be run:

<STATE_NAME>_<ACTION>_<ORDERING_NUMBER>_<OPTIONAL_DESCRIPTION>

For example, Download_Enter_05_wifi-driver and Download_Enter_10_ask-user would both run before the Download state, and the wifi-driver script would run before the ask-user script

The easiest way to have Mender run the state scripts is to create a new OpenEmbedded recipe that inherits mender-state-scripts and copies them into place in do_compile, using the ${MENDER_STATE_SCRIPTS_DIR} variable.

You can take a look at the example-state-scripts receipe to get started.

Raw flash support

Many Mender users have reached out and asked for support for raw flash - so they could use Mender on their raw flash devices. We are very happy to introduce official support for raw flash in Mender 1.2 - both NAND flash and SPI-NOR flash devices are supported!

To clarify what is meant by raw flash, take a look at the Flash memory types section.

During this process two more boards were added as reference boards for Mender, thus fully integrated with the CI system and supported:

To get started with your raw flash device, take a look at the Raw flash integration documentation.

There are some warnings about UBIFS while building for raw flash that can be safely ignored. Please see Known issues below for more information.

Try Mender 1.2.0 beta

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

Give 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 encoutered 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

The issues below are tracked and fixes are targeted for the 1.2.0 final release. So there is no need to report them, just be aware while testing the beta.
View full post