I’m trying to build a Linux image for Colibri imx7 using Yocto. I need to modify the wrapup.sh script that is included in the myImage*-Tezi_*.tar archive.
I found the recipe responsible for installing this file (layers/meta-toradex-bsp-common/recipes-bsp/tezi-metadata/tezi-metadata_0.3.bb) made a *.bbappend and can build my changes into the script with:
bitbake tezi-metadata
I find the correctly modified file in:
build/tmp/work/colibri_imx7_emmc-tdx-linux-gnueabi/tezi-metadata/0.3-r0/deploy-tezi-metadata/
However, when I build the image with:
“bitbake myImage”
it does not install the modifyied script into the Tezi tarball, but the original file. I assume it takes a previously generated package and does not understand that with the update of the recipe that package is outdated.
I tried “-c clean” and “-c cleansstate” on the image recipe and on tezi-metadata recipe without success.
Is there a way to tell bitbake that a particular package is outdated and should be rebuilt when building the image? If so, how do I identify the package that corresponds to tezi-metadata recipe?
Or can I force bitbake to check, and if necessary rebuild, all recipes the image depends on? I would rather avoid rebuilding the whole image from scratch on updating just this single recipe.
I don’t think I’ve ever seen bitbake missing a failed dependency.
And even if that would be the case here, with “-c cleansstate” you forced a rebuild of the relevant recipes.
The tezi-metadata_0.3.bb simply copies the metadata files into the build/deploy/images/colibri-imx7-emmc/ directory.
During image creation they are taken from there and put in the image tarball.
Could you also check what version of the files are in that deploy directory? If there are the old ones that would point to tezi-metadata, if they are the new ones likely the issue happens in the image creation. Anything strange with file permissions / owner?
I found the cause of the problem:
I inserted the task to modify that script after the do_install() task. However, do_install() already stages the file to the image directory. So, in fact I was modifying the file after its copy was taken for the TEZI tarball.
Inserting the modification task between do_unpack() and do_deploy() makes the recipe apped work correctly.
I’m not sure about the exact BSP version. Where do I find it? I imported the repository on May 22 2020 from this URL:
“Index of /toradex-bsp-platform.git -b LinuxImage3.0 -m default.xml”
So I guess its BSP version 3.0
I assume this is a general problem in bitbake dependency resolution. I had a similar effect with another recipe. The image recipe would only recognize outdated build artifacts from that recipe when I added the git hash to ${PV} like this: PV = “0.1.0+git${SRCPV}”
But on tezi-metadate.bbappend I would have no git hash available to use the same pattern.
in build/tmp/work/colibri_imx7_emmc-tdx-linux-gnueabi/tezi-metadata/0.3-r0/deploy-tezi-metadata
I see the updated version of wrapup.sh - so my .bbappend is actually working.
The artifacts there were created when I run “bitbake tezi-metadata”.
I did a “-c cleansstate” on the image recipe after testing that the tezi-metadata.bbapped indeed
created the modified script in that diectory. Still, in the TEZI tarball cretaed by the image recipe
I see the original version of the script. In build/deploy/images/colibri-imx7-emmc there too is
the old version of the script, which I believe is then taken into the TEZI tarball. The
new version of the script is simply ignored.
yes, I was able to fix this problem. It was actually my misconception about the stage in which bitbake copies files to the target directory. Once I understood this in more detail I could fix it.
