[PATCH 1/2] fix(rootfs): protect rootfs_install sstate prepare with lock

["'Felix Moessbauer' via isar-users" <isar-users@googlegroups.com>]

Previously the lock was a no-op, as it was attached to a task that does
not exist (the task is named do_rootfs_install_setscene). Instead attach
it to the function that is executed by bitbake on sstate prepare.

This might explain some sporadic data races on sstate tasks that
silently lead to the task being re-executed.

Fixes: 085efc7d ("sstate: add caching to rootfs")
Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/classes-recipe/rootfs.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/rootfs.bbclass b/meta/classes-recipe/rootfs.bbclass
index a58ad031..8a4aad16 100644
--- a/meta/classes-recipe/rootfs.bbclass
+++ b/meta/classes-recipe/rootfs.bbclass
@@ -702,7 +702,7 @@ rootfs_install_sstate_prepare() {
     sudo umount ${WORKDIR}/mnt/rootfs
     sudo chown $(id -u):$(id -g) rootfs.tar
 }
-do_rootfs_install_sstate_prepare[lockfiles] = "${REPO_ISAR_DIR}/isar.lock"
+rootfs_install_sstate_prepare[lockfiles] = "${REPO_ISAR_DIR}/isar.lock"
 
 rootfs_install_sstate_finalize() {
     # this runs in SSTATE_INSTDIR
-- 
2.53.0

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/20260625150232.531442-2-felix.moessbauer%40siemens.com.