8759 2015-12-03 21:58:05 +0000 useradd recipes don't re-create accounts in sysroot after base-passwd rebuilds 2015-12-08 23:35:02 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED DUPLICATE 7724 Undecided normal --- 1 haris.okanovic ross.burton meta.mr.watcher meta.watcher --- --- Don't know oldest_to_newest 57018 0 haris.okanovic 2015-12-03 21:58:05 +0000 Recipes using useradd.bbclass to create new user and group accounts in STAGING_DIR_TARGET (the target sysroot) don't re-create their accounts when they rebuild after a clean base-passwd rebuild. A rebuild of base-passwd resets /etc/passwd and /etc/group in the sysroot, but bitbake doesn't seem to propagate this change up to dependent recipes like cronie, which adds more accounts to these files. So if cronie rebuilds after a clean base-passwd build, the sysroot isn't updated with cronie accounts. This can fail other downstream recipes which expect cronie's crontab group to be there by depending on cronie. Reproduction steps, MACHINE=x64: bitbake base-passwd cronie grep crontab tmp-glibc/sysroots/x64/etc/group --> contains a crontab group, as expected bitbake -c cleanall base-passwd bitbake base-passwd grep crontab tmp-glibc/sysroots/x64/etc/group --> missing crontab group, as expected bitbake cronie grep crontab tmp-glibc/sysroots/x64/etc/group --> still missing crontab group Workaround: bitbake -c cleanall cronie bitbake cronie grep crontab tmp-glibc/sysroots/x64/etc/group --> crontab group is back The difference between the second and third builds of cronie appears to be an sstate-cache hit, which doesn't update the sysroot with cronie accounts. 57138 1 haris.okanovic 2015-12-08 23:35:02 +0000 This is a dup of Yocto bug 7724. It's almost the same reproduction case as well, but uses contrived recipes instead of cronie. *** This bug has been marked as a duplicate of bug 7724 ***