Root Filesystem Image v2

Update Modules
1

Description

This module performs a full root filesystem updates on the device. The module was originally developed for testing purposes and it is published as a non-official alternative way of doing rootfs updates on devices with dual partition layout (A/B).

It supports rollback in the same way as the conventional root filesystem update: rolling back to the old partition on any unforeseen problem. See Mender Architecture documentation to learn more about this design.

Specification

A B
Module name rootfs-image-v2
Supports rollback yes
Requires restart yes
Artifact generation script no
Full operating system updater yes
Source code Update Module
Maintainer Community

Prepare the device

This section describes how to setup your target device, i.e. the device to be updated. This will also be referred to as the device environment.

All commands outlined in this section should be run in the device environment.

Prerequisites

This update module has the following prerequisites for the device environment:

Install the Update Module

Download the latest version of this Update Module by running:

mkdir -p /usr/share/mender/modules/v3 && wget -P /usr/share/mender/modules/v3 https://raw.githubusercontent.com/mendersoftware/mender/master/tests/rootfs-image-v2

Prepare the development environment on your workstation

This section describes how to set up your development environment on your workstation.

All commands outlined in this section should be run in the development environment.

Prerequisites

This Update Modules has the following prerequisites for the development environment:

Create Mender Artifacts

The Artifact can be generated using mender-artifact tool. To generate a rootfs-image-v2 Update Module Mender Artifact, you can use command:

ARTIFACT_NAME="my-update-1.0"
DEVICE_TYPE="my-device-type"
OUTPUT_PATH="my-update-1.0.mender"
IMAGE="rootfs.ext4"
mender-artifact write module-image -T rootfs-image-v2 -n ${ARTIFACT_NAME} -t ${DEVICE_TYPE} -o ${OUTPUT_PATH} -f ${IMAGE}
  • ARTIFACT_NAME - The name of the Mender Artifact
  • DEVICE_TYPE - The compatible device type of this Mender Artifact
  • OUTPUT_PATH - The path where to place the output Mender Artifact. This should always have a .mender suffix
  • IMAGE - The path to the rootfs image to be packaged in the Artifact

You can either deploy this Artifact in managed mode with the Mender server (upload it under Releases in the server UI) or by using the Mender client only in Standalone deployments.

Artifact technical details

The Mender Artifact used by this Update Module has the root filesystem image as the only payload.

The Mender Artifact contents will look like:

Mender artifact:
  Name: my-update-1.0
  Format: mender
  Version: 3
  Signature: no signature
  Compatible devices: '[my-device-type]'
  Provides group: 
  Depends on one of artifact(s): []
  Depends on one of group(s): []
  State scripts:

Updates:
    0:
    Type:   rootfs-image-v2
    Provides: Nothing
    Depends: Nothing
    Metadata: Nothing
    Files:
      name:     rootfs.ext4
      size:     0
      modified: 2019-04-15 11:59:24 +0200 CEST
      checksum: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
1 Like
2

hmm, this is confusing:

  • what is the difference from using mender-artifact write rootfs-image?
  • mender-artifact write module-image -h says that “This command is not meant to be used directly, but should rather be wrapped by an update module build command”
3

The former command creates a normal rootfs update, the latter creates an update meant for an update module. Since update modules are generic plugins, there is no one command that can be recommended. Instead the update module should come with its own artifact build command which uses the module-image command under the hood.

4

Hello @lluiscampos . I followed this document to get the full system update and I came to the end. But when I run the last command, I get an answer like this:

root@ubuntu:/home/robust2# ARTIFACT_NAME=“full-update-1.0”
root@ubuntu:/home/robust2# DEVICE_TYPE=“imx6ul-var-dart”
root@ubuntu:/home/robust2# OUTPUT_PATH=“full-update-1.0.mender”
root@ubuntu:/home/robust2# IMAGE=“rootfs.ext4”
root@ubuntu:/home/robust2# ./mender-artifact write module-image -T rootfs-image-v2 -n ${ARTIFACT_NAME} -t ${DEVICE_TYPE} -o ${OUTPUT_PATH} -f ${IMAGE}
writer: can not open data file: rootfs.ext4: open rootfs.ext4: no such file or directory

Finally I can’t generate artifact.
What is the reason of this ? What does the image mean? How do I fix this problem?

5

Hello again @mEK,

This Update Module requires a full filesystem image. If you have full Mender integration in your device (namely A/B filesystems), you can generate update images for your device the same way you created the first image: using Yocto project or mender-convert .

Then, once you have an image, you can specify the path with IMAGE=... for the Mender Artifact to include it.

6

Thank you for your quick and clear answer. First of all, what are the steps I need to follow for full mender integration? Where do you think I should start? Is meta-mender not enough to create an A / B root file system?

7

But how have you installed Mender in your device?

Your logs hint that you are using an NXP imx6 based board, so maybe you have followed a Board integration tutorial here on Mender Hub? If so, you have already yocto environment ready to create new images :slight_smile:

9

@lluiscampos @kacf I think there is an issue here with the current version of the U-boot utils on the Dunfell branch. Passing the variables into fw_setenv -s - seems to require the syntax var=value rather than var value. Interestingly the var value syntax seems to work directly from the command line (ie fw_setenv foo bar).

Of course the Grub version of these commands probably needs to be adapted to match but I’ve not looked into that.

Thoughts?
Drew

10

Yes, but I believe the client already does this. Check out this commit, and then this later followup. The command line is a bit different, because var and value are parsed by the shell, not by the command, and I believe it accepts this.

Grub has always used the = variant.

What problem are you seeing exactly?

11

Oh, never mind, I missed the context, this is about rootfs-image-v2. And I’ve seen your pull request. Then you’re right, this needs fixing. We are testing the rootfs-image-v2 module, but only using Grub, which seems to support both.

12

3 posts were split to a new topic: Root filesystem update module - extend by additional payload files

13

Is is possible to construct the artifact such that it updates the rootfs-image.version value? Right now, it’s setting rootfs-image.rootfs-image-v2.version. I’ve monkeyed around with different combinations of --software-filesystem and --software-name to no avail.

14

@seth It is not possible with an update module.

Let me explain,

rootfs-image.version is reserved for full rootfs update, with a command like mender-artifact write rootfs-image.... There you could specify --software-version and it will end up in the key rootfs-image.version.

However here we are using an update module, that happens to be named rootfs-image-v2 (which is the parameter in -T option) which produces a the key rootfs-image.rootfs-image-v2.version. With update modules, mender-artifact tool will always append the module name.

Does this make sense to you? It is an implementation detail and we could think about changing it. Can you elaborate your use case?

15

Hi Luis, thank you for your response. That makes sense. Setting --software-filesystem="" --software-name="rootfs-image" gets close, but there’s a preceding dot (.rootfs-image.version=...)

The use case would just be to replace the the rootfs updating facility in Mender with an update module, as is being done in this “rootfs-image-v2” example. This could be useful if the target device does not use one of Mender’s supported bootloader scenarios. However, the difference is purely cosmetic. I don’t think there’s any downside to having rootfs-image.custom-rootfs-update-module.version over rootfs-image.version.

I’ve read elsewhere on this forum that in the C++ rewrite of the client, the rootfs updater will become similar to an update module. Would this change allow replacing it’s behavior on systems that don’t follow a supported pattern?

16

Actually, it is possible with an Update Module, but you have to specify the Provides data manually. You can’t use the --software-... convenience options. This should work:

mender-artifact write module-image \
    --no-default-software-version \
    --no-default-clears-provides \
    --provides rootfs-image.version:VALUE \
    --clears-provides "rootfs-image.*"