# Updated Pam - Now I can't login as root from the console

## danielrm26

This is fun.

I just did an update of gcc, ssh, and pam.  I then did an etc-update and remember seeing something about pam.  I chose option 1 (replace) since I had never made any changes to that file manually.

Well, now I can't login as root.  It says "login incorrect" regardless of what I type as a username.

Any ideas?  My only option now seems to be to bring up a pam file from one of my other boxes and copy it over to the now broken one.  Any ideas that are better than this?

----------

## danielrm26

Ok, I sftp'd my /etc/pam.d/login file from another gentoo box and was able to login fine.

WARNING: Be careful when updating pam in portage and then using etc-update.

# strings for searching this forum

# hopefull this will be seen by others if they have the same issue

/etc/pam.d/login

login

can't login anymore

username incorrect

incorrect username

----------

## water

Are you using unstable packages?

----------

## thwint

Today I finished installing my Gentoo box and had the same problem. 

What is wrong with the default configuration of pam-login 3.12?

----------

## b0fh

Same problem here. Could someone post a right /etc/pam.d/login?

Maybe I should switch back to stable packages... ~x86 was very buggy last weeks  :Sad: 

----------

## di1bert

Same thing here...

Any chance someone could post a working pam.d/login file as my box is useless until I can fix this.

The package is fine, it just seems to be the updated conifg file that is borking the system.

I am using a ~x86 system...

-- di1bert

----------

## water

Time to report a bug, i think

----------

## di1bert

Yes.

And for those of you (who like me) are too lazy to read bug reports...

*** Fix  (temporary)

I had the same problem. My solution is to replace "pam_unix2.so" with "pam_unix.so",

after that evyryting should work fine.

***

I just did this and my system is back up and running. It seems there is NO pam_unix2.so file...probably the source of the problem...

Anyhoo...back to "life"

-- di1bert

----------

## patrickfo

but i can login with ssh 

in /etc/pam.d/login we have reference to non existant modules:

remove all "2"

pam_unix2.so => pam_unix.so for example

and all will be ok

----------

## Lasker

 *patrickfo wrote:*   

> but i can login with ssh 
> 
> in /etc/pam.d/login we have reference to non existant modules:
> 
> remove all "2"
> ...

 

Yea, that works!  :Smile: 

But I wonder, why nobody mentioned the most obvious method

for people like me, who don't have a running ssh server but a boot CD:

Just boot from CD, mount your root partition like you did when you installed your system, i.e. 'mount -t reiserfs /dev/hda3 /mnt/gentoo'.

Then 'cd /mnt/gentoo/etc/pam.d' and edit with 'nano -w login'.

HTH

----------

## SavageMindz

I just had the same problem.  Thanks for the fix guys. I had a broken system there for all of 30 secs. Sometimes you guys really rock.  :Very Happy: 

----------

## ()

Maybe there should be some rules that certain critical packages are tested properly before entering the portage tree? I mean, chances are good you find a solution soon @ forums.gentoo.org, but not being able to log in #%!$

----------

## wilk307

same thing here

in my case (no cd unit / no ssh server) i passed the "single"  argument in the grub menu;

after this you you should get a root prompt and be able to fix things

for those who don't know this trick: select a linux entry in grub then append the "single" word

after all the other stuff at the command line; press enter and wait for the root prompt  :Smile: 

----------

## pjp

Moved from Installing Gentoo.

----------

## neenee

thanks all - that worked beautifully for me.

(used wilk307's method to get to a prompt,

then patrickfo's instructions and removed

the 2's)

----------

## chutzpah

Here's the working /etc/pam.d/login (luckily I didnt logout, and I have access to, oh 8 or 9 other gentoo boxen)

Anyway, here it is

```

#%PAM-1.0

                                                                                

auth       required     /lib/security/pam_securetty.so

auth       required     /lib/security/pam_stack.so service=system-auth

auth       required     /lib/security/pam_nologin.so

                                                                                

account    required     /lib/security/pam_stack.so service=system-auth

                                                                                

password   required     /lib/security/pam_stack.so service=system-auth

                                                                                

session    required     /lib/security/pam_stack.so service=system-auth

session    optional     /lib/security/pam_console.so

```

Hope this helps those without access to another box with gentoo.

----------

## dufeu

Thanks man. You rock.  :Wink: 

And more thanx to those who posted /etc/pam.d/login entries.

 :Cool: 

----------

## Azarah

Hi guys, slight screwup my side - did not notice that /etc/pam.d/login

there, sorry.  Another way will be to delete it, and remerge sys-apps/shadow.

----------

## Azarah

Thanks Rac - would have fixed this earlier, but DSL over here was down

again  :Sad: 

----------

## Raoul_Duke

 *Azarah wrote:*   

> Thanks Rac - would have fixed this earlier, but DSL over here was down
> 
> again 

 

Don't worry, took 5 seconds to find this thread......20 secs to fix the problem. It's the sort of thing that happens from time to time   :Wink: 

----------

## ()

Azarah: Could there be a restriction that system critical packages are tested before making their way into the tree? This should've been fairly easy to discover.

----------

## Auka

Hi, i had the same problem here. But as logging in through xdm (kdm, whatever) still worked fine I was lucky...  :Wink: 

----------

## Lasker

 *wilk307 wrote:*   

> same thing here
> 
> in my case (no cd unit / no ssh server) i passed the "single"  argument in the grub menu;
> 
> after this you you should get a root prompt and be able to fix things
> ...

 

Interesting, I'll remember this for the next time.

But isn't "single" the same as runlevel 1?

If so, IIRC I had to put runlevel entries imediately behind the kernel entry and before all other options in that line...

----------

## ce110ut

for reason's unknown, the provided /etc/pam.d/login post did NOT work for me.  I re-emerged shadow and that fixed it for me.

thanks to all - now I'm late for class   :Razz: 

----------

## Azarah

 *() wrote:*   

> Azarah: Could there be a restriction that system critical packages
> 
> are tested before making their way into the tree? This should've been fairly
> 
> easy to discover.

 

Well, sure, but sometimes there is not that much time for a 'less demaning'

package.  For ages now pam-login have been fairly without issues, and

it _never_ before wanted to install /etc/pam.d/login :/

Also, yes, it might not be a good attitude, but I would have liked to think

that it being in "unstable profile", would make people look at it as an

possibly unstable package, and rather help fix issues that was missed due

to either not having that environment that causes the issues, or missing

due to overlooking something obvious.  No offense intended   :Wink: 

----------

## shadow303

I think the problem with that attitude is that there seem to be many stable packages lingering in the unstable branch for an excessive period of time and upgrades are painful when you have a mix of stable and unstable (that was my main reason for switching to ~x86).  For exampe, KDE 3.1.4 just made it into stable and has been out for about 2 months.

----------

## shadow303

I think the problem with that attitude is that there seem to be many stable packages lingering in the unstable branch for an excessive period of time and upgrades are painful when you have a mix of stable and unstable (that was my main reason for switching to ~x86).  For exampe, KDE 3.1.4 just made it into stable and has been out for about 2 months.

----------

## Azarah

Well, maybe more feedback ?  Or maybe a bug or a better method.

Unfortunately Gentoo-stable is currently still a no show.  Aliz is also

working on this.  Fact of the matter is that living in unstable you do

forget about unstable - then again, our 'stable' is very unstable if you

go by Debian rules  :Smile: 

----------

## ()

I still think it could be useful with some sort of testing routines, counting on a certain behaviour from software eventually causes things to break. I don't know how practically feasible this is, but automated testing could be worth looking into. As I am looking into ways of improving Portage these days, perhaps I will think of something myself.

----------

## fireboy92k

If anybody else has this problem, and this doesn't solve your issue here is what got me day before yesterday.

I emerged eterm, which forced an depends emerge on shadow.  After a reboot, nobody could login, not even root.

Another thread reply pointed out that folks using metalog (which the install doc recommends) might have this problem and should get rid of metalog for sysklogd.

After a some frustration, a reboot with the boot disk, and some re-emerging, everything seems to be back in place with sysklogd vice metalog.

Much thanks to wayreth for pointing this out

----------

## GetLinux

 *Azarah wrote:*   

> Hi guys, slight screwup my side - did not notice that /etc/pam.d/login
> 
> there, sorry.  Another way will be to delete it, and remerge sys-apps/shadow.

 

BE CAREFUL ABOUT THIS!!! I followed this (had a problem where creating a normal user with useradd did not encrypt the password, but shadow did, therefore user could not log in), and re-emerging sys-apps/shadow did not re-create this file. Now I can't even log onto my machine as root (it doesn't even ask me for the password, just says "incorrect login" when I type "root" at the prompt!

Silly me for deleting a file without first testing to see if it was even necessary to do so...I could have tried "emerge sys-apps/shadow" without deleting the file and see if the problem was fixed first. Darn.

----------

## GetLinux

Another suggestion (see this forum where passwords are not properly encrypted when you create them with "useradd"):

```
emerge superadduser
```

All it is is a program that prompts you for the parameters for the "useradd" command...but it passes the passwords to the "shadow" app encrypted, like it's supposed to. Worked with no tweaking or config updates for me.

(With "useradd", for me, for some reason passwords ended up in /etc/shadow in plain text, which shadow would then try to decrypt when a user tried to login.)

----------

