I have had the system (9+) live as a Mate Desktop for a few months, after a crash & reboot I am unable to login to the system. On the GUI it goes to login but returns to the login screen, it happens so quickly I do not get a chance to read a displayed message.
I then tried Ctrl+Alt+F2 but the same problem, just returns to login
When I try to ssh into the system I see: client_loop: send disconnect: Broken pipe
I also have cockpit install and that shows Permission denied, although I do not recall if I had ever used it.
If I type the password wrong, it tells me that it is wrong.
The first thing to look into is where it says âcrash and rebootâ, understanding what went wrong could provide the answer of how to fix it, e.g. by looking at the logs from the time of the crash, and then looking at the logs from now. Try to access the system by using emergency mode or rescue mode.
Thanks for your help with this, I have done that and got to the bash prompt, not really sure what I am looking for but the /etc/passwd file is there and looks ok (I think). I opened it up with vi and can see the users
So you could look at e.g. â/var/log/messagesâ from the system that crashed, and see if there are any errors at the time of the crash, and also from the recent single user mode login.
The sulogin failed in single user mode might be to do with selinux needing relabel, it depends on what went wrong in the first place.
There is mention of selinux but I think it was set to disable, canât really see much else, have copied the log and can post, where / how would be best?
Thanks
Failed to execute /usr/lib/systemd/systemd: Permission denied
Failed at step EXEC spawning /usr/lib/systemd/systemd: Permission denied
Main process exited, code=exited, status=203/EXEC
Failed with result âexit-codeâ.
It was selinux, after posting the above I thought best to check and it was set to
SELINUX=enforcing
Changed to disabled, rebooted and logged in. I guess there may have been some way of fixing it but I have always / usually disabled it, not sure why I had not.
Now I am registered I will keep an eye on the project, switched to Rocky from CentOs about 3 months now and have 2 servers 1x8 & 1x9 + 9 on a desktop.
Most likely due to selinux extents needed resetting. You would need to put it back to permissive instead of disabled, and then do an autorelabel to fix all the selinux stuff on the files. Then you would be able to log in normally with selinux enabled.
It is one of those features on Linux that I have always disabled, not sure why I left it this time think I thought I would give it a try, but I have never had a problem by leaving it disabled, one less thing to go wrong.
Not running selinux also leaves vulnerabilities open.
As iwalker stated, doing an autorelable will fix most issues unless you have packages that selinux knows nothing about or you have updates beyond the versions handled by the policy installed. Doing an autorelable is one of the first things I do after installing a new version of Linux.
I guess it depends on if your system is on the Internet and can be reached from the outside. I prefer the extra protection rather than run the chance of havoc an intruder could cause.
Selinux can be troublesome until you get used to it.
Setting sebooleans can relax the policy to allow applications to do things not generally allowed. getsebool -a will list all the booleans and whether they are on or off.
The setroubleshoot packages help in debugging selinux issues. You can write your own policy files. Since installing Rocky 9.5, I have written my own modules for Sanp and ZoneMinder since the policy files in the selinux policy have fallen behind what is required for the new versions.