# Update Module Artifact Filtering **URL:** \ **Category:** General Discussions\ **Created:** [January 5, 2022, 10:01am UTC](https://hub.mender.io/t/update-module-artifact-filtering/4448 "2022-01-05T10:01:02Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [January 5, 2022, 10:01am UTC](https://hub.mender.io/t/update-module-artifact-filtering/4448/1 "2022-01-05T10:01:02Z")
I recently encountered the following situation and I am wondering if there is an elegant solution: I have two devices that share the same device\_type but come with different modems: Device A: device\_type=some\_device, modem\_type=some\_modem\_EU Device B: device\_type=some\_device, modem\_type=some\_modem\_AF 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? ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [January 5, 2022, 4:40pm UTC](https://hub.mender.io/t/update-module-artifact-filtering/4448/2 "2022-01-05T16:40:16Z")
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. ---
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [January 5, 2022, 8:10pm UTC](https://hub.mender.io/t/update-module-artifact-filtering/4448/3 "2022-01-05T20:10:16Z")
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). ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [January 5, 2022, 10:33pm UTC](https://hub.mender.io/t/update-module-artifact-filtering/4448/4 "2022-01-05T22:33:25Z")
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? ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [January 5, 2022, 10:42pm UTC](https://hub.mender.io/t/update-module-artifact-filtering/4448/5 "2022-01-05T22:42:53Z")
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. ---
**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:** [January 6, 2022, 6:11am UTC](https://hub.mender.io/t/update-module-artifact-filtering/4448/6 "2022-01-06T06:11:50Z")
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`](https://docs.mender.io/development/system-updates-yocto-project/variables#mender_device_types_compatible) variable. Then you can build modem updates that only support one of the types and this will be automatically selected. ---
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [January 6, 2022, 8:04am UTC](https://hub.mender.io/t/update-module-artifact-filtering/4448/7 "2022-01-06T08:04:29Z")
@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).