Using update module as a rootfs-image

General Discussions
1

Let’s say you are using an update module as your rootfs instead of the bundled “rootfs-image” type. An example would be this one:
Root Filesystem Image v2

When an artifact of this type is installed, the inventory for the device shows a blank “rootfs-image” field. The “rootfs-image-v2” value appears under “update_modules” instead. This is with a Mender server 2.3.1. This issue is not very serious, as it’s just a display issue, but see my next point below.

The issue becomes more evident with Mender 2.6 and the new “Provides” metadata feature for differentiating app versions vs rootfs version. Indeed, a true “rootfs-image” artifact provides “rootfs-image.version”, while a “rootfs-image-v2” artifact provides “rootfs-image.rootfs-image-v2.version”. Furthermore, it only clears “rootfs-image.rootfs-image-v2.*”, NOT “rootfs-image.*” (while I did not try an upgrade in these conditions, I assume this means the “Provides” of other apps installed on the rootfs are not cleared). While building with Yocto and meta-mender on branch dunfell, there is currently no way to change the “Provides” metadata from “rootfs-image.rootfs-image-v2.version” to “rootfs-image.version”. You can change the app name from “rootfs-image-v2” to something else, but you can’t get to a point where the “Provides” becomes “rootfs-image.version” (although you can manually add that string to the “Provides” yourself, I am experimenting with this at the moment).

These might sound like 2 different issues, but they have a common theme: currently, there is no way to cause an update module to fully behave like a rootfs. Any clue how this might be addressed?

2

Yes! :slight_smile: Part of the problem is that rootfs-image-v2 is not an officially supported Update Module, just an example, for testing purposes, so it doesn’t come with an Artifact generator. And indeed it’s not the Update Module which needs to change, it’s the Artifact generator. If it were written, it should be written like this:

mender-artifact write module-image \
    -T rootfs-image-v2 \
    --no-default-software-version \
    --software-filesystem rootfs-image \
    --software-version <NAME> \
    --clears-provides 'rootfs-image.*' \
    --clears-provides artifact_group \
    --clears-provides rootfs_image_checksum \
    <OTHER_OPTIONS>

(The last two --clears-provides options are historical and are just to match a rootfs-image Artifact. You may not need them in your setup.)

It’s a long line, but that’s why we promote generators as the way to make Artifacts. Rootfs-image Update Modules, even custom ones, are considered more advanced than simple file updaters, that’s why the defaults are more optimized for simple file updaters, and rootfs updaters need to be a bit more custom.

One flag which I see could make sense is one which removes the middle part in rootfs-image.rootfs-image-v2.version. This would be a lot shorter than what I wrote above. But what I wrote will also do the job.

2 Likes
3

Yes, this is perfect. I was working with a command line that ended up looking like this:

mender-artifact write module-image \
    -T rootfs-image-v2 \
   --provides rootfs-image.version:${MENDER_ARTIFACT_NAME} \
   --clears-provides rootfs-image.* \
   <OTHER_OPTIONS>

But this ends up with 2 full sets of provides and clears provides:

    Provides:
        rootfs-image.rootfs-image-v2.version: dev
        rootfs-image.version: dev
    Depends: Nothing
    Clears Provides: ["rootfs-image.*", "rootfs-image.rootfs-image-v2.*"]

Your version is better, as it leaves the artifact looking identical to a “rootfs-image”:

    Provides:
        rootfs-image.version: dev
    Depends: Nothing
    Clears Provides: ["rootfs-image.*", "artifact_group", "rootfs_image_checksum"]

This does not resolve the first issue (display issue on Mender web), but that’s OK, the second issue is the one I was really interested in. :slight_smile:

1 Like
4

I stand corrected: with a Mender server 2.6.0, that “rootfs-image” field is now moved to the new “Installed software” section, which correctly picks up an update module artifact that was created using the flags proposed by @kacf and puts it in that section. Success!

Edit: OK, so this works when updating an existing device with a Mender artifact that includes these provides. However, if you flash a blank device with the *.uefiimg that is produced by the same Yocto build, there are NO provides on the resulting device. None. Just an artifact name. So, the “Installed software” field does not show up on Mender web for this device. It looks like the build process does not add the provides to the *.uefiimg, but only to the *.mender. Should I create a new thread for this?

5

Sorry to self-bump, but I think my edit about the *.uefiimg not containing any provides might have been lost in the chatter. I will add that this can be seen with the Mender demo as well: a freshly spun demo (also based on dunfell) does not show any provides on the website.

@kacf , your input is greatly appreciated!

6

You’re right, it was lost!

The issue you’re describing is in fact a known issue, and will happen exactly once to every device. There is a deep rooted reason for this (it’s also why binary-delta updates can not be performed as the very first update), tracked in this ticket. Unfortunately I can’t give an estimate for when this will be solved, but the issue has come up in several situations lately, so I hope it will receive some attention soon.

1 Like