| Summary: | core-image-sato-sdk-xxx-.tar.gz wrong user:group | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Robert Berger <pokylinux> |
| Component: | core | Assignee: | Ross Burton <ross.burton> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | meta.mr.watcher, meta.watcher, ross.burton, tim.orling, yoann.congal |
| Version: | 5.1.4 | ||
| Target Milestone: | 5.2 M1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Robert Berger
2024-10-03 09:21:11 UTC
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. |