This is a howto on regaining control of your Linux computer when you messed up your normal way to interact with it: keyboard, mouse, video or network access.

You can't interact with your computer anymore

You switched video mode and lost your mouse. Or the screen is suddenly blank or freezed. Or you keyboard input echoes garbage. Or if you use a server, you can't no more ssh to it.

Your computer is in most likelihood still working ok under the hood, and there are quite always better ways to recover than to reboot cold.

Keyboard input echoes garbage

Most likely culprit is wrong configuration of your tty device. This is not critical as you can always switch tty. In general, typing Ctrl-V Ctrl-O will restore sane values.

I encountered one time a garbage case on a linux console, which was solved by:

echo -e \\033c

More details to be found here.

Mouse invisible or unusable because moving erratically

The mouse invisible can happen inside some sophisticated applications (e.g.: some versions of VirtualBox). The best way here is, after possibly switching console, to stop the faulty application.

If the mouse seems moving too fast or too slowly, try changing mouse parameters with tools like xset, or their highlevel desktop cousins. For instance, in Gnome, look for Mouse in the System/Preferences menu.

An erratically moving mouse may indicate, as with keyboard garbage, that the mouse device is badly configured; this used to happen in the past with serial mice. This can also happen if you use the mouse both in X and the console with gpm.

In nothing of the above solves the issue, restarting the X system may be needed, see below.

Mouse pointer freezed or keyboard unresponsive

This can happen with a USB mouse or keyboard, especially if:

  1. You use a KVM switch or
  2. You have switched to a linux console and back to X

Other symptoms: the leds on the keyboard don't change when you hit caps lock, or the leds on keyboard or mouse are off. Simply unplug and plug again the device can solve the issue.

You can verify after the fact that syslog contains messages about USB disconnections of these devices. I know no real definite solution to these issues.

Screen is freezed or blank

Switch to a console, stop cleanly your graphical applications if possible, then restart the X system. If you use gdm, this is how to do it on a Debian system:

/usr/sbin/invoke-rc.d gdm stop
/usr/sbin/invoke-rc.d gdm start

Nothing solves the issue: trying the network

If nothing of the above works, and you can't even get a text console by hitting Shift-Alt-F1, you may connect to your computer through telnet, ssh... That is, you have telnetd or sshd running on it. If not see below.

The file controlling where to start login processes is /etc/inittab. You will have something like that inside:

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100

The 2 first lines will give you a login prompt at the screen (reachable with Alt-F1 and Alt-F2 in text mode, and with Shift-Alt-F1 and Shift-Alt-F2 in graphical mode).

The last one (in general commented out with the #), will start getty on a serial device. Using a second computer running a tool like minicom and linking it using a null modem to the first one, you will get a login prompt on that second computer screen to allow troubleshoot the first one.

What if the line is commented out, what is a null modem, what to do if I have no serial port, and how do I configure minicom? Answers in next section.

Computer control recovery preparation using a serial link

So my advice to maximize your odds to cleanly regain control of your computer is to prepare for that case in advance, by allowing a serial link login. A serial link login has not the security problem of allowing network access.

No serial port on my computer

Except for servers, the rule now is no serial port. But the rule is also to have USB everywhere, and luckily hardware converters serial/link exist. Linux has drivers for a lot of these converters, and you should have no problem getting one, see for instance:

The Linux driver creates a device name like /dev/ttyUSB0 instead of /dev/ttyS0.

Starting a login process on my serial port

You have to edit and uncomment the line in /etc/inittab. Line:

#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100

becomes in case of a serial/usb converter:

T0:23:respawn:/sbin/getty -L ttyUSB0 9600 vt100

You must force the init process to take into account the modified file by issuing command:

telinit q

The null modem

The link above about serial/usb converters offers also null modems. If you don't mind a bit of soldering, it's quite easy to build one yourself.

Minicom configuration

What is needed at the other end of our serial link is a dumb serial terminal. It happens that if you don't have one in your attic, you can emulate one with a second computer. Minicom is one of these emulators.

At that point, you may also discover that you don't have a serial port either on that second computer! Time to go shopping for a second serial/usb converter... It's of course possible to have a serial port on the blocked computer and none on the terminal emulator.

So when you have all the hardware, you can install and configure minicom. Notice that you will have to run minicom as root, or give lax permissions to your serial devices. Minicom configuration file is called /etc/minicom/minirc.dfl under Debian and should contain:

pu port             /dev/ttyS0
pu baudrate         9600
pu bits             8
pu parity           N
pu stopbits         1
pu minit            
pu mreset           
pu rtscts           No

You should only have to change the first line to adapt of your specific serial device name. You may have to hit CR to get the login prompt.

If everything fails

Nothing of the above works? You are in for a reboot, but if the keyboard driver is still alive, you can still get a more a less clean shutdown using the SysRq.