public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'Felix Moessbauer' via isar-users" <isar-users@googlegroups.com>
To: isar-users@googlegroups.com
Cc: quirin.gylstorff@siemens.com,
	Felix Moessbauer <felix.moessbauer@siemens.com>
Subject: [RFC 06/12] rootfs: rework sstate caching of rootfs artifact
Date: Wed, 18 Feb 2026 12:58:21 +0100	[thread overview]
Message-ID: <20260218115827.3947145-7-felix.moessbauer@siemens.com> (raw)
In-Reply-To: <20260218115827.3947145-1-felix.moessbauer@siemens.com>

We ensure that the sstate artifact is always generated for the correct
rootfs directory by using the ROOTFSDIR variable instead of the
assumption that it is in "rootfs". Further, we avoid file permission
cleanup by using stdout to pass the artifact from the privileged space
to the caller.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/classes-recipe/rootfs.bbclass | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/meta/classes-recipe/rootfs.bbclass b/meta/classes-recipe/rootfs.bbclass
index b64a5bde..c9b0a6d1 100644
--- a/meta/classes-recipe/rootfs.bbclass
+++ b/meta/classes-recipe/rootfs.bbclass
@@ -663,11 +663,12 @@ rootfs_install_sstate_prepare() {
     # tar --one-file-system will cross bind-mounts to the same filesystem,
     # so we use some mount magic to prevent that
     mkdir -p ${WORKDIR}/mnt/rootfs
-    run_privileged mount -o bind,private '${WORKDIR}/rootfs' '${WORKDIR}/mnt/rootfs' -o ro
-    lopts="--one-file-system --exclude=var/cache/apt/archives"
-    run_privileged tar -C ${WORKDIR}/mnt -cpSf rootfs.tar $lopts ${SSTATE_TAR_ATTR_FLAGS} rootfs
-    run_privileged umount ${WORKDIR}/mnt/rootfs
-    run_privileged chown $(id -u):$(id -g) rootfs.tar
+    run_privileged_here <<'EOF' 3> rootfs.tar
+        mount -o bind,private '${ROOTFSDIR}' '${WORKDIR}/mnt/rootfs' -o ro
+        lopts="--one-file-system --exclude=var/cache/apt/archives"
+        tar -C ${WORKDIR}/mnt/rootfs -cpS $lopts ${SSTATE_TAR_ATTR_FLAGS} . >&3
+        umount -q ${WORKDIR}/mnt/rootfs
+EOF
 }
 do_rootfs_install_sstate_prepare[lockfiles] = "${REPO_ISAR_DIR}/isar.lock"
 
@@ -676,7 +677,8 @@ rootfs_install_sstate_finalize() {
     # - after building the rootfs, the tar won't be there, but we also don't need to unpack
     # - after restoring from cache, there will be a tar which we unpack and then delete
     if [ -f rootfs.tar ]; then
-        run_privileged tar -C ${WORKDIR} -xpf rootfs.tar ${SSTATE_TAR_ATTR_FLAGS}
+        mkdir -p ${ROOTFSDIR}
+        run_privileged tar -C ${ROOTFSDIR} -xp ${SSTATE_TAR_ATTR_FLAGS} < rootfs.tar
         rm rootfs.tar
     fi
 }
-- 
2.51.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/20260218115827.3947145-7-felix.moessbauer%40siemens.com.

  parent reply	other threads:[~2026-02-18 11:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-18 11:58 [RFC 00/12] add support to build isar unprivileged 'Felix Moessbauer' via isar-users
2026-02-18 11:58 ` [RFC 01/12] refactor bootstrap: store rootfs tar with user permissions 'Felix Moessbauer' via isar-users
2026-02-18 11:58 ` [RFC 02/12] deb-dl-dir: export without root privileges 'Felix Moessbauer' via isar-users
2026-02-18 14:01   ` 'Jan Kiszka' via isar-users
2026-02-18 11:58 ` [RFC 03/12] download debs without locking 'Felix Moessbauer' via isar-users
2026-02-18 11:58 ` [RFC 04/12] introduce wrappers for privileged execution 'Felix Moessbauer' via isar-users
2026-02-18 14:11   ` 'Jan Kiszka' via isar-users
2026-02-18 11:58 ` [RFC 05/12] bootstrap: move cleanup trap to function 'Felix Moessbauer' via isar-users
2026-02-18 11:58 ` 'Felix Moessbauer' via isar-users [this message]
2026-02-18 11:58 ` [RFC 07/12] rootfs_generate_initramfs: rework deployment to avoid chowning 'Felix Moessbauer' via isar-users
2026-02-18 11:58 ` [RFC 08/12] wic: rework image deploy logic to deploy under correct user 'Felix Moessbauer' via isar-users
2026-02-18 11:58 ` [RFC 09/12] use bitbake function to generate mounting scripts 'Felix Moessbauer' via isar-users
2026-02-18 11:58 ` [RFC 10/12] apt-fetcher: prepare for chroot specific fetching 'Felix Moessbauer' via isar-users
2026-02-18 11:58 ` [RFC 11/12] add support for fully rootless builds 'Felix Moessbauer' via isar-users
2026-02-18 16:09   ` 'Jan Kiszka' via isar-users
2026-02-18 16:50   ` 'Jan Kiszka' via isar-users
2026-02-18 11:58 ` [RFC 12/12] apt-fetcher: implement support for unshare backend 'Felix Moessbauer' via isar-users
2026-02-18 18:20 ` [RFC 00/12] add support to build isar unprivileged 'Jan Kiszka' via isar-users
2026-02-18 18:31   ` 'Jan Kiszka' via isar-users

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260218115827.3947145-7-felix.moessbauer@siemens.com \
    --to=isar-users@googlegroups.com \
    --cc=felix.moessbauer@siemens.com \
    --cc=quirin.gylstorff@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox