Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 113298 - man fails due to missing shadow for adding users/groups
Summary: man fails due to missing shadow for adding users/groups
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Release Media
Classification: Unclassified
Component: Everything (show other bugs)
Hardware: All Linux
: High blocker (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 113299 121807 127157 128999 129255 129951 132947 133281 367915 (view as bug list)
Depends on:
Blocks: 119737
  Show dependency tree
 
Reported: 2005-11-22 15:52 UTC by Rafael
Modified: 2011-07-02 12:51 UTC (History)
16 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge info (emerge-info,2.56 KB, text/plain)
2005-11-23 09:54 UTC, Rafael
Details
baselayout-1.11.14-users.patch (baselayout-1.11.14-users.patch,890 bytes, patch)
2006-02-14 08:35 UTC, Chris Gianelloni (RETIRED)
Details | Diff
patch catalyst to install shadow along with baselayout (stage1-chroot.sh.patch,456 bytes, patch)
2011-05-19 22:17 UTC, Zac Medico
Details | Diff
patch bootstrap.sh to install shadow in stage1 (bootstrap.sh.patch,1.15 KB, patch)
2011-05-19 23:15 UTC, Zac Medico
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael 2005-11-22 15:52:31 UTC
Migration between different CHOSTs during a stage 1/2 installation
when doing emerge -e system. This bug seems to affect mainly autoconf-2.59
and cronbase.
Autoconf fails because of Perl not being recompiled before it (Data::Dumper 
module is not found) and cronbase because there is no functional Shadow for 
adding the user/group.

To work around this bug, a change in dependencies should be done, so that the 
order of affected packages is :
perl -> shadow -> cronbase

The respective dependencies get pulled in in right order too.

Reproducible: Always
Steps to Reproduce:
1.decide to make a stage 1/2 installation
2.change CHOST value
3.emerge -e system (evtl. after successful bootstrap if stage1 install)

Actual Results:  
emerge -e system breaks at cronbase. even if this one gets injected externally 
with ROOT="..." set, autoconf-2.59 will fail because of not-found perl module

Expected Results:  
all steps from stage1 throughout the installation until a reboot should run 
flawlessly
Comment 1 roger55 (RETIRED) gentoo-dev 2005-11-22 16:07:59 UTC
*** Bug 113299 has been marked as a duplicate of this bug. ***
Comment 2 Chris Gianelloni (RETIRED) gentoo-dev 2005-11-23 04:38:21 UTC
No need to CC me when I told you where to assign it.  Also, no need for a
blocker... well... pretty much ever.  The only time we consider something a
"blocker" is when it means "Oh dear God, we need to roll out a new release
because of this *NOW*" type of thing.

I'll get to this today.  I honestly didn't have much time to work on Gentoo last
night.
Comment 3 Rafael 2005-11-23 04:45:18 UTC
Sorry for this, won't happen again...

Comment 4 Rafael 2005-11-23 06:12:07 UTC
(In reply to comment #0)

Apparently, the problem is a missing dependency in the depgraph
concerning dependencies of cronbase, or more precisely eutils.

Reasons for NOT adding shadow to eutils dependencies is more or less elaborated 
in bug #94745, see comment 5 + 6...

I think cronbase maintainer should be bugged to add the dep, as this might solve
all problems regarding CHOST issue with stage1/2 installs, life of releng people 
would certainly get a little less stressful too.

I didn't CC no one this time, someone more appropriate should do it ;)
Comment 5 Rafael 2005-11-23 09:54:41 UTC
Created attachment 73440 [details]
emerge info

This is emerge info from my main system, although it is
not built upon the stages i have tested the above behaviours on.

The interesting thing might be my catalyst version: 
dev-util/catalyst-2.0_pre20051122
Comment 6 Chris Gianelloni (RETIRED) gentoo-dev 2005-11-23 11:12:56 UTC
I'm currently looking at implimenting a eusergroup eclass that includes enewuser
and enewgroup (along with a couple helper functions).  What this would do is
allow us to make *that* eclass DEPEND on shadow (on Linux) and work around the
problems in bug #94745 by side-stepping it.
Comment 7 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-17 04:08:34 UTC
I've upgraded this to a blocker since some fix is required for our release to build properly and we are nearing our snapshot date.
Comment 8 SpanKY gentoo-dev 2006-01-17 06:12:37 UTC
or you could simply add shadow to packages.build and be done with it
Comment 9 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-17 06:35:08 UTC
Except adding shadow breaks stage 1 and stage2 building, so isn't a viable solution, as I stated last time you brought it up.  It also makes it impossible to build a set of default-linux stages without USE=pam...
Comment 10 Lars Weiler (RETIRED) gentoo-dev 2006-01-18 10:55:23 UTC
(In reply to comment #9)
> to build a set of default-linux stages without USE=pam...

I have pam set in the generic ppc-profile.  But it breaks as well.
Comment 11 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-20 11:59:25 UTC
Testing results:

Test #1 (shadow in packages.build and blockers removed)

# grep shadow profiles/default-linux/packages.build
# While shadow could be in here, it breaks stage 1 and stage 2 building for the
sys-apps/shadow
# grep pam-login sys-apps/shadow/shadow-4.0.7-r4.ebuild
        !pam? ( !build? ( !bootstrap? ( !sys-apps/pam-login ) ) )
# We moved /etc/pam.d/login to pam-login
PDEPEND="pam? ( >=sys-apps/pam-login-3.17 )"
                # These is now shipped with pam-login, and login
                                        # pam-login now.

>>> md5 files   ;-) files/README
>>> md5 files   ;-) files/run-crons-0.2.1
 * Adding group 'cron' to your system ...
 *  - Groupid: 16
/usr/portage/eclass/eutils.eclass: line 735: groupadd: command not found

!!! ERROR: sys-process/cronbase-0.3.2 failed.
!!! Function enewgroup, Line 735, Exitcode 127
!!! enewgroup failed
!!! If you need support, post the topmost build error, NOT this status message.


!!! catalyst: run script failed.

This is when it gets to building stage3.


Test #2 (shadow in packages.build)

# grep shadow profiles/default-linux/packages.build
# While shadow could be in here, it breaks stage 1 and stage 2 building for the
sys-apps/shadow
# grep pam-login sys-apps/shadow/shadow-4.0.7-r4.ebuild
        !pam? ( !sys-apps/pam-login )
# We moved /etc/pam.d/login to pam-login
PDEPEND="pam? ( >=sys-apps/pam-login-3.17 )"
                # These is now shipped with pam-login, and login
                                        # pam-login now.

Calculating dependencies ...done!

!!! Error: the sys-apps/pam-login package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers.


!!! catalyst: run script failed.

This is building a stage1.
Comment 12 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-21 14:47:28 UTC
Possible solution:

#1: Add pam to STAGE1_USE in *all* pam-enabled 2006.0 profiles
#2: Add sys-apps/shadow to default-linux/packages.build

This has been verified to work on x86.  Currently testing on amd64/ppc...
Comment 13 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-22 06:17:14 UTC
This also fixes amd64/ppc... I've added pam to STAGE1_USE on alpha, amd64, ppc, ppc64, sparc, and x86 for the 2006.0 profiles.

The rest of you need to make yourself a 2006.0 profile and make this change.
Comment 14 Joshua Kinard gentoo-dev 2006-01-22 11:09:11 UTC
mips done
Comment 15 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-22 15:55:06 UTC
I did s390 since there was already a 2006.0 profile...
Comment 16 Chris Gianelloni (RETIRED) gentoo-dev 2006-01-25 05:42:02 UTC
Apparently adding PAM to stage1 is a bad thing, so I'm adding solar to CC since he was working on a solution to this that doesn't involve PAM in stage1.

I am removing arches from CC since we might not need to do this.  I'll add them back if it ends up being necessary in the end or if another solution requires their assistance.
Comment 17 Chris Gianelloni (RETIRED) gentoo-dev 2006-02-06 08:49:08 UTC
*** Bug 121807 has been marked as a duplicate of this bug. ***
Comment 18 Chris Gianelloni (RETIRED) gentoo-dev 2006-02-06 08:50:40 UTC
OK.  I have resolved this in my snapshots with two changes.  First, I have removed sys-process/cronbase from RDEPEND on man, since it wasn't necessary.  Second, I have added a patch to baselayout-1.11.14-r3 in my snapshot that adds back the man user and group.  After these two changes, stage3 builds successfully (without pam in STAGE1_USE) on all arches.
Comment 19 Chris Gianelloni (RETIRED) gentoo-dev 2006-02-14 08:35:19 UTC
Created attachment 79772 [details, diff]
baselayout-1.11.14-users.patch

This patch resolves this issue for me.
Comment 20 solar (RETIRED) gentoo-dev 2006-02-14 09:23:33 UTC
Chris should this bug be reassigned to spanky/baselayout/base-system now?
Comment 21 Chris Gianelloni (RETIRED) gentoo-dev 2006-02-14 09:40:38 UTC
I would say so.  I'm keeping release on CC, though, since it'll affect anyone trying to build from stage1, so I'm sure we'll get *lots* of bugs on this if it isn't fixed in the tree by the time 2006.0 rolls out.
Comment 22 SpanKY gentoo-dev 2006-02-14 09:51:57 UTC
that's the point of the dupe
Comment 23 Gustavo Zacarias (RETIRED) gentoo-dev 2006-03-17 06:02:07 UTC
Anything new about this?
Stages can't be built with a current snapshot without tweaking it.
Comment 24 SpanKY gentoo-dev 2006-04-07 19:38:19 UTC
*** Bug 127157 has been marked as a duplicate of this bug. ***
Comment 25 Jakub Moc (RETIRED) gentoo-dev 2006-04-08 09:02:41 UTC
*** Bug 129255 has been marked as a duplicate of this bug. ***
Comment 26 Jakub Moc (RETIRED) gentoo-dev 2006-04-14 08:18:14 UTC
*** Bug 129951 has been marked as a duplicate of this bug. ***
Comment 27 Jakub Moc (RETIRED) gentoo-dev 2006-04-14 08:21:10 UTC
*** Bug 128999 has been marked as a duplicate of this bug. ***
Comment 28 Jakub Moc (RETIRED) gentoo-dev 2006-04-14 08:38:05 UTC
Is there still any issue with adding shadow dependency back to eutils.eclass  (where is really belongs), once the new shadow with re-integrated pam-login is marked stable? (Not that I'd notice any significant benefit wrt punting of various pretty much essential groups/users like cron/sshd/man from baselayout in the first place...)
Comment 29 Chris Gianelloni (RETIRED) gentoo-dev 2006-04-17 15:03:20 UTC
shadow inherits eutils, so it can't be a dependency of eutils...
Comment 30 Jakub Moc (RETIRED) gentoo-dev 2006-04-17 15:13:27 UTC
(In reply to comment #29)
> shadow inherits eutils, so it can't be a dependency of eutils...

It can with a little hack...

MY_PN="shadow"

DEPEND="!bootstrap? ( sys-devel/patch )"
RDEPEND=""

if [[ "${PN}" != "${MY_PN}" ]]; then
DEPEND="${DEPEND}
        sys-apps/shadow"
RDEPEND="${RDEPEND}"
fi
Comment 31 Chris Gianelloni (RETIRED) gentoo-dev 2006-04-18 08:22:32 UTC
As soon as you can prove to me that it won't cause more trouble than it is worth when trying to build stages via catalyst, I'll do it.  However, I can guarantee you that this will cause circular dependencies and generally be more trouble than it is worth.
Comment 32 Jakub Moc (RETIRED) gentoo-dev 2006-04-18 08:34:54 UTC
Shrug. If the above produces circular dependencies, then portage is broken... 

If that's not an acceptable solution, then I'd suggest re-adding cron/sshd/man back to baselayout and think twice before punting them again just for the sake of saving a few "redundant" lines in /etc/{passwd,group}.
Comment 33 solar (RETIRED) gentoo-dev 2006-04-18 08:40:46 UTC
(In reply to comment #32)
> Shrug. If the above produces circular dependencies, then portage is broken... 

Circular dependencies are just that. portage broken or not..  
A circle is still round.

> If that's not an acceptable solution, then I'd suggest re-adding cron/sshd/man
> back to baselayout and think twice before punting them again just for the sake
> of saving a few "redundant" lines in /etc/{passwd,group}.

Right this is the only real solution to the problem.
Comment 34 Chris Gianelloni (RETIRED) gentoo-dev 2006-04-18 14:55:34 UTC
The only thing that is required to be added back in man user/group.  That is because shadow will come in after man, but before openssh/cronbase.  As I said, the patch above worked perfectly for the 2006.0 release.
Comment 35 Jakub Moc (RETIRED) gentoo-dev 2006-05-10 14:10:33 UTC
*** Bug 132947 has been marked as a duplicate of this bug. ***
Comment 36 Jakub Moc (RETIRED) gentoo-dev 2006-05-14 03:02:12 UTC
*** Bug 133281 has been marked as a duplicate of this bug. ***
Comment 37 solar (RETIRED) gentoo-dev 2006-05-28 18:36:30 UTC
This is a formal vote for the solution presented by Chris in comment #34, me in 
#33 and others via IRC.
Add man back to user/group as needed and lose the dep so this bug wont hold up 
releng or others building feom the lowe levels of gentoo without adding any 
new deps. In addition I vote for making the change within the next few days.
Comment 38 Joshua Kinard gentoo-dev 2006-05-28 18:39:52 UTC
Seconded.  This just halted my 2006.1-pre stage run for mips, so I wanna squish it.
Comment 39 Gustavo Zacarias (RETIRED) gentoo-dev 2006-05-29 10:38:45 UTC
+1
i've been patching this for ages now to build QA stuff and it's quite bothersome.
Comment 40 Guy Martin (RETIRED) gentoo-dev 2006-05-29 10:51:05 UTC
+1

I'm for it.
Comment 41 Jason Wever (RETIRED) gentoo-dev 2006-05-29 11:24:40 UTC
+1 from me as well (as the supposed SPARC basesystem guy).
Comment 42 SpanKY gentoo-dev 2006-06-07 06:15:53 UTC
formal vote ?  you just made that up

adding users back into baselayout ignores problems, it doesnt fix them

the only real fix is having portage create the users instead of relying on packages such as shadow being installed
Comment 43 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-06-07 06:25:21 UTC
(In reply to comment #42)
> formal vote ?  you just made that up
> 
> adding users back into baselayout ignores problems, it doesnt fix them
> 
> the only real fix is having portage create the users instead of relying on
> packages such as shadow being installed
> 

while i agree with you on principal, this bug is holding people up.  We have a SoC project for GLEP 27, perhaps we can provide a module for this situation.  For now though, if you don't have a workable solution, I can't see a reason to leave it 'broken'; ie it blocks legitimate work for a bunch of other projects.
Comment 44 solar (RETIRED) gentoo-dev 2006-06-07 06:32:21 UTC
(In reply to comment #42)
> formal vote ?  you just made that up
> 
> adding users back into baselayout ignores problems, it doesnt fix them
> 
> the only real fix is having portage create the users instead of relying on
> packages such as shadow being installed

man is a user on every system. There is no reason to not really have it 
there cept maybe on uclibc systems where noman might be set.

Problem is this is blocking building from stage1 (comment #9) 
correctly and forcing shadow where it was not forced before is a 
worse solution than a one liner returning old behavior.

If you have a creative way to add users which does not rely on shadow then 
I think all of us are all ears.
Comment 45 SpanKY gentoo-dev 2006-06-07 09:16:25 UTC
the man account serves no purpose when the system has no man functionality installed

as i said, moving the logic to portage negates the need for any accounting utilities to be preinstalled
Comment 46 Andrew Gaffney (RETIRED) gentoo-dev 2006-06-07 09:18:59 UTC
Feel free to remove the 'man' user/group once that logic has been moved to portage and is shown to be stable (and work with ${ROOT}!) :)
Comment 47 Joshua Kinard gentoo-dev 2006-06-07 21:23:36 UTC
Portage-2.1 is in feature freeze right now, so even if someone cooked up that kind of logic, it would be of no use because it would not be able to make the snapshot, so the temp solution for now is the one-line addition.  Maybe said logic can be drafted and put into portage before 2007.0 rolls around (it can't be that hard -- anyone even drafted up pseudo-code or something for it?), and we can get rid of this change.  But for 2006.1 to work well, we need this change.
Comment 48 SpanKY gentoo-dev 2006-06-09 07:26:45 UTC

*** This bug has been marked as a duplicate of 53269 ***
Comment 49 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-06-09 08:36:58 UTC
When glep 27 is done, this is fixed, fix your shit now and we can fix it later at the end of the summer.

Don't go creating problems when no solution exists.
Comment 50 SpanKY gentoo-dev 2006-06-09 13:12:32 UTC
instead of being a jackass why dont you read the backlog

baselayout isnt broken

people want to add users back in to baselayout to ignore the underlying issue

uberlord *already added the user back in to baselayout*

the problem reported here *no longer shows up because the hacks have been added back into portage*

no go back to doing something useful instead of re-opening bugs you havent been following

*** This bug has been marked as a duplicate of 53269 ***
Comment 51 Stuart Longland (RETIRED) gentoo-dev 2010-12-30 03:41:41 UTC
Hate to bump an old bug; however as of this date, I still encounter this issue.  Catalyst will successfully build stage 1 and 2, then fail at stage 3 due to this little gem.

My workaround has been to edit the man ebuild; making it depend directly on shadow.  This works well enough for my needs.  I'm not sure why it doesn't seem necessary for other architectures, but it affects me on MIPS.  The last few releases, I seem to recall having to perform this hack.

How close is the real work-around to this problem?
Comment 52 Benedikt Böhm (RETIRED) gentoo-dev 2010-12-30 09:41:34 UTC
(In reply to comment #51)
> Hate to bump an old bug; however as of this date, I still encounter this issue.
>  Catalyst will successfully build stage 1 and 2, then fail at stage 3 due to
> this little gem.

this issue has never ben fixed and i wonder how releng copes with this bug ...

> My workaround has been to edit the man ebuild; making it depend directly on
> shadow.  This works well enough for my needs.  I'm not sure why it doesn't seem
> necessary for other architectures, but it affects me on MIPS.  The last few
> releases, I seem to recall having to perform this hack.
> 
> How close is the real work-around to this problem?

i assume that this bug will never get fixed. i suggest you give my metro branch a try (https://github.com/hollow/metro), which has this issue fixed (https://github.com/hollow/metro/commit/7c6be8945c28c3b770d1fcd98d79fc3a8a161398) 

Comment 53 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2011-05-06 19:46:15 UTC
I'm hitting this bug again on my testing for baselayout-2.0.2 and openrc-0.8.2-r1 on amd64 and x86.
Comment 54 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2011-05-18 13:25:19 UTC
*** Bug 367915 has been marked as a duplicate of this bug. ***
Comment 55 Zac Medico gentoo-dev 2011-05-19 22:17:41 UTC
Created attachment 274019 [details, diff]
patch catalyst to install shadow along with baselayout

I'd suggest a catalyst patch like this as a workaround, until we get the PMS/EAPI/council train rolling to solve bug 53269. This patch is completely untested, but anyway, it conveys the general idea.
Comment 56 Zac Medico gentoo-dev 2011-05-19 23:15:29 UTC
Created attachment 274027 [details, diff]
patch bootstrap.sh to install shadow in stage1

Here's an alternative to the catalyst patch. It seems sensible to include shadow in stage1 since you never know when an ebuild will call enewgroup. Note that this patch is intended to solve failures like this one:

/usr/portage/eclass/eutils.eclass: line 860: groupadd: command not found
 * ERROR: sys-apps/man-1.6f-r4 failed (setup phase):
 *   enewgroup failed
 * 
 * Call stack:
 *            ebuild.sh, line  56:  Called pkg_setup
 *   man-1.6f-r4.ebuild, line  24:  Called enewgroup 'man' '15'
 *        eutils.eclass, line 860:  Called die
 * The specific snippet of code:
 *   		groupadd -r ${opts} ${egroup} || die "enewgroup failed"
Comment 57 Naohiro Aota gentoo-dev 2011-07-02 11:36:03 UTC
(In reply to comment #56)
> Created attachment 274027 [details, diff]
> patch bootstrap.sh to install shadow in stage1

These patch break Gentoo/*BSDs. We need to add some check here.
Comment 58 Zac Medico gentoo-dev 2011-07-02 12:38:59 UTC
(In reply to comment #57)
> (In reply to comment #56)
> > Created attachment 274027 [details, diff]
> > patch bootstrap.sh to install shadow in stage1
> 
> These patch break Gentoo/*BSDs. We need to add some check here.

The bootstrap.sh patch needs to be reverted since bootstrap.sh is not called for stage1, and stage1 is where we really want to have the useradd provider installed. The correct place to pull packages into stage1 is packages.build, and there are separate packages.buid files for linux and fbsd:

  profiles/default/bsd/fbsd/packages.build
  profiles/default/linux/packages.build
  profiles/hardened/packages.build
  profiles/targets/vserver/packages.build
  profiles/uclibc/packages.build
Comment 59 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2011-07-02 12:51:06 UTC
(In reply to comment #58)
> (In reply to comment #57)
> > (In reply to comment #56)
> > > Created attachment 274027 [details, diff]
> > > patch bootstrap.sh to install shadow in stage1
> > 
> > These patch break Gentoo/*BSDs. We need to add some check here.
> 
> The bootstrap.sh patch needs to be reverted since bootstrap.sh is not called
> for stage1, and stage1 is where we really want to have the useradd provider
> installed. The correct place to pull packages into stage1 is packages.build,
> and there are separate packages.buid files for linux and fbsd:
> 
>   profiles/default/bsd/fbsd/packages.build
>   profiles/default/linux/packages.build
>   profiles/hardened/packages.build
>   profiles/targets/vserver/packages.build
>   profiles/uclibc/packages.build

I built stages locally to test this, but I wasn't able to check them yet.
If this works, as it should (the stages did build), I'll add shadow to packages.build.