I have just noticed using mender sumo branch in yocto, that I am seeing the contents of the data partition in the mender rootfs artifact. However the sdimg looks correct with nothing in the /data folder in the A/B rootfs partitions and the content in the data partition.
Is there something in particular I should be doing to make the content of data partition not appear in the rootfs mender artifact?. I thought with the addition of the IMAGE_ROOTFS_EXCLUDE_PATH code this shouldn’t happen?
no build errors, at all, just see device_type in mender folder, which i guess the mender recipe is installing, and fw_env.config in the uboot folder which i guess is also coming from the mender recipe/uboot patches.
I will take a look at your suggestion, many thanks. I also need to bring the various sumo layers up to date, so maybe that will help
currently re-building a clean build, incase something dirty in the build is causing the tar and tar.xz to not been cleaned of data directory. I can see in the do_image_tar logs that the functions prepare_excluded_directories and cleanup_excluded_directories are being executed
when i dump the command being used for IMAGE_CMD_tar it points to build/tmp/debug/work/ty_k_turn_2_arm_varsommx6-poky-linux-gnueabi/turn-core-image-minimal/1.0-r0/rootfs and not the mender temporary rootfs folder, so this may explain whe we can see the prepare_excluded_directories executing, but the tar command is using the original rootfs folder. variable expansion issue? race/dependency/ task evaluation order issue?
To fix this “fully”, there needs to be some backports,
To try to explain the problem again, if you have,
IMAGE_FSTYPES = "tar.bz2"
The pre/post hooks will be installed on do_image_tar.bz2 task, but there is no such task and you want the hooks on do_image_tar as the bz2 is just a “conversion” image.
So to get around this problem you would set:
IMAGE_FSTYPES = "tar tar.bz2"
This way you would make sure that the pre/post hooks are applied to do_image_tar and /data would be cleaned up properly. This applies to all “conversion” images an the linked fix should take care of this.
Yeah, that feels like what is happening. I’m playing with a change to the prepare_excluded and cleanup_excluded functions so that changing the value of IMAGE_ROOTFS is not necessary. Basically it will back up the original in prepare and restore it in cleanup.