Basically I expect that USERADD_ERROR_DYNAMIC = "error" And USERADD_ERROR_DYNAMIC = "warn" Will do 99% the same thing as each other - one gives warnings and one gives errors, but the _list_ of missing userIds and groupdIds being listed as warnings or errors should be the same. Instead I see that the lists are completely different. Building with empty group/passwd files: "warn" warns about 16 missing userIds and 22 missing groupIds in various recipes "error" errors about 2 missing userIds and 1 missing groupId in the 'dbus' recipe. After these entries are added to the group/passwd files, no other errors are thrown from any other recipe. To reproduce: git clone git://git.yoctoproject.org/poky poky_sumo cd poky_sumo git checkout sumo source oe-init-build-env cat > useradd_error.conf << EOF USERADD_ERROR_DYNAMIC = "error" USERADDEXTENSION = "useradd-staticids" USERADD_UID_TABLES = "./passwd" USERADD_GID_TABLES = "./group" EOF cat > group << EOF messagebus:x:994: netdev:x:995: EOF cat > passwd << EOF messagebus:x:995::::: EOF bitbake core-image-minimal -r useradd_error.conf # No errors are thrown, build completes. Expected to get errors on missing userId / groupId like 'dhcp', 'rpc' 'sshd' etc # If files 'passwd' and 'group' are empty, dbus recipe throws errors. No other recipes are observed to throw errors # If instead of USERADD_ERROR_DYNAMIC = "error" you set ="warn" and rebuild from clean, then warnings are thrown for ~16 missing userIds & ~22 missing groupIds # poky 'morty' throws errors as expected on many recipes. 'pyro' through sumo & master do not as of 24 Sept 2018
(I had not noticed that I had been assigned to this, hence the late answer.) I believe this is working as intended, even though the result may be a bit confusing at first. When USERADD_ERROR_DYNAMIC is set to "warn", it will report all user/group IDs that do not have any static IDs assigned for all recipes in all layers. However, when it is set to "error", it will only fail with an error for those recipes that are actually built. This saves you from having to add static IDs for all those recipes you know you will never build. If you add a bb.warn(msg) before raise NotImplementedError(msg) in the handle_missing_id() function in useradd-staticids.bbclass, you should see all the warnings during parsing, and later the errors during build. What we could do, I guess, is to update the documentation to clarify the behavior.
Hi Peter, You say > When USERADD_ERROR_DYNAMIC is set to "warn", it will report all user/group IDs that do not have any static IDs assigned for all recipes in all layers. However, when it is set to "error", it will only fail with an error for those recipes that are actually built. Ok yes thanks for explaining the difference between "all recipes" and "all recipes that are actually built". But I think that still matches the behavior I expect, which isn't the behavior I see. My problem is that building poky core-image-minimal creates /etc/passwd and /etc/group with 16-20 entries. If I create static files with only 2 entries, and turn on USERADD_ERROR_DYNAMIC="error", I expect to see the other (missing static id values) 14-18 entries in /etc/passwd and /etc/group cause build errors. The generated /etc/passwd and /etc/group entries are only for the recipes being built, right? There's obviously some confusion here. What am I not understanding? :-)
Ah, you are probably thinking of the default users and groups installed by base-passwd, e.g., root, daemon, bin, sys, etc. They have static IDs from the upstream Debian package. After building base-passwd, you can find the default users in tmp/sysroots-components/core2-64/base-passwd/usr/share/base-passwd/passwd.master (assuming you build for qemux86-64). Those should match the users you saw in /etc/passwd.
Ah.... yes you are right. I didn't know those userids and groupids were static from the upstream packages! I have been re-testing with thud and you are absolutely correct. SO sorry to have wasted your time! Please close this bug as stupid-user-misunderstanding.
Nah, it's not stupid. Even though the functionality is correct, the documentation can obviously be improved.
Could someone send a patch to clarify the docs so we could close this?
Long, long overdue, but I just sent a patch to yocto@lists.yoctoproject.org to update the documentation for USERADD_ERROR_DYNAMIC.
The update to the manual is now integrated.