Can login with GDM, can't login to console

[3strands]

Guys, got a really strange problem here.

I've just installed a fresh Fedora 16 image, and on June 2nd at around 10:30am I ran a "yum upgrade" and let things take their course. I locked the screen and walked away. Came back and I couldn't unlock my screen - logging into the console also failed.

I tried doing a couple of checks, here are the symptoms:
1) Logging into the console fails for both root and my user. I have checked, the passwords are exaclty the same as before.
2) selinux was in enforcing targeted mode when I ran the update - I have moved to permissive, but still fails.
3) I can change grub to boot into single mode, and my root shell opens. I can set passwords here. However, this is where the interesting bit happens:

If I change the password of "user" to "passw0rd_5736!!_!" while in single mode, the command succeeds. If I then test it while in single-user mode but su - user, then try to "su - user", that same password fails.

If I su to "user" from the initial root prompt and run passwd and change the password, it succeeds until the final entry, where it gives a "passwd: Authentication token manipulation error" before returning - however the password in /etc/shadow does change.

Here's the really strange part. When I "init 5" and try to login with GDM, the login succeeds with the new password!

Sounds like a PAM problem, but I can't figure out how to troubleshoot it. As an FYI, the system is now in SELinux permissive, not enforcing, so SELinux shouldn't be causing the fault.

[sea]

Out of curiosity, does a simple su user -c whoami work, as you see, without the dash?

Let me rephrase your issue:
1) you re-booted into the installed OS
2) Updated 2012 june 2nd 10:30 am
3) When you came back, xscreensaver was active and you could not login?

4)Hard power off, boot into emergency mode
5) changed pw of user and root

In init 5 they work, but not in init 3?

[3strands]

It does work, actually. running that command returns "user"

What I found was quite interesting. My system-auth-ac file has a line requiring pam_shells.so
auth required pam_shells.so

each of my users has "/bin/bash" as the shell in /etc/passwd.

For some reason, /bin/bash did not exist in /etc/shells. Once I re-added "/bin/bash" manually, the login have begun working again. pam_shells.so would definitely do it.

I need to find an easier way to turn on debugging for pam, though. Thanks for the assistance!

[PabloTwo]

There is a known bug in F16 about the missing /bin/bash entry in /etc/shells. After doing a full update, the most advised fix was to "yum reinstall bash". This bug created all sorts of weird shell behavior.