Preconditions/Environment ------------------------- Using Angstrom v2015.12 https://github.com/openembedded/openembedded-core (jethro) Building in home folder. Triggering Action/Cause ----------------------- bitbake <image-name> Expectation ----------- No warnings. Actual Result ------------- All warnings are for -dbg packages. All are source files in /<packagename>-dbg/usr/src/debug/<packagename>/... Last build had 126 packages with the warning. Including things like: gcc-linaro-4.9: gcc: /gcc-dbg/usr/src/debug/gcc/linaro-4.9-r2015.06/gcc-linaro-4.9-2015.06/build.arm-angstrom-linux-gnueabi.arm-angstrom-linux-gnueabi/gcc/tm-preds.h is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] systemd-226+gitAUTOINC+4211d5bd13: systemd: /systemd-dbg/usr/src/debug/systemd/1_226+gitAUTOINC+4211d5bd13-r0/git/src/udev/scsi_id/scsi_serial.c is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] perl-5.22.0: perl: /perl-dbg/usr/src/debug/perl/5.22.0-r0/perl-5.22.0/ext/re/re_exec.c is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Reproducibility --------------- So far 100%
Robert, can you or co-worker try to reproduce this with only oe-core layers? If the Linaro toolchain or meta-oe layers are required to reproduce we need to know. Update this defect when you find out please.
We will work on it. Hi Joshua, Why the target milestone is 1.4.5, please ?
(In reply to comment #1) > Robert, can you or co-worker try to reproduce this with only oe-core layers? > If the Linaro toolchain or meta-oe layers are required to reproduce we need > to know. Update this defect when you find out please. I can confirm that there is no such issues in pure oe-core jethro branch, please check the linaro layer.
Mike Looijmans reported a fix on the OE-Core list. http://lists.openembedded.org/pipermail/openembedded-core/2016-January/115658.html > I got rid of these messages by doing the following replacements in do_install and package install scripts: > > Instead of "cp -r -p ..." use "cp -r --preserve=mode,links ..." > Instead of "cp -a ..." use "cp -R --no-dereference --preserve=mode,links ..." > > This fixes these QA warnings in a more structured way than running a blunt "chown root:root ..."
(In reply to comment #4) > Mike Looijmans reported a fix on the OE-Core list. > http://lists.openembedded.org/pipermail/openembedded-core/2016-January/ > 115658.html > > > I got rid of these messages by doing the following replacements in do_install and package install scripts: > > > > Instead of "cp -r -p ..." use "cp -r --preserve=mode,links ..." > > Instead of "cp -a ..." use "cp -R --no-dereference --preserve=mode,links ..." > > > > This fixes these QA warnings in a more structured way than running a blunt "chown root:root ..." It seems that they are different issues ? Mike's is qt related. This bug said was gcc, systemd, and perl.
G'day Robert, For me I had a total of 126 packages emit the warning. Those 3 packages where just the last few on the list. Andreas Muller and Max Krummenacher reported similar warnings reporting a "flood" but providing just a snippet I think of qt packages. His snippet seems to line up with it just being -dbg packages.
(In reply to comment #2) > Why the target milestone is 1.4.5, please ? Not sure why that happens — I just added myself to CC… Changed back now.
(In reply to comment #6) > G'day Robert, > For me I had a total of 126 packages emit the warning. > Those 3 packages where just the last few on the list. > > Andreas Muller and Max Krummenacher reported similar warnings reporting a > "flood" but providing just a snippet I think of qt packages. > His snippet seems to line up with it just being -dbg packages. Hi Phil, Could you please list some example of the packages? What's your contents of bblayer.conf? I just built core-image-sato-sdk on jethro branch and there's no such warning. // Qi
Created attachment 2944 [details] Log file of warings Log files of a clean build today.
Created attachment 2945 [details] bblayer.conf meta-emit is layer that creates an image for our hardware. very little in it other than a recipe to build our kernel (based on altera's kernel recipe) and list of some extra packages from the altera console-image.
I think the problem needs to be fixed recipe by recipe in your layers. They are either caused by 'cp' command in do_install task or 'cp' command in Makefile. // Qi
It appears the NEEDINFO has been cleared.
The issue still exists in current master. Only an angstrom setup did show the issue, setting up a poky build did not. When I build core-image-minimal for qemux86 with a current angstrom setup I get 50 recipes which throw the warning, producing 9597 lines of clutter in the log file: $ grep -c "WARNING.*owned by" 20160403135759.log 50 $ grep -c "owned by" 20160403135759.log 9597 For reasons unknown to me poky does not deploy source files into the -dbg packages in the first place, thus the bug is not triggered in poky. On poky ${WORKDIR}/debugsources.list does only contain paths with directory elements, while on angstrom some paths end with a regular file name. I sent a patch to the ML which chowns the source files after they get copied into the package directory: http://lists.openembedded.org/pipermail/openembedded-core/2016-April/119825.html
Is your layer available publicly? What's your layers git revs? Regards, Chen Qi
I finally got enough time to investigate further. I found cpio -l (i.e. createing hardlinks) under pseudo does not set the owner to root, neither width --no-preserve-owner nor with - -owner=0:0. The file ownership in Poky is corrected later with fs-perms.txt. Angstrom does provide its own fs perms configuration which disables the oe-core fs-perms.txt. But due to a bug the angstrom file is not active. Patch sent to the angstrom ML. http://article.gmane.org/gmane.linux.distributions.angstrom.devel/7856 http://www.mail-archive.com/angstrom-distro-devel@linuxtogo.org/msg07263.html @ Chen I used the following Angstrom setup which shows the issue: Build Configuration: BB_VERSION = "1.31.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "SUSELINUX-42.1" TARGET_SYS = "i586-angstrom-linux" MACHINE = "qemux86" DISTRO = "angstrom" DISTRO_VERSION = "v2016.07" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta = "master:da7a2c7b00b40a8759dbe9f4ab6df3e337e3d6b6" meta-multimedia meta-oe meta-systemd = "master:303d9ea960e2d88281079a4e71abe2cf8c815184" meta-qt5 = "master:15a4f86005e4435b9e0a2f1e7d0477e327fcbe83" meta-angstrom = "master:cab08f9a68d86b48c65fdf07a709f05a211ccf93" While the following Poky setup does not: Build Configuration: BB_VERSION = "1.31.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "i586-poky-linux" MACHINE = "qemux86" DISTRO = "poky" DISTRO_VERSION = "2.1+snapshot-20160716" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "master:627d01997fcf6a0581d88047735769ffb2592b82" Note that poky and angstrom meta use the same head: * 627d019 (HEAD -> master, origin/master, origin/HEAD) useradd-staticids: use map() instead of imap() * da7a2c7 (HEAD -> master, origin/master, origin/HEAD) useradd-staticids: use map() instead of imap() local.conf differences: -DISTRO ?= "poky" +DISTRO ?= "angstrom" Regards Max
(In reply to comment #15) > I finally got enough time to investigate further. > > I found cpio -l (i.e. createing hardlinks) under pseudo does not set > the owner to root, neither width --no-preserve-owner nor with - > -owner=0:0. Peter has mentioned elsewhere that (i.e. #9317[1]) that he expects pseudo has issues to do with hardlinks ending up with incorrect modes. Peter (added to CC), should we track this as a pseudo bug? 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9317#c1
Probably worth checking on. What exactly is being done with cpio that's not producing the expected ownership?
(In reply to comment #17) > Probably worth checking on. What exactly is being done with cpio that's not > producing the expected ownership? The use case here is the deployment of the src files in do_package. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/package.bbclass#n393 When I looked into this I found that pseudo behaves the same as when I'm using ln and cpio as the real root, e.g. the newly created hardlinks have uid/gid/mode from the source file. So I'm not so sure if that is real issue with pseudo. Note 1: Using sudo chown afterwards on one of the files changes uid/gid for all of the hardlinks. Note 2: That is on an ext4 fs. > whoami mk > touch bla > ln bla bla.ln.user > sudo ln bla bla.ln.sudo > echo bla | cpio -pdmL --no-preserve-owner bla.cpio.user > echo bla | sudo cpio -pdmL --no-preserve-owner bla.cpio.root > sudo ls -R -l .: insgesamt 8 -rw-r--r-- 5 mk users 0 1. Aug 20:47 bla drwx------ 2 root root 4096 1. Aug 20:52 bla.cpio.root drwx------ 2 mk users 4096 1. Aug 21:02 bla.cpio.user -rw-r--r-- 5 mk users 0 1. Aug 20:47 bla.ln.sudo -rw-r--r-- 5 mk users 0 1. Aug 20:47 bla.ln.user ./bla.cpio.root: insgesamt 0 -rw-r--r-- 5 mk users 0 1. Aug 20:47 bla ./bla.cpio.user: insgesamt 0 -rw-r--r-- 5 mk users 0 1. Aug 20:47 bla
Seems this is really a pseudo bug, marking it as such. Max seems to have provided additional information, so moving this back to NEW
I thought we had resolved a problem related to this in post-release 2.0 (jethro) or somewhere in 2.1 development. I wish I could remember the details, but it was some type of inconsistency between a copy function and when it was run. Is this issue still happening in 2.1 or master? The only issue I'm aware of that is still occurring is modes on -dbg items are changing. We know the cause -- but do not have a fix yet.
We have a probable fix (drop the chmod/chown commands from the -dbg file generation, which are trying to duplicate the original's permissions on a hard link, which is redundant at best), but that doesn't change the fact that we're preserving the original filesystem ownership for those files, which is probably a mistake. It might make more sense to chown -R 0:0 the -dbg tree after linking it, which would likely make this go away. It certainly makes sense that, when extracting files not-under-pseudo, then hardlinking to them, then packaging them, we end up with host filesystem ownership.
I tried: $ bitbake gnome-common -cdevshell $ cd ../image/usr/bin $ echo gnome-autogen.sh | cpio -p -l /tmp/ # ls -l gnome-autogen.sh /tmp/gnome-autogen.sh -rwxr-xr-x 2 root root 12093 Sep 27 02:29 gnome-autogen.sh -rwxr-xr-x 2 root root 12093 Sep 27 02:29 /tmp/gnome-autogen.sh Their ownerships are the same. I think that it should be fixed on master branch.