linux/poky.git/meta/classes/useradd.bbclass, branch yocto-3.1.19

useradd: Ensure preinst data is expanded correctly in pkgdata

2021-09-29T23:02:22+00:00

The preinst data in pkgdata will not expand out the ${XXX_PARAM} variables since they don't use a package suffix. It happens that the final expansion used for the packages is corrected by a second trip through the datastore. The first version is used for calculation of the task output hash and recent improvements in hash reuse showed this data wasn't using included in the hashes, meaning for example builds with dynamic IDs were mixing sstate with builds using static IDs. The result was a mess. Fix this by expanding the data in the preinst correctly to use the package specific _PARAM values. (From OE-Core rev: fbd5a1f877d805d810562985c7a5dac4a5761263) Signed-off-by: Richard Purdie (cherry picked from commit 375430f249e7e0b6622e566e2478b40ba7e606ab) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

useradd: Ensure do_populate_sysroot has dependency on useradd variables

2019-06-01T10:27:06+00:00

The do_populate_sysroot task doesn't rerun if you change any of the USERADD_PARAM or GROUPADD_PARAM variables, only do_package will. If another task depends on the recipe, this means it won't see any updated changes. This patch adds in the missing vardeps ensuring the code is deterministic. [YOCTO #13232] (From OE-Core rev: 37d0382a3c67f47f8cfdd977a041069bf912b8c3) Signed-off-by: Richard Purdie

useradd: Fix build architecture corruption of sstate artefacts

2019-05-31T14:36:20+00:00

When mixing aarch64 and x86_64 host builds with common sstate, useradd failures were found. This was due to references to: /home/pokybuild/yocto-worker/qemuarm/build/build/tmp/sysroots-components/aarch64/pseudo-native/usr/bin/pseudo or /home/pokybuild/yocto-worker/qemuarm/build/build/tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo on the wrong architecture within the useradd postinst files. Instead of using COMPONENTS_DIR as the FIXME, use PSEUDO_SYSROOT which contains the arch component as well to avoid this. Add extra comments to cause the relavent sstate to be rebuilt. (From OE-Core rev: 0384622f72a6c0bd8225cf06f692340fdef67d4a) Signed-off-by: Richard Purdie

useradd.bbclass: print a warn when useradd not found

2017-11-07T13:30:22+00:00

Exit quietly makes it very hard for debugging when user is not added as expected, print a warning helps a lot. (From OE-Core rev: 057885ed6f22781960bce4e082e3aa96e126764c) Signed-off-by: Robert Yang Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

staging.bbclass: handle postinst-useradd-* fixmes

2017-10-07T22:20:40+00:00

After 02457ef7f600ce954874e2d11e74b1c6daaa3bfc, PSEUDO for postinst-useradd-* scripts get to use only one PSEUDO_LOCALSTATEDIR which is set under recipes ${WORKDIR}. When the those scripts are run in a clean build environment that is built from the sstate (populate_sysroot_setscene run for postinst-useradd-* providers), pseudo fails to run because it cannot access the PSEUDO_LOCALSTATEDIR (recipe ${WORKDIR}s do not exist). This triggers a sysroot staging error. Previously, the PSEUDO_LOCALSTATEDIR setting in useradd.bbclass worked because the RSS sstate/staging logic automagically processed ${STAGING_DIR_TARGET} in postinst-useradd-* scripts to point under the sysroot being built. The fix uses the same fixme processing by adding PSEUDO_LOCALSTATEDIR variable to it. Furthermore, LOGFIFO is added to be able to use the logging fifo of the recipe that actually runs postinst-useradd-*. (From OE-Core rev: b28374cfad37db161b5ac5953b4a4638912f3f27) Signed-off-by: Mikko Ylinen Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd.bbclass: Unify writing of script file in useradd_sysroot_sstate()

2017-09-18T10:07:30+00:00

There were two identical code blocks for writing the postinst-useradd-${PN} scripts. This combines them into one. (From OE-Core rev: 0c4259dd3c74d81f20b87417cecb1e636365ce10) Signed-off-by: Peter Kjellerstedt Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd: don't override pseudo environment

2017-09-18T10:07:30+00:00

Back in the dark days before recipe-specific-sysroots the paths being passed in this manual construction of the pseudo environment made sense, but now they're incorrect and result in pseudo writing to two different databases during a single build. The result is that pseudo doesn't follow changes to /etc/passwd in the sysroot, and warns in the logs. Remove the PSEUDO_LOCALSTATEDIR assignment and inherit the correct assignment in FAKEROOTENV. (From OE-Core rev: 02457ef7f600ce954874e2d11e74b1c6daaa3bfc) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

useradd: remove preinst script referring to recipe sysroot

2017-05-11T15:56:00+00:00

Remove recipe-specific-sysroot details from the preinst scripts generated by useradd.bbclass. This was added to match the default from bitbake.conf. Unlike the default case, the dependencies used by useradd mean that a default passwd/group file is always present. This means we don't need the native sysroot fallback. Fixes [YOCTO #11460] (From OE-Core rev: dfc9323c1cd7814989766be5bd1861fbaa739d2d) Signed-off-by: Maxin B. John Signed-off-by: Richard Purdie

useradd.bbclass: Handle COMPONENTS_DIR when restoring state

2017-05-11T15:56:00+00:00

The export of PSEUDO in useradd_sysroot() contains references to ${COMPONENTS_DIR}. These need to be handled when restoring postinst-useradd-${PN} from the sstate cache. (From OE-Core rev: 097875bc9ab9d60a452b01ac6825775983684d68) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

base-passwd/useradd: Various improvements to useradd with RSS

2017-04-14T08:47:08+00:00

Currently there are multiple issues with useradd: * If base-passwd rebuilds, it wipes out recipe specific user/group additions to sysroots and causes errors * If recipe A adds a user and recipe B depends on A, it can't see any of the users/groups A adds. This patch changes base-passwd so it always works as a postinst script within the sysroot and copies in the master files, then runs any postinst-useradd-* scripts afterwards to add additional user/groups. The postinst-useradd-* scripts are tweaked so that if /etc/passwd doesn't exist they just exit, knowning they'll be executed later. We also add a dummy entry to the dummy passwd file from pseudo so we can avoid this too. There is a problem where if recipe A adds a user and recipe B depends on A but doesn't care about users, it may not have a dependency on the useradd/groupadd tools which would therefore not be available in B's sysroot. We therefore also tweak postinst-useradd-* scripts so that if the tools aren't present we simply don't add users. If you need the users, you add a dependency on the tools in the recipe and they'll be added. We add postinst-* to SSTATE_SCAN_FILES since almost any postinst script of this kind is going to need relocation help. We also ensure that the postinst-useradd script is written into the sstate object as the current script was only being added in a recipe local way. Thanks to Peter Kjellerstedt and Patrick Ohly for some pieces of this patch. [Yocto #11124] (From OE-Core rev: 1b5afaf437f7a1107d4edca8eeb668b9618a5488) Signed-off-by: Richard Purdie