Target file system contaminated with wrong permissions

[lakabd]

When I execute the commands below to build my linux image inside the container, the resulted file system inside the image is contaminated with wrong (non-root) permissions :

docker run -d --name="crops-cont" -v "/home/user/workdir:/workdir" --workdir="/workdir" crops/poky:ubuntu-18.04

sleep 1

docker exec -u pokyuser "crops-cont" bash -c "source src/poky/oe-init-build-env build-dir/ && bitbake my-image"

When building the image, Bitbake runs smoothly with no errors/warnings. Below is a capture of the obtained file system :

I eliminated all the suspects when analyzing the origin of the problem, and I found out that the container is what is causing the issue. When I build my image without it, the problem disappears.

Does anyone have any clue to what may cause such a problem when using the container ?

also, if I don't add the sleep 1 between the two docker calls inside my script I get : unable to find user pokyuser: no matching entries in passwd file is this a normal behavior ?

any help is greatly appreciated :)

[rewitt1]

Hi @lakabd,

Does this occur when only using oe-core images and metadata(or poky) alone? For instance do you see the same issue when building core-image-minimal with no other layers?

If not, then without having the combination of layers and recipes you are using, I'm not sure I would be able to reproduce the issue.

[lakabd]

Hi @rewitt1, Thank you for your reply.

I tried to build a core-image-minimal-initramfs for the qemux86 machine using the same commands as the above, and I encountered a similar permissions issue, but this time in the yocto build directory : all sysroot native binaries inside qemu-helper-native (tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin) cannot be executed. I get the error : cannot execute binary file with bash exit status 126.

Now, in the GNU doc, 126 exit code refers to command is found but is not executable, but I found out that it can be caused also by wrong permissions. However, if I execute ls -l I can see that all the binaries are executable and have my users UID and GID.

There is a great chance that this issue is linked to my build environment, as if it wasn't the case, it would have already made some noise on the issues menu-tab. However, it stays related to the use of the container, because again, if I try to build the image without the container, everything works well.

I would really appreciate it if you could help with some insights on what can go wrong inside the container that can cause such issues.

[rewitt1]

I'm willing to try and help, but I'm not sure I'll be able to if I can't reproduce the issue.

I tried to build a core-image-minimal-initramfs for the qemux86 machine using the same commands as the above, and I encountered a similar permissions issue, but this time in the yocto build directory : all sysroot native binaries inside qemu-helper-native (tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin) cannot be executed. I get the error : cannot execute binary file with bash exit status 126.{/quote}

Was this inside of the container or on the host?

I forgot to answer one of your previous questions:

also, if I don't add the sleep 1 between the two docker calls inside my script I get : unable to find user pokyuser: no matching entries in passwd file is this a normal behavior ?

This is expected in this case. On your command line docker run -d --name="crops-cont" -v "/home/user/workdir:/workdir" --workdir="/workdir" crops/poky:ubuntu-18.04 you specify -d. This means that the command can return before the container is fully started, and therefore the pokyuser may not yet be created inside of the container.

[lakabd]

Was this inside of the container or on the host?

The build was inside the container and the problem was located inside the tmp/ of the yocto project (as I'm sharing all the workplace with the container)

Also, I noticed lately that the problem occurs only if the container wasn't already running (in my script I was deleting the container after each build), if I create and leave the container running and just use docker exec afterwards to run my bitbake cmds, the problem disappears !.

I'm willing to try and help, but I'm not sure I'll be able to if I can't reproduce the issue.

I find the issue really bizarre, and I'm quite sure that it is related to my build environment. Nevertheless, if you have any idea or suggestion for a test to try, please share it, I'll be more than happy to test it on my environment.

Lastly, I would appreciate it if you could leave the issue open, in case someone encounters the same issue so he can share his insights.