Data folder present in mender artifact rootfs update

PR is here: https://github.com/mendersoftware/meta-mender/pull/875

Awesome, I’ll give it a test first thing in the morning. Many thanks

After many days working on a solution, All solutions failed due to early expansion of do_image_xxx tasks.

It looks like the issue is caused by the image.bbclass dynamic generation of the do_image_xxx tasks whereby the cmds are joined into a big string to form the task script long before our functions or our anonymous python functions are called. Attempts so far to change the IMAGE_CMD_tar in the anonymous python block causes build errors with hash mismatch between the two parsing phases noticing that the IMAGE_CMD_tar variable has been changed twice.

I have an ugly solution hack for my scenario only for tar as I can fine no good solution to this after 2 days solidly on it, the problem stems from some IMAGE_CMDS_xxx being defined as variables rather than functions in image-types.bbclass

Ugly code injection/hack Warning :face_vomiting:

In the end to achieve the tar, tar.xz, tar.gz files all being based on the mender temporary rootfs directory, I had to define my own IMAGE_CMD_TAR variable in my distro.conf which was a copy of the definition of IMAGE_CMD_tar in image-types.bbclass with the rootfs path modified to the mender rootfs.image_tar. At the end of my custom IMAGE_CMD_TAR I added a shell comment symbol to prefix all the original definition in IMAGE_CMD_tar when expanded out by the do_image_tar script in the image.bbclass.

yuck!