Because pam-1.0.1 didn't install pambase, their is no or no 'good' pam configuration. Reproducible: Always Steps to Reproduce: 1. Installed a clean stage3 2008.0 'like' normal. 2. Configure it (see attachment for my make.conf) 3. emerge -auv world 4. Eventuality it wants to install dev-db/mysql and fails. (because groupadd fails @ Pam: Authentication failed error) Actual Results: You will get the error "groupadd: 'Pam: Authentication failed' ". You don't some of the 'root' privileges anymore. If you logout after this, you can't login, only with livecd. Expected Results: Continue setup, without error. And the ability to login. You can fix this error by emerge sys-auth/pambase
Created attachment 182841 [details] make.conf configuration file
Please post your `emerge --info' too.
Created attachment 182941 [details] emerge --info Note; Kernel updated to 2.6.28-r2 from 2.6.27-r8 after bug report. (this shouldn't have any effect)
(In reply to comment #0) > 4. Eventuality it wants to install dev-db/mysql and fails. (because groupadd > fails @ Pam: Authentication failed error) It seems like it's probably related to sys-libs/pam having sys-auth/pambase in PDEPEND. This problem might be solved by the merge order calculation changes associated with bug 250020. I'll see if I can reproduce the problem in a stage3 chroot and test if it's solved by the changes that are in svn.
(In reply to comment #1) > Created an attachment (id=182841) [edit] > make.conf configuration file I wasn't able to reproduce the problem given that configuration. I might be able to if I had your world file. Anyway, the sys-libs/pam dependencies seem fine, so I'll reassign this to dev-portage. It seems like a variant of bug 199856 (might be solved by changes from bug 250020).
This bug has some implications similar to bug 256616 in the sense that the system is extremely fragile between the time that sys-libs/pam is upgraded and sys-auth/pambase has not yet been installed. The --jobs parallel scheduling code needs to be aware of conditions like these in order to ensure that they don't interfere with other builds.
In svn r12713 it's fixed to disable spawning of parallel builds when a deep system dependency has an unsatisfied runtime dependency. Combined with the merge order fixes associated with bug 250020, hopefully this bug is mostly solved. There are still some corner cases that won't be handled correctly, but those will have to wait until bug 199856 completely solved.
This is fixed in 2.2_rc24 which is in package.mask. I'll close this bug when it's also released in 2.1.6.8.
This is released in 2.1.6.8.
Hey Zac,
Hey Zac, Years ago I noticed portage parallel builds became almost completely sequential on my 12/24 core system. I've been suffering through watching my mostly idle system build packages sequentially, with the occassional burst of 3 or 4 in parallel every time I upgrade. But today I finally decided to look at the code. I suspect this is the reason: commit bd75495cc5771726084073d20ab556205cb2521e Author: Zac Medico <zmedico@gentoo.org> Date: Thu Feb 26 04:26:07 2009 +0000 Bug #259954 - Do not spawn parallel build when the system is in a fragile state due to a system package having an unsatisfied runtime dependency (such as sys-libs/pam having an unsatisfied PDEPEND on sys-auth/pambase). svn path=/main/trunk/; revision=12713 As I read the description of this bug and referenced bug 199856, it seems like part of the problem is that PDEPEND allows packages to be installed in the system with missing runtime dependencies (although only for a short while in theory). I'm planning about putting some effort into identifying whether this is what's choking out the parallel builds on my system. And if so, I'm thinking of trying out a mod to emerge where I can optionally disable the logic in the above commit; and orthogonally add an option to treat PDEPENDS af if they were RDEPENDS. When I do a major upgrade or a an emerge -e @world, it seems like the parallel build doesn't really provide much speedup as is. Is there any way with the code as is (I'm on portage-2.3.3) to diagnose the state of the scheduler (why it's not starting more jobs) when the load average and existing number of jobs are both below threshold? Do you expect I will run into any problems or pitfalls coding the mod I've described above?
(In reply to Joe Harvell from comment #11) > I'm planning about putting some effort into identifying whether this is > what's choking out the parallel builds on my system. And if so, I'm > thinking of trying out a mod to emerge where I can optionally disable the > logic in the above commit; and orthogonally add an option to treat PDEPENDS > af if they were RDEPENDS. You can now use the emerge --implicit-system-deps=n option for this, see bug 681312. > When I do a major upgrade or a an emerge -e @world, it seems like the > parallel build doesn't really provide much speedup as is. > > Is there any way with the code as is (I'm on portage-2.3.3) to diagnose the > state of the scheduler (why it's not starting more jobs) when the load > average and existing number of jobs are both below threshold? If you send the main emerge process a SIGUSR1 signal, then it will produce a pdb shell so that you can poke around. > Do you expect I will run into any problems or pitfalls coding the mod I've > described above? Hopefully the --implicit-system-deps=n option serves your needs.
