Issue metadata
Sign in to add a comment
|
enewgroup function fails to create user in /etc/group if it exists in /build/$BOARD/etc/group |
||||||||||||||||||||||||
Issue descriptionCode: https://cs.corp.google.com/chromeos_public/src/third_party/eclass-overlay/eclass/user.eclass?rcl=590ac1932044a530115017ceae64cb57ceadbc69&l=414 Calling enewgroup in .ebuild file should create that group in /etc/group, even if that group already exists in /build/$BOARD/etc/group. Currently this is not the case, causing emerge-$BOARD calls to fail when the .ebuild file needs to reference a group that already exists in the system. P.S. not sure if only non-cros-workonable .ebuild files go off of /etc/group rather than /build/$BOARD/etc/group P.P.S. not sure if the same problem exists for enewuser
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/e53449ac8dd22ac152661751546834fa146298e2 commit e53449ac8dd22ac152661751546834fa146298e2 Author: Micah Morton <mortonm@chromium.org> Date: Fri Apr 20 19:57:12 2018 Skip checks for user/group existence in user.eclass These checks cause enewuser/enewgroup calls to fail if the user/group already exists in the board sysroot but not in the sdk root. Sometimes users/groups need to be created in the sdk root when they already exist in the board sysroot. For example, in order to chown a file to user 'shill' in the ebuild for strongswan, 'shill' group needs to be created in the sdk root at the same time that it already exists in the board sysroot. This situation arises because the shill ebuild creates the shill user/group during pkg_preinst() (so they are created in the board sysroot only) but the strongswan ebuild needs to create the shill group during pkg_setup() (which creates the group in the sdk root as well). _write_entry_to_db() checks whether entries in the group or passwd file exists before adding the entries, so these checks are not necessary in the first place. BUG= chromium:834445 TEST=before: cannot reference shill group in ebuild for strongswan, even after calling enewgroup, after: can reference shill group Change-Id: I2f1f9400ab8d9be615bdb56279ebddf4926b2557 Reviewed-on: https://chromium-review.googlesource.com/1017860 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Micah Morton <mortonm@chromium.org> Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/e53449ac8dd22ac152661751546834fa146298e2/eclass/user.eclass
,
Apr 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/03e44fde2b50b9be9cd7c0b7c39ea7abf5543f88 commit 03e44fde2b50b9be9cd7c0b7c39ea7abf5543f88 Author: Manoj Gupta <manojgupta@chromium.org> Date: Sun Apr 22 10:54:35 2018 Revert "Skip checks for user/group existence in user.eclass" This reverts commit e53449ac8dd22ac152661751546834fa146298e2. Reason for revert: Breaking chromiumos-sdk builder. https://uberchromegw.corp.google.com/i/chromiumos/builders/chromiumos-sdk/builds/8715 BUG= chromium:835616 Original change's description: > Skip checks for user/group existence in user.eclass > > These checks cause enewuser/enewgroup calls to fail if the user/group > already exists in the board sysroot but not in the sdk root. Sometimes > users/groups need to be created in the sdk root when they already exist > in the board sysroot. For example, in order to chown a file to user > 'shill' in the ebuild for strongswan, 'shill' group needs to be created > in the sdk root at the same time that it already exists in the board > sysroot. This situation arises because the shill ebuild creates the > shill user/group during pkg_preinst() (so they are created in the board > sysroot only) but the strongswan ebuild needs to create the shill > group during pkg_setup() (which creates the group in the sdk root as > well). > > _write_entry_to_db() checks whether entries in the group or passwd file > exists before adding the entries, so these checks are not necessary in > the first place. > > BUG= chromium:834445 > TEST=before: cannot reference shill group in ebuild for strongswan, even > after calling enewgroup, after: can reference shill group > > Change-Id: I2f1f9400ab8d9be615bdb56279ebddf4926b2557 > Reviewed-on: https://chromium-review.googlesource.com/1017860 > Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> > Tested-by: Micah Morton <mortonm@chromium.org> > Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> > Reviewed-by: Mike Frysinger <vapier@chromium.org> Bug: chromium:834445 Change-Id: Id6e5ba1da72b16f7258ad486c335b7fed4c00327 Reviewed-on: https://chromium-review.googlesource.com/1023163 Commit-Ready: Manoj Gupta <manojgupta@chromium.org> Tested-by: Manoj Gupta <manojgupta@chromium.org> Reviewed-by: Manoj Gupta <manojgupta@chromium.org> [modify] https://crrev.com/03e44fde2b50b9be9cd7c0b7c39ea7abf5543f88/eclass/user.eclass
,
Apr 22 2018
Unfortunately, I had to revert this CL because it caused chromiumos-sdk builder to fail. Please, test changes that affect SDK with a chromiumos-sdk tryjob. Or to repro locally, use $ cros_sdk --bootstrap
,
Jun 5 2018
,
Aug 13
I've run into the same issue (see https://crbug.com/873164 ) and I'm trying a slightly different fix (see CL:1170839). cros_sdk --bootstrap doesn't seem to do anything (with or without the patch). I've run the chromiumos-sdk tryjob: https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8938305666688756640 How exactly did it fail? It's been running for a while now and so far no failure, but it seems to be taking an inappropriate amount of time:
,
Aug 13
I think the answer here is extremely simple even though it took me a while to figure out. When emerging a package to the SDK root (a.k.a. in pkg_setup) you need to do 'sudo emerge <package>' instead of 'emerge-$BOARD <package>'. That's what fixed this for me anyway.
,
Aug 13
I'll try to page the rest of this topic back in if there's more to this and that doesn't fix it. I spent an embarrassing amount of time on it so I definitely have the context if we need to discuss further.
,
Aug 13
I think I already tried what you're doing in CL:1170839: https://chromium-review.googlesource.com/c/chromiumos/overlays/eclass-overlay/+/1048309
,
Aug 14
,
Aug 14
Re #7:
Alternatively,
nano /build/${board}/etc/passwd (or group)
and remove the entry, then emerge-${BOARD} your project.
But will this work on the buildbots as well? I'm concerned that the CL would break any bots that don't rebuild everything from scratch every time.
Re #10:
Ah yes, that's almost equivalent to my CL. My CL does a little more conservative and won't put stuff into passwd or group if it's already there.
,
Aug 22
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by mortonm@chromium.org
, Apr 18 2018