Re: [OE-core] [PATCH] useradd: Switch from --root to --prefix option

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2026-04-16 at 13:49 +0100, Richard Purdie via lists.openembedded.org wrote:
> Whilst assessing where we use chroot (which requires superuser privileges),
> I realised that shadow's utilities we use have the option of specifing
> a prefix for files. This provides the same outcome but avoids the chroot
> call. Whist we can emulate that under pseudo, it is probably nicer to avoid
> doing that and use the prefix option instead.
> 
> Therefore switch --root -> --prefix
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes/useradd.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
> index 9d857a4555d..d7ed6cb9315 100644
> --- a/meta/classes/useradd.bbclass
> +++ b/meta/classes/useradd.bbclass
> @@ -26,7 +26,7 @@ SYSROOT=""
>  if test "x$D" != "x"; then
>  	# Installing into a sysroot
>  	SYSROOT="$D"
> -	OPT="--root $D"
> +	OPT="--prefix $D"
>  
>  	# Make sure login.defs is there, this is to make debian package backend work
>  	# correctly while doing rootfs.
> @@ -37,7 +37,7 @@ if test "x$D" != "x"; then
>  	    cp $D${sysconfdir}/login.defs.dpkg-new $D${sysconfdir}/login.defs
>  	fi
>  
> -	# user/group lookups should match useradd/groupadd --root
> +	# user/group lookups should match useradd/groupadd --prefix
>  	export PSEUDO_PASSWD="$SYSROOT"
>  fi

Without the chroot, it is finding /sbin/pam_tally2 on the host and calling it:

ERROR: core-image-sato-sdk-1.0-r0 do_rootfs: [log_check] core-image-sato-sdk: found 6 error messages in the logfile:
[log_check] b'/srv/pokybuild/yocto-worker/qemux86/build/build/tmp/work/qemux86-poky-linux/core-image-sato-sdk/1.0/recipe-sysroot-native/usr/sbin/useradd\n/srv/pokybuild/yocto-worker/qemux86/build/build/tmp/work/qemux86-poky-linux/core-image-sato-sdk/1.0/recipe-sysroot-native/usr/sbin/useradd\nRunning useradd commands...\nNOTE: ptest-runner: Performing useradd with [--prefix /srv/pokybuild/yocto-worker/qemux86/build/build/tmp/work/qemux86-poky-linux/core-image-sato-sdk/1.0/recipe-sysroot --system --no-create-home --home / --user-group ptest]\npam_tally2: Error opening /var/log/tallylog for update: Permission denied\npam_tally2: Authentication error\nuseradd: failed to reset the tallylog entry of user "ptest"\n/srv/pokybuild/yocto-worker/qemux86/build/build/tmp/work/qemux86-poky-linux/core-image-sato-sdk/1.0/recipe-sysroot-native/usr/sbin/useradd\n'
[log_check] pam_tally2: Error opening /var/log/tallylog for update: Permission denied
[log_check] pam_tally2: Error opening /var/log/tallylog for update: Permission denied
[log_check] pam_tally2: Error opening /var/log/tallylog for update: Permission denied
[log_check] pam_tally2: Error opening /var/log/tallylog for update: Permission denied
[log_check] pam_tally2: Error opening /var/log/tallylog for update: Permission denied

https://autobuilder.yoctoproject.org/valkyrie/#/builders/30/builds/3587
https://autobuilder.yoctoproject.org/valkyrie/#/builders/36/builds/3607

This is likely an issue even within the chroot if the binary were
present but of the wrong arch so we'll need to fix this regardless.

The call is from useradd.c:tallylog_reset() in shadow-native.

Cheers,

Richard