We are using meta-mender in our yocto build environment. We are currently working on dunfell branch.
Last week I updated meta-mender from 45041cfb7b05c2ff44204d592b200493b25ed8ae to b3a10de4a3e5332d91fdea6169db3b0c2eb3f3ee.
After that update, the file /etc/mender/artifact_info is missing in the RootFS. Without that file we are not able to do any deployments to this devices.
As a result, this update will break our OTA-functionality!
As far as I see this change: feat: generate a bootstrap artifact · mendersoftware/meta-mender@222532b · GitHub is causing the problem.
As we are on dunfell, we are using mender-client version 2.6.1 per default. Same issue is there when using latest release 3.4.0. Other versions weren’t tested, I expect 3.3.0 to work when looking at the sources.
We manually fixed this by adding
DISTRO_EXTRA_RDEPENDS += " mender-artifact-info "
to our distro config. Is this the recommended way if fixing the issue?
Is there anything wrong with our configuration?
Does anybody have same issues?
Thanks in advance and best regards
Ran into the same issue today, on kirkstone. I can add a few more details as to what happens in runtime.
Starting from a previous working kirkstone installation, if I install a new rootfs mender artifact built today with bitbake, the file /etc/mender/artifact_info is missing on the new rootfs. Then, if I try installing another rootfs mender artifact on top of that, the “mender install” command fails instantly with this error:
ERRO Reading headers failed: open /etc/mender/artifact_info: no such file or directory
ERRO open /etc/mender/artifact_info: no such file or directory
The mender client version is 3.4.0 on both new and old rootfs.
Thanks for confirming the issue. Same behaviour on our side when trying to install ANY artifact.
Hi @ruben and thank you for your report.
This is indeed right.
We are working on a fix here.
Hopefully it should be merged very soon.
In the meantime, adding back the
mender-artifact-info dependency locally, like you have done is the go-to workaround.
Yes, it’s a known issue, we are working on fixing it. Use the tags for now, either
@kacf thanks for the hint with tags. I will use them from now on