poky master commit id: 312488228ad408fb0f29b2aa272e72cf87de8e93 = core-image-minimal looks good = 5.1.x sudo tar xvf core-image-minimal-multi-v7-ml.rootfs.tar.bz2 -C /opt/resy/5.1.66/multi-v7-ml/imx6q-phytec-mira-rdk-nand/lumpi-core-image-minimal ls -lah total 68K drwxr-xr-x 17 root root 4.0K Mar 9 2018 . drwxr-xr-x 6 root root 4.0K Oct 3 09:02 .. drwxr-xr-x 2 root root 4.0K Mar 9 2018 bin drwxr-xr-x 2 root root 4.0K Mar 9 2018 boot drwxr-xr-x 2 root root 4.0K Mar 9 2018 dev drwxr-xr-x 20 root root 4.0K Mar 9 2018 etc drwxr-xr-x 3 root root 4.0K Mar 9 2018 home drwxr-xr-x 7 root root 4.0K Mar 9 2018 lib drwxr-xr-x 2 root root 4.0K Mar 9 2018 media drwxr-xr-x 2 root root 4.0K Mar 9 2018 mnt dr-xr-xr-x 2 root root 4.0K Mar 9 2018 proc drwxr-xr-x 2 root root 4.0K Mar 9 2018 run drwxr-xr-x 2 root root 4.0K Mar 9 2018 sbin dr-xr-xr-x 2 root root 4.0K Mar 9 2018 sys drwxrwxrwt 2 root root 4.0K Mar 9 2018 tmp drwxr-xr-x 9 root root 4.0K Mar 9 2018 usr drwxr-xr-x 8 root root 4.0K Mar 9 2018 var = core-image-sato-sdk wrong user:group (not booting over nfs) = drwxr-xr-x 18 student student 4.0K Mar 9 2018 . drwxr-xr-x 6 root root 4.0K Oct 3 09:13 .. drwxr-xr-x 2 student student 4.0K Mar 9 2018 bin drwxr-xr-x 2 student student 4.0K Mar 9 2018 boot drwxr-xr-x 2 student student 4.0K Mar 9 2018 dev drwxr-xr-x 62 student student 4.0K Mar 9 2018 etc drwxr-xr-x 3 student student 4.0K Mar 9 2018 home drwxr-xr-x 9 student student 4.0K Mar 9 2018 lib drwxr-xr-x 2 student student 4.0K Mar 9 2018 media drwxr-xr-x 2 student student 4.0K Mar 9 2018 mnt drwxr-xr-x 3 student student 4.0K Mar 9 2018 opt drwxr-xr-x 2 student student 4.0K Mar 9 2018 proc drwxr-xr-x 2 student student 4.0K Mar 9 2018 run drwxr-xr-x 2 student student 4.0K Mar 9 2018 sbin drwxr-xr-x 2 student student 4.0K Mar 9 2018 sys drwxr-xr-t 2 student student 4.0K Mar 9 2018 tmp drwxr-xr-x 11 student student 4.0K Mar 9 2018 usr drwxr-xr-x 9 student student 4.0K Mar 9 2018 var It should be something like: drwxr-xr-x 17 root root 4.0K Oct 2 22:32 . drwxr-xr-x 5 root root 4.0K Oct 3 09:20 .. drwxr-xr-x 2 root root 4.0K Mar 9 2018 bin drwxr-xr-x 2 root root 4.0K Mar 9 2018 boot drwxr-xr-x 2 root root 4.0K Mar 9 2018 dev drwxr-xr-x 62 root root 4.0K Oct 2 22:32 etc drwxr-xr-x 3 root root 4.0K Mar 9 2018 home drwxr-xr-x 9 root root 4.0K Mar 9 2018 lib drwxr-xr-x 2 root root 4.0K Mar 9 2018 media drwxr-xr-x 2 root root 4.0K Mar 9 2018 mnt drwxr-xr-x 3 root root 4.0K Mar 9 2018 opt drwxr-xr-x 2 root root 4.0K Mar 9 2018 proc drwxr-xr-x 2 root root 4.0K Mar 9 2018 run drwxr-xr-x 2 root root 4.0K Mar 9 2018 sbin drwxr-xr-x 2 root root 4.0K Mar 9 2018 sys lrwxrwxrwx 1 root root 8 Oct 2 22:32 tmp -> /var/tmp drwxr-xr-x 11 root root 4.0K Mar 9 2018 usr drwxr-xr-x 9 root root 4.0K Oct 2 22:32 var
The good news is that the problem does not seem to exist on the styhead branch, but only on master. This[1] commit from styhead looks good. [1] 16ffecc808365f7399fb58d53dcd07ff951eba3c7
a quick diff against master shows this: $ git diff master meta/classes-recipe/image_types.bbclass diff --git a/meta/classes-recipe/image_types.bbclass b/meta/classes-recipe/image_types.bbclass index 87d6effc6c..b230add314 100644 --- a/meta/classes-recipe/image_types.bbclass +++ b/meta/classes-recipe/image_types.bbclass @@ -145,7 +145,7 @@ IMAGE_CMD:vfat = "oe_mkvfatfs ${EXTRA_IMAGECMD}" IMAGE_CMD_TAR ?= "tar" # ignore return code 1 "file changed as we read it" as other tasks(e.g. do_image_wic) may be hardlinking rootfs -IMAGE_CMD:tar = "${IMAGE_CMD_TAR} --sort=name --format=posix --pax-option=delete=atime,delete=ctime --numeric-owner -cf ${IMGDEPLOYDIR}/${IMAGE_NAME}.tar -C ${IMAGE_ROOTFS} . || [ $? -eq 1 ]" +IMAGE_CMD:tar = "${IMAGE_CMD_TAR} --sort=name --format=posix --numeric-owner -cf ${IMGDEPLOYDIR}/${IMAGE_NAME}.tar -C ${IMAGE_ROOTFS} . || [ $? -eq 1 ]" SPDX_IMAGE_PURPOSE:tar = "archive" do_image_cpio[cleandirs] += "${WORKDIR}/cpio_append" @@ -283,7 +283,6 @@ EXTRA_IMAGECMD:f2fs ?= "" # otherwise mkfs.vfat will automatically pick one. EXTRA_IMAGECMD:vfat ?= "" -do_image_tar[depends] += "tar-replacement-native:do_populate_sysroot" do_image_cpio[depends] += "cpio-native:do_populate_sysroot" do_image_jffs2[depends] += "mtd-utils-native:do_populate_sysroot" do_image_cramfs[depends] += "util-linux-native:do_populate_sysroot" @@ -392,5 +391,3 @@ IMAGE_TYPES_MASKED ?= "" # bmap requires python3 to be in the PATH EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('.bmap') else ''}" -# reproducible tar requires our tar, not the host's -EXTRANATIVEPATH += "${@'tar-native' if 'tar' in d.getVar('IMAGE_FSTYPES') else ''}"
That change isn't quite the right thing, but Ross will take a look. Thank you Ross.
With current master I can't replicate. I build core-image-sato-sdk and then looked at a listing of the rootfs tarball: $ tar atvf tmp/deploy/images/qemuarm64/core-image-sato-sdk-qemuarm64.rootfs.tar.bz2 | head drwxr-xr-x 0/0 0 2018-03-09 12:34 ./ lrwxrwxrwx 0/0 0 2018-03-09 12:34 ./bin -> usr/bin drwxr-xr-x 0/0 0 2018-03-09 12:34 ./boot/ lrwxrwxrwx 0/0 0 2018-03-09 12:34 ./boot/Image -> Image-6.10.11-yocto-standard -rw-r--r-- 0/0 22409728 2018-03-09 12:34 ./boot/Image-6.10.11-yocto-standard drwxr-xr-x 0/0 0 2018-03-09 12:34 ./dev/ drwxr-xr-x 0/0 0 2018-03-09 12:34 ./etc/ The files have root:root ownership. This smells like user error, in that the tarball was not unpacked as root. Can you verify that your rootfs tarballs have incorrect permissions when you list the contents, instead of unpacking them?
Mine don't. I build, as ususal, in a docker container and it's the same process - actually scripted, I use to unpack it. Switching to styhead fixed it. $ tar atvf core-image-sato-sdk-multi-v7-ml.rootfs.tar.bz2 | head drwxr-xr-x 1000/1000 0 2018-03-09 12:34 ./ drwxr-xr-x 1000/1000 0 2018-03-09 12:34 ./bin/ lrwxrwxrwx 1000/1000 0 2018-03-09 12:34 ./bin/ash -> /bin/busybox.nosuid lrwxrwxrwx 1000/1000 0 2018-03-09 12:34 ./bin/base64 -> /usr/bin/base64.coreutils lrwxrwxrwx 1000/1000 0 2018-03-09 12:34 ./bin/bash -> /bin/bash.bash -rwxr-xr-x 1000/1000 846372 2018-03-09 12:34 ./bin/bash.bash lrwxrwxrwx 1000/1000 0 2018-03-09 12:34 ./bin/busybox -> busybox.nosuid -rwxr-xr-x 1000/1000 476920 2018-03-09 12:34 ./bin/busybox.nosuid -rwsr-xr-x 1000/1000 42440 2018-03-09 12:34 ./bin/busybox.suid lrwxrwxrwx 1000/1000 0 2018-03-09 12:34 ./bin/cat -> /bin/cat.coreutils
Huh. What image are you running inside the docker? (and specifically, what version of tar does it have?) Can you replicate with a pristine poky in a fresh build directory with no configuration and just bitbake core-image-sato-sdk?
in the container I have: Ubuntu 22.04.4 LTS tar --version tar (GNU tar) 1.34 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason.
Very odd. Can you confirm that you can replicate with a *pristine* poky with no layers/configuration?
Inside a podman container (specifically, the kas container which is Debian based) I also can't replicate: $ tar atvf core-image-sato-qemuarm64.rootfs-20241022163312.tar.bz2|head drwxr-xr-x 0/0 0 2018-03-09 12:34 ./ drwxr-xr-x 0/0 0 2018-03-09 12:34 ./bin/ lrwxrwxrwx 0/0 0 2018-03-09 12:34 ./bin/ash -> /bin/busybox.nosuid
with master 626031da74b31d0a8c5ca9d5a1acac9a2d55e998 it seems to be OK again. Something healed for me ;)
Closing then.