1. Topics
  2. Ownership issue during do_image

Ownership issue during do_image

Frederic Martinsons <frederic.martinsons@...>
 

Hello, some news about this issue.

Tim pointed me to the docker and the reason why crops container have some UID:GID manipulation: see there.

I used an ubuntu 20.04 VM to setup a build without docker and I fall into the exact same problem.

But finally, I found that a workaround by creating and using another working directory inside my image creation command (though I clearly don't know why this work and the former way don't, despite it worked with yocto warrior)

Before that, I have a working directory that was created in the bbclass :

SQSHDIR = "${S}/sqshimg/${MACHINE}"

do_image_tapos_sqshimg[dirs] += "${SQSHDIR}"
do_image_tapos_sqshimg[cleandirs] += "${SQSHDIR}"
do_image_tapos_sqshimg[recrdeptask] += "do_deploy"

IMAGE_CMD_tapos-sqshimg() {

	install -d ${SQSHDIR}

I simply replaced the creation command by:

IMAGE_CMD_tapos-sqshimg() {

     SQSHDIR_WORKDIR=$(mktemp -d)

and voilà !
Frederic Martinsons <frederic.martinsons@...>
 

Yes I do, I build under docker (ubuntu 20.04), I didn't mention that in my original post , sorry. Do you think it is related to my issue ?

On Tue, Nov 15, 2022 at 09:06 PM, Tim Orling wrote:

Are you building with a docker/podman container?

On Tue, Nov 15, 2022 at 9:24 AM Frederic Martinsons < frederic.martinsons@...> wrote:

Hello list,

Doesn't ring a bell to anybody ? Even the slightest clue will help me to continue to track down this weird behavior , nobody have ever problem of files/directories rights during image generation ?
Tim Orling
 

Are you building with a docker/podman container?


On Tue, Nov 15, 2022 at 9:24 AM Frederic Martinsons <frederic.martinsons@...> wrote:

Hello list,

Doesn't ring a bell to anybody ? Even the slightest clue will help me to continue to track down this weird behavior , nobody have ever problem of files/directories rights during image generation ?
Frederic Martinsons <frederic.martinsons@...>
 

Hello list,

Doesn't ring a bell to anybody ? Even the slightest clue will help me to continue to track down this weird behavior , nobody have ever problem of files/directories rights during image generation ?
Frederic Martinsons <frederic.martinsons@...>
 

Hello list, 

I currently migrate our project from warrior to dunfell and we experience some issues during the image generation step.
We have a custom IMAGE_FSTYPES to meet our need and in one of our custom steps is to copy the rootfs (populated during yocto do_rootfs step) into a custom dir and act on it (reorganizing tree and making a squash file system).

I'm experiencing an issue on file ownership preservation that I didn't have in warrior.
We use rsync to copy the rootfs tree to another location (via multiple option, including the -a one which preserve ownership) and during that step, I see a lot of:

```
rsync: chown "<MY/DEST/PATH/>" failed: Operation not permitted (1)
```

The files and directories are nevertheless copied (but of course.

To investigate further I do a devshell and reproduce the issue via a simple 'cp -a' (which also preserve ownership of files) and see the same king of ownership preservation problems:

```
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0# ll ${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/bin/arping
-rwxr-xr-x 1 root root 22680 Mar  9  2018 ${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/bin/arping*
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0#
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0# cp -a ${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/bin/arping  .
cp: failed to preserve ownership for './arping': Operation not permitted
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0# ll arping
-rwx------ 1 1000 1000 22680 Mar  9  2018 arping*
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0# id
uid=0(root) gid=0(root) groups=0(root)
```

During devshell'ed session, the rootfs populated by do_rootfs is seen as root user (while the real user is me with uid 1000) , I guess this is due to the fact that the images step is run under pseudo and fakes user/group. What I can't understand is why pseudo (or something else) doesn't do the same with my file copy ?

```
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0# ll ${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/
total 72
drwxr-xr-x 17 root root 4096 Nov  1 05:38 ./
drwxr-xr-x 12 1000 1000 4096 Nov  1 05:38 ../
drwxr-xr-x  2 root root 4096 Mar  9  2018 bin/
drwxr-xr-x  2 root root 4096 Mar  9  2018 boot/
drwxr-xr-x  2 root root 4096 Mar  9  2018 dev/
drwxr-xr-x 38 root root 4096 Nov  1 05:38 etc/
lrwxrwxrwx  1 root root    8 Nov  1 05:38 home -> /rw/home
drwxr-xr-x  8 root root 4096 Mar  9  2018 lib/
lrwxrwxrwx  1 root root   19 Mar  9  2018 linuxrc -> /bin/busybox.nosuid
drwxr-xr-x  2 root root 4096 Mar  9  2018 media/
drwxr-xr-x  2 root root 4096 Mar  9  2018 mnt/
dr-xr-xr-x  2 root root 4096 Mar  9  2018 proc/
drwxr-xr-x  2 root root 4096 Mar  9  2018 run/
drwxr-xr-x  5 root root 4096 Nov  1 05:38 .rw_skeleton/
drwxr-xr-x  2 root root 4096 Mar  9  2018 sbin/
dr-xr-xr-x  2 root root 4096 Mar  9  2018 sys/
-rw-r--r--  1 root root  149 Mar  9  2018 .tapos.manifest
drwxrwxrwt  2 root root 4096 Mar  9  2018 tmp/
drwxr-xr-x 10 root root 4096 Mar  9  2018 usr/
drwxr-xr-x  7 root root 4096 Nov  1 05:38 var/
fmartinsons@SGX-CMP-776:~$ ll ${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/
total 72
drwxr-xr-x 17 fmartinsons fmartinsons 4096 nov.   1 06:38 ./
drwxr-xr-x 12 fmartinsons fmartinsons 4096 nov.   1 06:38 ../
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 bin/
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 boot/
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 dev/
drwxr-xr-x 38 fmartinsons fmartinsons 4096 nov.   1 06:38 etc/
lrwxrwxrwx  1 fmartinsons fmartinsons    8 nov.   1 06:38 home -> /rw/home
drwxr-xr-x  8 fmartinsons fmartinsons 4096 mars   9  2018 lib/
lrwxrwxrwx  1 fmartinsons fmartinsons   19 mars   9  2018 linuxrc -> /bin/busybox.nosuid
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 media/
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 mnt/
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 proc/
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 run/
drwxr-xr-x  5 fmartinsons fmartinsons 4096 nov.   1 06:38 .rw_skeleton/
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 sbin/
drwxr-xr-x  2 fmartinsons fmartinsons 4096 mars   9  2018 sys/
-rw-r--r--  1 fmartinsons fmartinsons  149 mars   9  2018 .tapos.manifest
drwxr-xr-t  2 fmartinsons fmartinsons 4096 mars   9  2018 tmp/
drwxr-xr-x 10 fmartinsons fmartinsons 4096 mars   9  2018 usr/
drwxr-xr-x  7 fmartinsons fmartinsons 4096 nov.   1 06:38 var/
fmartinsons@SGX-CMP-776:~$ id
uid=1000(fmartinsons) gid=1000(fmartinsons) groups=1000(fmartinsons)
```

Am I missing something about pseudo usage ? And if so, why did these copy operations work perfectly within warrior branch ?

Has anyone already experienced this before ? Can someone help me with this issue ?
1 - 5 of 5