[yocto] Issue with useradd-staticids and sstate-cache

Joshua Watt jpewhacker at gmail.com
Tue May 14 10:33:15 PDT 2019


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 <JPEWhacker at gmail.com>



More information about the yocto mailing list