Somewhere along the way, I seem to have broken root login from the KDE login page (on the console of the system). I can access the root account just fine using an SSH client, but it won’t accept my login attempts from the console.
I’ve tried using passwd root to reset the password, with no effect.
Any suggestions, short of nuking and rebuilding the world, about how to find and fix whatever I broke?
FWIW, here is what I see at the end of /var/log/secure when a login attempt fails:
Sep 29 14:40:41 localhost sddm-helper[2482]: pam_kwallet5(sddm:auth): (null): pam_sm_authenticate
Sep 29 14:40:41 localhost sddm-helper[2482]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
Sep 29 14:40:41 localhost sddm-helper[2482]: pam_unix(sddm:session): session opened for user root by (uid=0)
Sep 29 14:40:41 localhost sddm-helper[2482]: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
Sep 29 14:40:41 localhost sddm-helper[2304]: pam_unix(sddm-greeter:session): session closed for user sddm
Sep 29 14:40:41 localhost systemd[2309]: pam_unix(systemd-user:session): session closed for user sddm
Sep 29 14:40:41 localhost sddm-helper[2482]: pam_unix(sddm:session): session closed for user root
Sep 29 14:40:41 localhost sddm-helper[2482]: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_close_session
Sep 29 14:40:41 localhost sddm-helper[2482]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
Sep 29 14:40:42 localhost sddm-helper[2555]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
Sep 29 14:40:42 localhost systemd[2557]: pam_unix(systemd-user:session): session opened for user sddm by (uid=0)
The only other possibly relevant change I’ve made is that I added Xming on the dev system I use, and I’ve connected to this system several times using X11.
One thing you can try, lets see if its a problem with selinux. If you have selinux enabled, then we can temporarily disable it with this:
setenforce 0
then try and login from the console. Does it work? If so, then it would hint at a problem with /etc/passwd or /etc/shadow maybe. If it still doesn’t work, then something that was installed to allow you to access remotely has changed the system and doesn’t allow console logins anymore. Maybe something under /etc/pam.d perhaps.
I just now turned off SELinux in /etc/selinux/config.
That fixed the issue. This machine is physically sitting next to me in my office. I’m going to leave SELinux turned off for now.
I appreciate the quick assist. I did see a momentary complaint about vmware in the lower right of the desktop when I logged in just now. Here is the notification that caused it (I think):
We're sorry, it looks like /usr/lib/vmware/bin/vmware-modconfig crashed. Please contact the developer if you want to report the issue.
OK, so what you can do, you can force a relabel with selinux contexts, by doing something like this:
touch /.autorelabel
that is for the / filesystem. For other partitions, you can do the same, eg /usr/.autorelabel but for now just start with where the config files are and see if that fixes it before doing other partitions - of course, enable selinux again in /etc/selinux/config by setting to permissive rather than enforcing and reboot your system. This should fix any problems with selinux on the standard files in /etc for example. Later, set to enforcing to fully enable selinux again.
Well when I blew up Rocky Linux 8.4 while trying to install VMWare Player, the first thing I did was to delete everything that dealt with VMware. That fixed it partially, as there were times it would come up and say FAILED over and over again, then I get a login. The CLUE that lead me to SELinux was I kept getting those pesky error messages on my task bar that said something was wrong and to troubleshoot security settings, or some such thing. After checking against openSUSE 15.3 (yes I know they are two different OS), which has SELinux turned OFF. I decided to go back to Rocky Linux and then went to /etc/selinux/config and changed the line SELINUX=enforcing => SELINUX=disabled, then rebooted the system which forced the system to autorelabel the entire drive. After that I rebooted the the drive twice more which seemed to mostly cure the problem. The next step was to to change SELINUX=disabled to SELINUX=permissive and then rebooted the system a few more times it to autorelabeled the drive but far more quickly, finally I changed SELINUX=permissive back to SELINUX=enforcing. That seems to have [SOLVED] the problem and I no longer get the FAILED problem when rebooting the system.
The only problem I now have is I have not quite gotten up the nerve to try and reinstall VMWare Player again. I think I followed iwalker’s bread crumbs on how to fix the problem and install VMWare Player 16.1.2 but along the way I was shocked to discover that VMWare has been aware of this problem for some time as has Red Hat yet the problem still persists. I have ZERO problem install VMWare Player 16.1.2 on CentOS 7.9 and ZERO problem installing VMWare Player 16.1.2 on openSUSE 15.3 Leap which uses almost the identical kernel – 4.18.0 – so I have no idea what is causing the problem. I am hoping that when Red Hat releases it next point upgrade to 8.5 and/or VMWare releases it next version of Player and Workstation the problem will be FIXED, rather than me trying to patch (?) the system.