On Tue, 2019-05-14 at 15:25 +0000, Bach, Pascal wrote: > Hello > > We ran into an issue when trying to switch to useradd-staticids that > looks like it could be a bug with sstate. We are running thud. > > The issue appeared on our CI builds which have a shared sstate-cache > (SSTATE_DIR) but otherwise start with a clean build (no tmp > directory). > > We tried to add static user ids by setting USERADDEXTENSION = > "useradd-staticids" and providing the required passwd and group > files. > Locally everything worked fine. > > But the CI servers produced the following error: > > DEBUG: Executing shell function useradd_sysroot > /build/tmp/work/corei7-64-ccp-linux/dbus/1.12.10-r0/recipe-sysroot- > native/usr/sbin/useradd > Running groupadd commands... > NOTE: dbus: Performing groupadd with [--root /build/tmp/work/corei7- > 64-ccp-linux/dbus/1.12.10-r0/recipe-sysroot --gid 998 --system > netdev] > groupadd: GID '998' already exists > ERROR: dbus: groupadd command did not succeed. > > Looking at the /etc/group file in recipes-sysroot it contains: > > systemd-network:!:998: > > which obviously conflicts with what we have set in our static user > group: > > netdev:x:998: > systemd-network:x:994: > > Looking at the logs I think the recipe-sysroots is coming from sstate > cache (via do_populate_sysroot_setscene task). > > When running the same build with static user ids on the same CI > server with a different (empty) SSTATE_DIR everything works. > > Now I have several questions regarding this: > 1. Is switching to static user ids without cleaning sstate cache a > supported uses case? The documentation mentions deleting TMPDIR but > it doesn't mention sstate.
FWIW, I think when we switch to static user IDs (a long while ago) we had to delete everything; it was a pain. We never switched back, so I don't have any experience with more recent versions. > 2. Is this an sstate bug that should be investigated further? I believe this is captured by this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12107 > 3. Does somebody know of a solution for this issue beside cleaning > the entire sstate cache? > > Regards > Pascal -- Joshua Watt <jpewhac...@gmail.com> -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
