15606 2024-10-03 09:21:11 +0000 core-image-sato-sdk-xxx-.tar.gz wrong user:group 2024-11-11 12:05:11 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 5.1.4 x86 Multiple RESOLVED FIXED Medium+ normal 5.2 M1 1 pokylinux ross.burton meta.mr.watcher meta.watcher ross.burton tim.orling yoann.congal --- --- Don't know oldest_to_newest 99752 0 pokylinux 2024-10-03 09:21:11 +0000 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 99754 1 pokylinux 2024-10-03 13:40:57 +0000 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 99755 2 pokylinux 2024-10-03 13:49:09 +0000 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 ''}" 99757 3 tim.orling 2024-10-03 14:43:22 +0000 That change isn't quite the right thing, but Ross will take a look. Thank you Ross. 99764 4 ross.burton 2024-10-03 15:16:08 +0000 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? 99766 5 pokylinux 2024-10-03 19:05:33 +0000 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 99830 6 ross.burton 2024-10-10 15:20:06 +0000 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? 99845 7 pokylinux 2024-10-11 17:57:54 +0000 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. 99918 8 ross.burton 2024-10-17 15:12:18 +0000 Very odd. Can you confirm that you can replicate with a *pristine* poky with no layers/configuration? 99964 9 ross.burton 2024-10-22 19:16:54 +0000 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 100136 10 pokylinux 2024-11-10 18:31:53 +0000 with master 626031da74b31d0a8c5ca9d5a1acac9a2d55e998 it seems to be OK again. Something healed for me ;) 100140 11 ross.burton 2024-11-11 12:05:11 +0000 Closing then.