useradd.bbclass has this in useradd_preinst: export PSEUDO_PASSWD="$SYSROOT:${STAGING_DIR_NATIVE}" But with recipe-specific-sysroots the STAGING_DIR_NATIVE is in the *recipe* work directory, and may well not exist if the packages were taken from sstate or rm_work is enabled.
Concrete example: dbus pkg_preinst has this line: export PSEUDO_PASSWD="$SYSROOT:/data/poky-master/tmp/work/corei7-64-poky-linux/dbus/1.10.14-r0/recipe-sysroot-native"
which is used/called as part of -c populate_sdk_ext :(
Moving my comments from the duplicate bug I filed before finding this one and closing mine:. My comments, moved: The path to pseudo-native/usr/bin/pseudo used by useradd is populated from sstate. This means if the build dir is different from the build dir that was used to generate the sstate, the useradd command will fail. One place this happens is "$bitbake <image> -c populate_sdk_ext" . This tries to do a groupadd for dbus and fails. This bug is being opened by me for tracking/discussion, there is a patch already available that seems to fix it in my testing, from Peter Kjellerstedt . His patch is https://patchwork.openembedded.org/series/6598/ . His comments on the patch cover letter: Similar to the problem with the hosttools directory and the state cache that was recently fixed, there is another problem with the sysroots-components directory. This only affects postinst-useradd scripts, so in this case the fix can be activated from useradd.bbclass rather than sstate.bbclass and thus affects a lot less recipes. Also, from Jose: Bug 11497 created to add a test case for this scenario
*** Bug 11489 has been marked as a duplicate of this bug. ***
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=eb30ca2b316076e83e1a709015863670946d5bee