Okay this is not news, but seems like it’s still a problem for someone, so I’m following fox2mike’s suggestion (from yesterday.. I initially forgot about doing so), and I’m blogging about it…
So many people using ~arch or some packages out of ~arch might have seen that a new update to shadow (>=4.0.12-r2) blocks pam-login, and pam-login blocks newer versions of shadow.
Why this? Well it’s simple to say for me, as I know the background, but might be less easy to understand without knowing that.
So let’s start with the reason why /bin/login was not provided by shadow when using pam (thing that happens on most desktop systems)… to be honest, I don’t know that for sure, probably it’s just that shadow weren’t providing a PAM-enabled /bin/login or it had problems in the past.. so we just gone using pam-login package from SuSE (in the good days when people provided the tarballs for other distributions to use), the 3.x series.
This was all good until shadow 4.0.something started providing a valid /bin/login, so we just had pam-login ebuild to build /bin/login from shadow source code.. but that meant we had to build the same code two times, and maintain patches for two packages instead of one.
So as this was planned for a while but Azarah hasn’t had time to handle that, I decided to do the merge between the two: since shadow 4.0.14-r2 the single sys-apps/shadow package replaces both shadow AND the old pam-login package. This means that they block each other now, so you have to do something like:
emerge -C pam-login && emerge -u shadow
if you want to have your system working fine. If you just unmerge pam-login but NOT update shadow, you won’t be able to login in the system if you restart (although already running sessions, already waiting login prompts, xdm and variants and ssh won’t be affected).
Please also note that you need a recent version of util-linux, that dropped the pam useflag, if you want to be sure that it won’t request you to merge pam-login again; ~arch version is fine. For older versions you might want to just set util-linux to use -pam with package.use as it doesn’t change anything anyway.
Now, don’t start asking for better way to handle this, as portage does not provide anything to improve this. This works without strange surprises, so just drop pam-login and you’ll be fine 🙂
Update: Comments have been closed because this post had too much spam coming. If you want to say yours, use the repost. Thanks, Diego.
It seems to me that you never will want both PAM-login and shadow-login so why not just unmerge PAM in the ebuild scripts whenever shadow is to be updated? I can’t see what could possibly break.Famous last words. With suitible warnings and messages, of course. These messages will scroll by while you’re asleep after saying emerge –update world. Very useful when you are looking through the logs after something doesn’t work any more.Martins
Unmerging from an ebuild isn’t viable. The block will disallow you from running a blind emerge -uD world without first taking care of the issue..And about PAM need… many things lately rely on the use of PAM, to set limits and other things, so I wouldn’t say it’s unneeded.. it can be avoided, but I wouldn’t do that anyway.
Ok, gents, somewhat of a newb here – I unmerged pam-login, but haven’t logged out of that session (lucky).I ran the emerge string above: [emerge -C pam-login && emerge -u shadow] with these results:localhost ~ # emerge -C pam-login && emerge -u shadow— Couldn’t find pam-login to unmerge.>>> No packages selected for removal by unmerge.Calculating dependencies… done!>>> Auto-cleaning packages…>>> No outdated packages were found on your system. * GNU info directory index is up-to-date.Next, I looked through the emerge.log file and found the original version I unmerged: pam-login-3.17I tried: emerge -uDpv pam-login-3.17 with the following result:These are the packages that would be merged, in order:Calculating dependencies!!! ‘pam-login-3.17’ is not a valid package atom.!!! Please check ebuild(5) for full details.!!! (Did you specify a version but forget to prefix with ‘=’?)Not sure what to do next – is there something other than chrooting to fix? Will chroot and re-emerging pam-login work?Thanks…cdI can’t figure out what to do next. BTW, I’m ok with pam-login – seems like more and more apps are utilizing it.
I suggest this:FEATURES=-collision-protect emerge –nodeps shadow && emerge –unmerge pam-loginThat way you never lose /bin/login at any point in time.
Thanks verry much diego :)NOTE:If you can’t emerge -u shadow, because you already have the latest version etc., then unmerge it and try again. (Directed at the newb guy)
I did exactly like in the post. I’m going to reboot the system and login from SSH. I guess that if I go to the datacenter, i can login from there without problems.I’m gonna kill some of you guys if the update to the server doesn’t go smooth. :)I love Portage.
what if i want pam over shadow, ie: i’m running a server where applications/services will be relying upon pam. i tried reversing the original instructions, and rebooted fine but still get pam blocked by shadow when i do an emerge -Dup world. best,joe
Please read the entry, it is not _pam_ being blocked, but pam-login, and the only reason is that shadow with pam useflag IS pam-login.
so should i remove pam from my useflag? if i emerged the shadow package and unmerged the pam thing?
I’ve successfully dealt with this issue on my own systems by simply unmerging shadow and remerging it, because it’s blocking on itself for me (I use the ‘pam’ USE flag). I didn’t have to unmerge pam-login or change any USE flags this way.YMMV
Thank you for posting this. This was a problem for me, and now it is solved.
Daniel LinThank you, you are very useful.
Thanks for this, Diego. I hadn’t sync’ed for weeks: 167 packages to update, and this stopping them! Now it’s fixed. You da man!