Apply preexisting provides to compiled mender uefiimg image

Hello, I am trying to generate a yocto image with preexisting provides for the mender client. I need this as I have to deploy custom update module artifacts with certain depends fields matching provides preexisting on the device. There is a MENDER_ARTIFACT_PROVIDES yocto variable available but this only adds the provides information to the mender artifact but not the compiled image. Or is there a way to modify (add new / change existing) the existing provides field during runtime? Does anyone have any suggestions on how to accomplish this?

Any thoughts please ? @kacf

Hi @GowthamSK,

indeed, this should probably be added here. We’ll look into possible implications and let you know. Thanks for bringing this up!

Greetz,
Josef

Note that the artifact_info file is deprecated, and support for it will be removed soon. Unfortunately it is not possible to have pre-existing provides data on the device after the first flash. The easiest way to resolve it is just to create an artifact which installs a dummy file in /tmp using the single-file update type, and which has all of the requires provides fields.

In the future we expect this problem to be resolved by this feature. I can’t say exactly when it will be resolved, but it has received some attention lately, so I’m hopeful.

I am trying to create a custom update module feature for the mender client using which I intend to update the firmware images in the system. The board might have multiple firmware images or a single firmware image. Each of these firmware images has its own version information. Now the custom artifact for this can have a single firmware image or multiple firmware images to be updated. My initial plan was to use the provides and depends field for the artifact to make sure that the server deploys the artifact only to the boards which are running older versions of the firmware image than what is provided by the artifact. But currently as discussed here, there is no support to have pre-existing provides on the board. Apart from the dummy file installation in /tmp, can you please tell me if there is there any other mender feature existing that can be used for this use case?

Thanks for your response @kacf. So the mender provides is stored in an LMDB database in the data partition which is available as mender-store file in the rootfs. Is it possible to edit this database during runtime using mender client? If so, I can create the provides I need after every boot.

I think you only need it upon the first boot. If so, one thing you can try is to put a dummy artifact, like the one I mentioned earlier, somewhere on the data filesystem, and then make a systemd service file which you enable at boot, which installs this artifact using mender install <ARTIFACT>. Then remove the artifact, and make the service dependent on its existence, so it won’t run more than once. This essentially replicates what MEN-2582 will do.

Thanks for your response @kacf

Hi @kacf Is there any update on MEN-2582, are we proceeding with the fix?

Yes, it is being worked on right now, and it should most likely (though I cannot guarantee it 100%) be part of the next Mender release.

1 Like

This has now been implemented. It should provide everything you need through this bootstrap artifact, which gets installed the first time Mender is launched in a fresh image. Use the MENDER_ARTIFACT_PROVIDES variable to supply information.

Thanks for the update. Release version, please?

Mender client 3.5.0.

But mender-artifact 3.9.0, which is already out, can already write bootstrap artifacts, and the latest kirkstone and dunfell branches write bootstrap artifacts as part of their builds. So you can already look at them for validation. But the actual usage of the bootstrap artifact needs to wait for the Mender client 3.5.0.

Thanks for the reply, when will this be ported to meta-mender (yocto recipe) ?

I’m not sure exactly, it depends on when Mender 3.5.0 is released. From experience I’d say maybe late December or early to mid January, but treat that as uncertain.