# Using update module as a rootfs-image

**URL:** <https://hub.mender.io/t/using-update-module-as-a-rootfs-image/3288>\
**Category:** General Discussions\
**Created:** [March 2, 2021, 3:45pm UTC](https://hub.mender.io/t/using-update-module-as-a-rootfs-image/3288 "2021-03-02T15:45:58Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![hacpa](https://avatars.discourse-cdn.com/v4/letter/h/a9adbd/32.png) [@hacpa](https://hub.mender.io/u/hacpa)\
**Post date:** [March 2, 2021, 3:45pm UTC](https://hub.mender.io/t/using-update-module-as-a-rootfs-image/3288/1 "2021-03-02T15:45:58Z")

</div>

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](https://hub.mender.io/t/root-filesystem-image-v2/402)

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?

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [March 2, 2021, 4:58pm UTC](https://hub.mender.io/t/using-update-module-as-a-rootfs-image/3288/2 "2021-03-02T16:58:38Z")

</div>

Yes! 🙂 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:

```auto
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.

---

<div class="post-metadata">

**Author:** ![hacpa](https://avatars.discourse-cdn.com/v4/letter/h/a9adbd/32.png) [@hacpa](https://hub.mender.io/u/hacpa)\
**Post date:** [March 2, 2021, 9:22pm UTC](https://hub.mender.io/t/using-update-module-as-a-rootfs-image/3288/3 "2021-03-02T21:22:22Z")

</div>

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

```auto
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:

```auto
    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”:

```auto
    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. 🙂

---

<div class="post-metadata">

**Author:** ![hacpa](https://avatars.discourse-cdn.com/v4/letter/h/a9adbd/32.png) [@hacpa](https://hub.mender.io/u/hacpa)\
**Post date:** [March 4, 2021, 12:28am UTC](https://hub.mender.io/t/using-update-module-as-a-rootfs-image/3288/4 "2021-03-04T00:28:41Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![hacpa](https://avatars.discourse-cdn.com/v4/letter/h/a9adbd/32.png) [@hacpa](https://hub.mender.io/u/hacpa)\
**Post date:** [March 8, 2021, 2:55pm UTC](https://hub.mender.io/t/using-update-module-as-a-rootfs-image/3288/5 "2021-03-08T14:55:32Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [March 9, 2021, 9:59am UTC](https://hub.mender.io/t/using-update-module-as-a-rootfs-image/3288/6 "2021-03-09T09:59:31Z")

</div>

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](https://tracker.mender.io/browse/MEN-2582). 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.
