Yocto useradd completes but no user added to /etc/passwd

Question

I am trying to add a user to an inherited Yocto Kirkstone image build. I have added a recipe in

<my-layer>/recipes-core/example-user/example-user.bb

SUMMARY = "Add a nonroot user who has docker permissions"
LICENSE = "CLOSED"

inherit useradd
DEPENDS = "docker-ce"

USERADD_PACKAGES = "${PN}"
USERADD_PARAM:${PN} = "-u 1200 -s /bin/sh -G docker,dialout -m exampleuser"

BB_DONT_CACHE = "1"

In my build/local.conf I have:

IMAGE_INSTALL:append = " \
    example-user \
    docker \
    python3-docker-compose \
    eth0-static-ip \
    mount-or-fix-data-partition \
    run-startup-script \
"

I know that the recipe is being run because if I add bogusgroup to the list of groups in the USERADD_PARAM:${PN} line, bitbake fails with the expected group does not exist error. However, when I run the image and cat /etc/passwd, the user is not there.

@MikeBergmann asked if I checked log.do_rootfs. Indeed it looks like not all is well there, however I don't see an indication of what the actual problem was. Full output of the add users task:

NOTE: Executing systemd_create_users ...
DEBUG: Executing shell function systemd_create_users
configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)
configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)
Usage: useradd [options] LOGIN
       useradd -D
       useradd -D [options]

Options:
      --badnames                do not check for bad names
  -b, --base-dir BASE_DIR       base directory for the home directory of the
                                new account
      --btrfs-subvolume-home    use BTRFS subvolume for home directory
  -c, --comment COMMENT         GECOS field of the new account
  -d, --home-dir HOME_DIR       home directory of the new account
  -D, --defaults                print or change default useradd configuration
  -e, --expiredate EXPIRE_DATE  expiration date of the new account
  -f, --inactive INACTIVE       password inactivity period of the new account
  -g, --gid GROUP               name or ID of the primary group of the new
                                account
  -G, --groups GROUPS           list of supplementary groups of the new
                                account
  -h, --help                    display this help message and exit
  -k, --skel SKEL_DIR           use this alternative skeleton directory
  -K, --key KEY=VALUE           override /etc/login.defs defaults
  -l, --no-log-init             do not add the user to the lastlog and
                                faillog databases
  -m, --create-home             create the user's home directory
  -M, --no-create-home          do not create the user's home directory
  -N, --no-user-group           do not create a group with the same name as
                                the user
  -o, --non-unique              allow to create users with duplicate
                                (non-unique) UID
  -p, --password PASSWORD       encrypted password of the new account
  -r, --system                  create a system account
  -R, --root CHROOT_DIR         directory to chroot into
  -P, --prefix PREFIX_DIR       prefix directory where are located the /etc/* files
  -s, --shell SHELL             login shell of the new account
  -u, --uid UID                 user ID of the new account
  -U, --user-group              create a group with the same name as the user

groupadd: GID '65534' already exists
configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)
configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)
useradd: invalid user ID '65534:65534'
groupadd: group 'adm' already exists
configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)
configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)
groupadd: group 'utmp' already exists
groupadd: group 'audio' already exists
groupadd: group 'cdrom' already exists
groupadd: group 'dialout' already exists
groupadd: group 'disk' already exists
groupadd: group 'input' already exists
groupadd: group 'kmem' already exists
groupadd: group 'kvm' already exists
groupadd: group 'lp' already exists
groupadd: group 'render' already exists
configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)
configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)
groupadd: group 'tape' already exists
groupadd: group 'tty' already exists
groupadd: group 'video' already exists
groupadd: group 'users' already exists
configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)
configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)
useradd: user 'messagebus' already exists
groupadd: group 'systemd-journal' already exists
configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)
configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)
useradd: user 'systemd-network' already exists
configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)
configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)
useradd: user 'systemd-resolve' already exists
configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)
configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)
useradd: user 'systemd-timesync' already exists
DEBUG: Shell function systemd_create_users finished

EDIT 2024-03-11

Looking further into the SYSLOG_SU_ENAB message, it appears to be from the shadow recipe. It doesn't look like it would cause a command failure, just interfere with logging.

#
# Enable "syslog" logging of su(1) activity - in addition to sulog file logging.
# SYSLOG_SG_ENAB does the same for newgrp(1) and sg(1).
#
SYSLOG_SU_ENAB      yes
SYSLOG_SG_ENAB      yes

Further edit, 2024-03-11: I have also confirmed that the error above occurs even when my recipe is not present.

Looking further, it appears that during the build process, the recipe is turned into a series of do_ scripts in the directory

/home/jenkins/oe-core/build/tmp/work/cortexa72-cortexa53-tdx-linux/example-user/1.0-r0/recipe-sysroot/temp/ of which the relevant script is

/home/jenkins/oe-core/build/tmp/work/cortexa72-cortexa53-tdx-linux/example-user/1.0-r0/temp/run.useradd_sysroot.3752244

This contains the following bash function:

# line: 30, file: /home/jenkins/oe-core/build/../layers/openembedded-core/meta/classes/useradd_base.bbclass
perform_useradd() {
        local rootdir="$1"
        local opts="$2"
        bbnote "example-user: Performing useradd with [$opts]"
        local username=`echo "$opts" | awk '{ print $NF }'`
        local user_exists="`grep "^$username:" $rootdir/etc/passwd || true`"
        if test "x$user_exists" = "x"; then
                eval flock -x $rootdir/etc -c  \"$PSEUDO useradd \$opts\" || true
                user_exists="`grep "^$username:" $rootdir/etc/passwd || true`"
                if test "x$user_exists" = "x"; then
                        bbfatal "example-user: useradd command did not succeed."
                fi
        else
                bbnote "example-user: user $username already exists, not re-creating it"
        fi
}

This function determines success by grepping a /etc/passwd file and making sure that the username is present. However the /etc/passwd file appears to be local to the recipe directory:

/home/jenkins/oe-core/build/tmp/work/cortexa72-cortexa53-tdx-linux/example-user/1.0-r0/recipe-sysroot/etc/passwd

When the build completes this etc/passwd file no longer exists.