Living without shadow
Any package that wants to add user accounts (e.g. dbus) automatically installs the "shadow" package into the image. This appears to be done by adduser.bbclass.
We want to keep it small, and can easily live without the shadow package. Busybox already provides adduser and similar commands, and also handles login etc. just fine. So I tried adding a line RPROVIDES_busybox+="shadow"
to the busybox recipe. I would expect to have an alternative provider now, and no more forces installation of the big shadow.
The result was much more surprising though. Letting busybox provide "shadow" resulted in failing to build the rootfs. The "adduser" command did not work on the host. This was very unexpected - does shadow deliver something into the sysroot that adduser.bbclass needs?
How can I get rid of the shadow package?
Signature · 1 line
Mike Looijmans
Quoted 11 lines · Mike Looijmans
Any package that wants to add user accounts (e.g. dbus) automatically installs the "shadow" package into the image. This appears to be done by adduser.bbclass.
We want to keep it small, and can easily live without the shadow package. Busybox already provides adduser and similar commands, and also handles login etc. just fine. So I tried adding a line RPROVIDES_busybox+="shadow"
to the busybox recipe. I would expect to have an alternative provider now, and no more forces installation of the big shadow.
Quoted 7 lines
The result was much more surprising though. Letting busybox provide "shadow" resulted in failing to build the rootfs. The "adduser" command did not work on the host. This was very unexpected - does shadow deliver something into the sysroot that adduser.bbclass needs?
How can I get rid of the shadow package?
Lets expand that briefly, from the current version of useradd.bbclass:
DEPENDS_append = "${USERADDDEPENDS}"
USERADDDEPENDS = " base-passwd shadow-native shadow-sysroot shadow" USERADDDEPENDS_class-cross = "" USERADDDEPENDS_class-native = "" USERADDDEPENDS_class-nativesdk = ""
What this does is for target packages, base-passwd [the password file], shadow-native [tools needed to configure passwords at install time], shadow-sysroot [shadow components needed to update the sysroot, and shadow [target utilities] are added to the -depends-.
The DEPENDS are only build-time requirements, not runtime.
The system further requires RDEPENDS:
# RDEPENDS setup
rdepends = d.getVar("RDEPENDS_%s" % pkg, True) or "" rdepends += ' ' + d.getVar('MLPREFIX') + 'base-passwd' rdepends += ' ' + d.getVar('MLPREFIX') + 'shadow' # base-files is where the default /etc/skel is packaged rdepends += ' ' + d.getVar('MLPREFIX') + 'base-files' d.setVar("RDEPENDS_%s" % pkg, rdepends)
For any package that has a call to a groupadd, useradd or groupmems, those dependencies are added. We can't install the package onto the target without base-passwd (passwd/group file), shadow (utilities needed by the package install scripting) and base-files (/etc/skel is needed to add new users) being installed.
So with that said, what is required in the end is something that honors the necessary 'groupadd', 'useradd' and 'groupmems' executables. If bitbake can provide them, then your RPROVIDES_busybox = "shadow" should work fine. (bitbake also provides 'su', may provide 'login', and 'chpasswd'.)
If you are getting rootfs creation issues, then I need a reference to the error messages to have an idea of what may be needed.
--Mark
Quoted 51 lines · Mark Hatle
Quoted 11 lines · Mike Looijmans
Any package that wants to add user accounts (e.g. dbus) automatically installs the "shadow" package into the image. This appears to be done by adduser.bbclass.
We want to keep it small, and can easily live without the shadow package. Busybox already provides adduser and similar commands, and also handles login etc. just fine. So I tried adding a line RPROVIDES_busybox+="shadow"
to the busybox recipe. I would expect to have an alternative provider now, and no more forces installation of the big shadow.Quoted 7 lines
The result was much more surprising though. Letting busybox provide "shadow" resulted in failing to build the rootfs. The "adduser" command did not work on the host. This was very unexpected - does shadow deliver something into the sysroot that adduser.bbclass needs?
How can I get rid of the shadow package?
Lets expand that briefly, from the current version of useradd.bbclass:
DEPENDS_append= "${USERADDDEPENDS}"
USERADDDEPENDS = " base-passwd shadow-native shadow-sysroot shadow" USERADDDEPENDS_class-cross = "" USERADDDEPENDS_class-native = "" USERADDDEPENDS_class-nativesdk = ""What this does is for target packages, base-passwd [the password file], shadow-native [tools needed to configure passwords at install time], shadow-sysroot [shadow components needed to update the sysroot, and shadow [target utilities] are added to the -depends-.
The DEPENDS are only build-time requirements, not runtime.
The system further requires RDEPENDS:
# RDEPENDS setup
rdepends =d.getVar("RDEPENDS_%s" % pkg, True)or "" rdepends += ' ' +d.getVar('MLPREFIX')+ 'base-passwd' rdepends += ' ' +d.getVar('MLPREFIX')+ 'shadow' # base-files is where the default/etc/skelis packaged rdepends += ' ' +d.getVar('MLPREFIX')+ 'base-files'd.setVar("RDEPENDS_%s" % pkg, rdepends)For any package that has a call to a groupadd, useradd or groupmems, those dependencies are added. We can't install the package onto the target without base-passwd (passwd/group file), shadow (utilities needed by the package install scripting) and base-files (
/etc/skelis needed to add new users) being installed.
Quoted 9 lines
So with that said, what is required in the end is something that honors the necessary 'groupadd', 'useradd' and 'groupmems' executables. If bitbake can provide them, then your
RPROVIDES_busybox= "shadow" should work fine. (bitbake also provides 'su', may provide 'login', and 'chpasswd'.)If you are getting rootfs creation issues, then I need a reference to the error messages to have an idea of what may be needed.
At the end I see this:
Collected errors:
* preinst_configure: Aborting installation of dbus-1.
* opkg_install_cmd: Cannot install package libavahi-client3.
* preinst_configure: Aborting installation of rpcbind.
* opkg_install_cmd: Cannot install package packagegroup-base.
* preinst_configure: Aborting installation of rpcbind.
* opkg_install_cmd: Cannot install package nfs-utils-client.
* preinst_configure: Aborting installation of avahi-daemon.
* opkg_install_cmd: Cannot install package avahi-daemon.
The logs seems to be "interlaced", but here's a summary of the things I cound find. If you want, I can send the full log.
Downloading file:/media/work/openpli-next/build/tmp/deploy/ipk/mips32el/base-passwd_3.5.29-r0_mips32el.ipk.
Removing any system startup links for dbus-1 ...
Running groupadd commands...
NOTE: Performing groupadd with [--root /media/work/openpli-next/build/tmp/work/et10000-oe-linux/my-image/1.0-r0/rootfs -r netdev] and 10 times of retry
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
WARNING: groupadd command did not succeed. Retrying...
ERROR: Tried running groupadd command 10 times without scucess, giving up
Removing any system startup links for rpcbind ...
Running useradd commands...
NOTE: Performing useradd with [--root /media/work/openpli-next/build/tmp/work/et10000-oe-linux/my-image/1.0-r0/rootfs --system --no-create-home --shell /bin/false --user-group rpc] and 10 times of retry
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
WARNING: useradd command did not succeed. Retrying...
ERROR: Tried running useradd command 10 times without scucess, giving up
Signature · 1 line
Mike Looijmans