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
*** Bug 113299 has been marked as a duplicate of this bug. ***
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.
Sorry for this, won't happen again...
(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 ;)
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
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.
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.
or you could simply add shadow to packages.build and be done with it
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...
(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.
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.
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...
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.
mips done
I did s390 since there was already a 2006.0 profile...
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.
*** Bug 121807 has been marked as a duplicate of this bug. ***
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.
Created attachment 79772 [details, diff] baselayout-1.11.14-users.patch This patch resolves this issue for me.
Chris should this bug be reassigned to spanky/baselayout/base-system now?
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.
that's the point of the dupe
Anything new about this? Stages can't be built with a current snapshot without tweaking it.
*** Bug 127157 has been marked as a duplicate of this bug. ***
*** Bug 129255 has been marked as a duplicate of this bug. ***
*** Bug 129951 has been marked as a duplicate of this bug. ***
*** Bug 128999 has been marked as a duplicate of this bug. ***
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...)
shadow inherits eutils, so it can't be a dependency of eutils...
(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
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.
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}.
(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.
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.
*** Bug 132947 has been marked as a duplicate of this bug. ***
*** Bug 133281 has been marked as a duplicate of this bug. ***
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.
Seconded. This just halted my 2006.1-pre stage run for mips, so I wanna squish it.
+1 i've been patching this for ages now to build QA stuff and it's quite bothersome.
+1 I'm for it.
+1 from me as well (as the supposed SPARC basesystem guy).
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
(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.
(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.
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
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}!) :)
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.
*** This bug has been marked as a duplicate of 53269 ***
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.
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 ***
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?
(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)
I'm hitting this bug again on my testing for baselayout-2.0.2 and openrc-0.8.2-r1 on amd64 and x86.
*** Bug 367915 has been marked as a duplicate of this bug. ***
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.
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"
(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.
(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
(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.
