I've ran a yum update on my CentOS 5.8 box and now I am unable to log into the console as root. Basically what happens is I receive the login prompt, enter the correct username and password, and am immediately spit back to the login prompt. If I enter an incorrect password, I am told the password is incorrect, therefore I know that I am using the proper credentials.

The only log I can seem to find of what's going on is /var/log/secure which simply contains:

15:33:41 centosbox login: pam_unix(login:session): session opened for user root by (uid=0)
15:33:41 centosbox login: ROOT LOGIN ON tty1
15:33:42 centosbox login: pam_unix(login:session): session closed for user root

The shell is never spawned.

I've checked my inittab which looks like so:

1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

And my /etc/passwd which properly has bash listed for my root user:


As well as permissions on /tmp (1777) & /root (750).

I've attempted re-installing bash, pam, and mingetty to no avail, and confirmed /bin/login exists.

Any thoughts would be greatly appreciated.



  • For clarification: is is correct that you can log in as a non-root user. If so, then is it correct that you can su to root? I assume the answer to both questions is yes. – gsiems Sep 6 '12 at 20:16
  • I am unable to log in as any unprivileged user as the same thing happens. When I enter the correct password it pops me right back to the login prompt, when I enter the wrong password, I receive "login incorrect." – cjones26 Sep 6 '12 at 20:23
  • Is /etc/pam.d/ intact? what does /etc/pam.d/login look like? – gsiems Sep 6 '12 at 20:49
  • /etc/pam.d appears to be fine (I'm comparing it to a working CentOS server I set up the same day as this one)...check the pastebin for /etc/pam.d/login: pastebin.com/rUig4qfn (this appears fine as well). – cjones26 Sep 6 '12 at 21:11
  • @slashp: Can you login via ssh? – quanta Sep 7 '12 at 4:04

You're logging in just fine - whatever shell you're starting is exiting immediately.

Boot to single user mode or a rescue CD and chroot into your installed system.

First, check your startup scripts (profile, bashrc and the like). Make sure they're not doing anything that would exit immediately.

Can you even chroot? If you can't, that means it can't run your shell. Try chrooting and specify a static shell.

Change root's shell to a static shell and that should help. Then from there you can reboot into the installed system and start figuring things out.

Are you using selinux/apparmor? Have you tried setting enforcement to permissive? Does that help?

  • Yep, I can chroot that's how I've been getting in to check the stuff ewwhite was having me look at. What do you mean by static shell? Thanks! – cjones26 Sep 7 '12 at 14:00
  • A non-dynamically linked shell. Do you have busybox installed? Make a symlink to it named 'ash' and try setting your shell to that. After you chroot, can you run a 'login shell'? (su -/su - username)? – MikeyB Sep 7 '12 at 14:09
  • No selinux/apparmor...installed busybox, symlinked it to /bin/ash, changed my /etc/passwd and still the same result. – cjones26 Sep 7 '12 at 15:24
  • What about the other things I suggested to check out? – MikeyB Sep 7 '12 at 17:23
  • Yes I can run both the su - and su - username and get a prompt. – cjones26 Sep 7 '12 at 19:26

Perhaps you had a major glibc change or something that's affecting login. Did you reboot following your yum update or at least see what was updated in /var/log/yum.log? The latter will tell you which packages were modified/updated.

You can verify the installed /bin/login binary with:

# rpm -qf /bin/login
# rpm -vV util-linux | grep S.5

And report back if there's any output from the second command...


So it appears to be a library problem. Let's assume that it's /bin/login that's causing the issue. Can you run a quick ldd on the binary? Does your output look like this?

# ldd /bin/login    
    linux-vdso.so.1 =>  (0x00007fffb57ec000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000035f3c00000)
    libpam.so.0 => /lib64/libpam.so.0 (0x00000035f8800000)
    libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00000035f3800000)
    libaudit.so.0 => /lib64/libaudit.so.0 (0x00000035f6c00000)
    libc.so.6 => /lib64/libc.so.6 (0x00000035f1800000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000035f2400000)
    /lib64/ld-linux-x86-64.so.2 (0x00000035f1400000)
  • I did in fact have a lot of libc6 error after a kernel update / reboot (this machine was converted from an XVA to a VHD and I needed to remove the xen kernel & install the standard el5 one) and that's when I performed the yum update in a chroot. I ran the two commands above & get the same output from the first, and no output from the second. – cjones26 Sep 6 '12 at 21:13
  • Okay, this is probably a glibc issue. Perhaps you could try installing yum-utils and running yumdownloader glibc to obtain the rpm, then an rpm -ivh --force on the actual glibc package. I'm not sure... it sounds like there's a package/library issue, though. – ewwhite Sep 6 '12 at 21:22
  • Bah, tried it but no gold :(. – cjones26 Sep 6 '12 at 21:38
  • @slashp see my edit. – ewwhite Sep 6 '12 at 21:42
  • My output looks the same (same libraries and same versions) with the exception of the addresses they are pointing to...for instance, the first library listed in your output points to 0x00007fffb57ec000, while in mine it points to 0x00007fff401ff000. Probably not a big deal but just wanted to point it out. – cjones26 Sep 7 '12 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.