I’m building a solution as an updatable VM using mender framework.
I saw that there is a file in /etc/mender called “rootfs-image-v2.conf”.
It seems to be generated by mender-client-test-files.inc.
Could it be an issue to assume that mender is in test mode where I am in a “production mode”.
Can I proprose a patch to explicitly have mender-client-test package and not rely on QEMU meaning Test?
It’s a reasonable request, but I think it’s a bit tricky to fix because some of test files are quite deeply embedded in our test system. We test the same QEMU image that we release, and therefore some of the test files, such as
mender-image-v2.conf, are still present.
I have two proposals:
Simply ignore it. Even though there are a few test files installed, they are all made to be non-intrusive. IOW they only have an effect if they are actively used.
If you are building for x86, I suspect that you can simply remove the meta-mender-qemu layer. It’s primary purpose is to supply our test files for QEMU, and to enable QEMU on vexpress (ARM test board). For x86 production I don’t think the layer has any significant effect.
Thanks for answering and confirming that’s not a big issue.
A quick fix for me will be to blacklist this BB recipe to avoid shipping unnecessary dependencies.
Another solution could be to move this recipes to a meta-mender-test layer that’s not related to qemu no ?
It’s… complicated. The meta-mender-ci layer has loads of more, much more intrusive, changes, for extensive testing. But we run a smaller number of tests even on our shipped images for QEMU, which means those test recipes need to be in meta-mender-qemu. So it’s somewhere in-between. Meta-mender-qemu is not quite a production layer, but not quite a test layer, either.
It’s not impossible to fix, but not very high priority either, since meta-mender-qemu is not really meant for production images.