We’re developing an embedded system that has a Linux device + other MCUs. When doing an update, it could happen that only the Linux device has to be updated (i.e. rootfs, Linux kernel, bootloader…), only the MCUs’ firmware, or both. Would that be that possible currently with Mender? I.e. to have one single artifact that is downloaded by the Mender client, and depending on its meta-data information to update each part of the system (via custom Update Modules).
There are the building blocks available, like the DFU Update Module as a blueprint for updating an MCU, plus the depends/provides mechanisms in the artifacts.
However, for more advanced use cases this might become complicated to manage. We are currently developing a solution that might fit those needs. It is not public yet, so if you are interested then please contact your Mender sales rep to figure out the details.
Thanks for the reply. We may be interested in such solution, I’ll raise this info internally.
I’d like to check that my understanding is correct, could you please confirm the following ideas?
- Currently it would be possible to create a single mender artifact that is composed of several payload files and managed by one custom Update Module, for example like this:
./mender-artifact write module-image \
-t $DEVICE_TYPE \
-o release-X.mender \
-T custom-update-module \
-n release-X-1.2.3 \
-f rootfs.tar.ext4 \
-f mcu-A-firmware \
-f mcu-B-firmware \
-f mcu-C-firmware \
- The custom Update Module would parse the mender artifact, and perform the needed actions to install it depending on the files contained in the artifact. It could happen that, for a certain release, some files are not included in the artifact because (e.g. the rootfs) they are not changed from the previous release.
Would the approach above be correct/feasible? Would it be possible to create a mender artifact that is parsed/handled simultaneously by multiple Update Modules depending on its content, so that the functionality is split into several Update Modules?
Yes, the approach 1) is technically possible. However it brings the challenge of having to handle each target device (and its possible errors and rollbacks) manually. Hence it brings, depending on the complexity of your system, a noticeable maintenance burden. You can probably keep it a bit simpler by always shipping the full suite of artifacts, and always flashing no matter the current version to guarantee a coherent state, but in any case its not optimal I think.
For 2), that is completely up to your Update Module logic. You can act depending on what files are there, what metadata is included, etc.pp.
Hence this is possible and technically feasible, but probably a bit involved. However, creating an artefact which is handled by multiple Update Modules is not possible.