On Fri, Jul 3, 2020 at 2:14 PM Richard Purdie <[email protected]> wrote: > > On Tue, 2020-06-23 at 11:01 +0100, Richard Purdie wrote: > > Looking at the pattern, I did have a thought which I've not > > researched > > yet. > > > > Is it possible these are dynamically generated group/users in the > > rootfs which happen to collide with the host user/group? > > > > You'd think the adduser/addgroup calls would happen in a > > deterministic > > order as the rootfs is build but perhaps it doesn't work out like > > that. > > > > Are each of the above groups of files, specifically created users at > > rootfs time? > > At this point this patchset is driving me a bit crazy. I've had it in > master-next, we keep seeing warnings and its hard to know whether the > warnings are real ones or ones from this patch. > > I'm worried that things are not deterministic and this meant I really > needed to investigate. > > I added some fixes and more debug to the patch,
Oh, that's the /home stuff... I looked at that, thought it looked wrong and totally forgot to go back to it :| > then ran it on the > autobuilder again. An example failure is: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/2113 > > WARNING: core-image-sato-sdk-1.0-r0 do_rootfs: Path in the rootfs is owned by > the same user or group as the user running bitbake: /var/spool/cron total 8 > drwxrwx--- 2 0 995 4096 Oct 31 2019 . drwxr-xr-x 4 0 0 4096 Jul 3 12:27 .. > WARNING: core-image-sato-sdk-1.0-r0 do_rootfs: Path in the rootfs is owned by > the same user or group as the user running bitbake: /usr/bin/crontab > -rwxr-sr-x 1 0 995 51544 Oct 31 2019 > /home/pokybuild/yocto-worker/musl-qemux86-64/build/build/tmp/work/qemux86_64-poky-linux-musl/core-image-sato-sdk/1.0-r0/rootfs//usr/bin/crontab > WARNING: core-image-sato-sdk-1.0-r0 do_rootfs: /etc/passwd: > root:x:0:0:root:/home/root:/bin/sh daemon:x:1:1:daemon:/usr/sbin:/bin/sh > bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh > sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh > man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh > mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh > uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh > www-data:x:33:33:www-data:/var/www:/bin/sh > backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List > Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh > gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh > nobody:x:65534:65534:nobody:/nonexistent:/bin/sh > messagebus:x:999:999::/var/lib/dbus:/bin/false rpc:x:998:998::/:/bin/false > rpcuser:x:997:997::/var/lib/nfs:/bin/false > avahi:x:996:996::/run/avahi-daemon:/bin/false > sshd:x:995:994::/var/run/sshd:/bin/false > pulse:x:994:993::/var/run/pulse:/bin/false > WARNING: core-image-sato-sdk-1.0-r0 do_rootfs: /etc/group: root:x:0: > daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: mail:x:8: > news:x:9: uucp:x:10: man:x:12: proxy:x:13: kmem:x:15: input:x:19: > dialout:x:20: fax:x:21: voice:x:22: cdrom:x:24: floppy:x:25: tape:x:26: > sudo:x:27: audio:x:29:pulse dip:x:30: www-data:x:33: backup:x:34: > operator:x:37: list:x:38: irc:x:39: src:x:40: gnats:x:41: shadow:x:42: > utmp:x:43: video:x:44: sasl:x:45: plugdev:x:46: kvm:x:47: staff:x:50: > games:x:60: shutdown:x:70: users:x:100: nogroup:x:65534: messagebus:x:999: > rpc:x:998: rpcuser:x:997: avahi:x:996: crontab:x:995: tracing:x:1000: > sshd:x:994: pulse:x:993:pulse > > On that centos7 worker, the build UID is 6000, the GID is 995. > > As we can see from the dump of /etc/group, crontab is GID 995 and > crontab files owned by that group are fine. So the warning is a false > one and my theory about the cause is confirmed. > > We'd only see the issue where the dynamicly assigned UIDs/GIDs conflict > with the host running the build which explains the intermittent nature. > > I don't know how to fix this. No, I can't think of anything off the top of my head either. I keep coming back to AB configuration, which you can't rely on outside of that environment. > I'm going to batch together the fixes we > have and send those, then drop this patch from master-next until we can > figure out something better to use in testing. > I'll keep thinking about it... -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140295): https://lists.openembedded.org/g/openembedded-core/message/140295 Mute This Topic: https://lists.openembedded.org/mt/75035700/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
