Extending the default "dual rootfs update" functionality of mender with additional images

On a linux system with unencrypted root filesystem, the kernel and device tree images can often simply be included in and booted from the “/boot” directory of the root filesystem. Mender supports this type of system very well, because the entire Linux system (kernel, device-tree, and root filesystem) are all contained in a single image.

Our boot scenario requires that the kernel and device-tree images be separate from the root filesystem, because the kernel itself (via the initramfs) mounts the encrypted filesystem, so it’s impossible to access the “/boot” directory of the root filesystem without running the kernel first. This means that Mender doesn’t just automatically upgrade the kernel/dt by virtue of their being included within the root filesystem.

At first, I thought that this problem could be addressed by simply adding an “ArtifactInstall_Leave” state script that additionally mounted the newly OTAed root filesystem and copying the kernel/dt from it’s “/boot” directory into our boot partition. The problem with that, however, is that our system intentionally does not provide the facilities to mount the newly installed encrypted filesystem from within the running firmware image (mounting the encryted filesystem can only be done from within the initramfs for security reasons).

Failing the first strategy, my next thought was that there should be a way to include both the encrypted root filesystem AND the unencrypted kernel/dts images in the same .mender image. My understanding after more careful reading the documentation however, is that Mender doesn’t actually allow one to simply add extra files into a standard rootfs upgrade image. It looks like it would allow me to define my own “Update Module” type, whose payload could just be a tar file containing the encrypted rootfs, unencrypted kernel, and unencrypted dtb. The problem I see with this approch is that it appears that I’d be completely on my own in terms of implementing the entire mender install procedure for this new payload type. I expect to have to implement the kernel/dtb part of the install, because that’s custom functionality, but it would be much better to be able to re-use Mender’s implemenation of the rootfs install/rollback.

Is there a way to implement the “Update Module” strategy described in the previous paragraph while still leveraging Mender’s built in support for dual rootfs updates? Is there a completely different strategy that I should be considering instead?

Hi @davidr ,

This Update Module implements the dual rootfs update (the same way that’s built into the Mender client): Root Filesystem Image v2

It contains a link to the module itself, it’s quite simple and should be a good starting point to customize: mender/rootfs-image-v2 at master · mendersoftware/mender · GitHub

Thanks. That’s definitely helpful (and I think it would have taken me quite a while to figure out that that is the implementation of the default dual rootfs update).

In that script, I see a conditional that says:
if [ "$(cat stream-next)" != "" ]; then echo "More than one file in payload" exit 1 fi

The documentation for the mender-artifact command implies to me that it’s only possible to have one payload in each *.mender file. Is it possible to have multiple payloads? If so, how would I do it with mender-artifact?


I am glad it helped a bit!

No, you can currently only have one payload, so I would recommend you package several files into a .tar file or something similar. :slight_smile:

I’m glad that my interpretation of the documentation is valid, but still wondering: if it’s only possible to have one file in the payload, then what is that conditional checking for?

The plan is to allow multiple payloads in future releases, so my guess would be it is there to make it easier to adjust / support when that happens.

1 Like

OK, Thanks for the insight!