Sunday, December 17, 2017
Resetting the Linux text console
I've found two different solutions to losing the linux text console or having your X11 session garbled. Initially it seemed impossible to recover from these situations but after much experimentation two solutions were discovered.
First, I'll describe the original solution I found using a somewhat old version of Vector Linux that ran the 184.108.40.206 kernel. As far as I can tell ALT+SYS+K does not work on a kernel this old. Periodically the X11 session will show garbled graphics and switching to the text console via ctrl+alt+F1 just shows the same garbled graphics. I can still type and see some results (the garbled graphics shift a bit) but the computer isn't very useable in this state.
After reading about framebuffers and Linux Kernel Modules I tried "/sbin/modprobe radeonfb" and then my text console reappeared. Even after shutting down the Xserver this module continues to run the text console. One can change the video resolution of the framebuffer via commands like "fbset 640x480-60" or even look at images via the fbi utility.
The 2nd case involved a severe bug in slackware 14.2 whereby exiting the Xserver would just give an entirely black screen and typing seemed to have no effect. The only way to recover seemed to be by typing "/sbin/reboot" in an ssh session from another computer. This computer had the more modern kernel version 4.4.14.
So I tried:
alt+sysrq+k (kills all processes running on the current virtual console)
alt+sysrq+r (switch the keyboard from raw mode, which is used by X11, to XLATE mode)
Now after the alt+sysrq+r key sequence I noticed that I could toggle num-lock and caps lock so clearly the keyboard was still functioning on some level even though I couldn't see anything I typed. So it seemed I was back to rebooting via ssh. Then one day I tried typing "startx" and hitting enter on the blank screen and lo and behold my X11 session worked. So what would happen if I tried exiting from the Xserver now? The text console reappeared! Tricks like loading a framebuffer LKM wouldn't work as the framebuffer is now built into the kernel.
I wish I understood exactly what was happening here although I can hypothesize that some piece of memory was put into a corrupted state. This solution worked on a ASUS P5KPL-AM motherboard with a Intel 82G33/G31 Express Integrated Graphics Controller. To further complicate matters I use xautolock to suspend the computer after 10 minutes of inactivity.
So there you have it. Hopefully one of these solutions will work if you find yourself with a garbled X session or a blank text console.
UPDATE: Jan 16th, 2019
On Slackware 14.2 I've used one other method for restoring the X session:
"sudo /sbin/init 4" which is executed via an ssh session from another computer. This will set runlevel 4 which sets a normal graphical login and also will keep ssh running (note that init 1 would kill the ssh session). One could also kill -9 the X process and run the startx script over again. This appears to be the best method to use if the X session stops working correctly.
Subscribe to Posts [Atom]