The OS image is independent of the modem_type, therefore device A and B can receive the same OS image. However, the installed modems are different and therefore device A should only receive an update module artifact that comes with firmware for a modem of type some_modem_EU while device B should only receive artifacts targeted at some_modem_AF.
My first idea was to add the modem type to the device inventory (modem_type=some_modem_XY). Then I could add a “depends” information into the metadata of the update module artifact. Like this hosted mender would then be able to filter the various update module modem firmware artifacts and the user could only select the artifacts that are applicable to the chosen device.
Is such an approach possible? Or are there other solutions to deal with that use case?
is it possible at all to avoid the fragmentation all together with combination of kernel modules/udev/systemd to probe and upload its firmware based upon what is discovered at runtime? Obviously this highly depends on your setup, and bus’s being used etc.
Theoretically we could create one big artifact that contains all different variants of modem firmware and choose the right one at runtime. However, the modem firmware is quite big (about 100Mb per modem) and therefore this is not desirable. Another possibility would be to load the appropriate firmware from e.g. a blob store or apt repository (also at runtime).
wow, that’s seems a very a large blob of firmware, is it a single binary or is it an archive that contains irrelevant data? could it be suboptimal? does it need debug sections stripping from it? can it be compressed?
also at 100MB, is it definitely “firmware” rather than a userspace executable? if its the latter, might be worth checking what its written in, just in-case its a higher-level language that compiles a runtime into it. You may be able to recompile it without the runtime embedded in it and provide the runtime as a shared resource between the two modem exes.
What I would do would be to use different device_types and instead build OS images that support both types. See the MENDER_DEVICE_TYPES_COMPATIBLE variable. Then you can build modem updates that only support one of the types and this will be automatically selected.
@dellgreen: The firmware blobs are already stripped and compressed. Unfortunately further improvements are not under our control. The best would be if the modem vendor could ship a modem firmware that is applicable for all regional variants of the modem. But unfortunately this is not the case.
@kacf: Your approach seems to be a good solution. I double checked that I can even change the device_type of an already existing device. At least with recent versions of Mender client this seems to work fine. In order to keep the factory setup simple, we could then do a solution that comes with one single image for all device variants and a special (systemd) service that would then fine tune the device_type on the first boot (e.g. change it from some_device to some_device_EU).