[yocto] Issue with useradd-staticids and sstate-cache
Bach, Pascal
pascal.bach at siemens.com
Tue May 14 08:25:38 PDT 2019
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.
2. Is this an sstate bug that should be investigated further?
3. Does somebody know of a solution for this issue beside cleaning the entire sstate cache?
Regards
Pascal
More information about the yocto
mailing list