After coming back from laptop hibernation, my Fedora 27 has gone into a weird state whereby:

  1. On the graphical console, no input is accepted, even mouse activity is disregarded
  2. On the text console, any keyboard input is preceded by '^[' (would that be CTRL+'1 character past Z'?). So when I want to log in, I see ^[r^[o^[o^[t and once login times out waiting for input, it is game over: No more input. Capslock LED is inactive, Numlock LED is active.

I remember seeing this on a boot screen of a Sun SPARCstation in the 90s...

What is going exactly and how can I fix it (except reboot the machine)?

Edit: This has been a "once-only" occurrence on the machine in question. After a reboot, the problem is gone. It might be due to a hardware glitch or any random bug. Although if it is due to an extra special mode of the terminal I/O, one would like to know more.

  • ^[ is the control code for the Esc key. I have seen similar posts, with ^@ (the null character), but both are hard to Google. – muru Mar 7 '18 at 13:57
  • 1
    Possible duplicate of ^@ spam in tty (but seems to be system-wide) - got it, see if that helps – muru Mar 7 '18 at 13:59
  • @muru Interesting, thanks. But I don't think that's it, it is the one and only time I see this happen on the machine in question. A reboot fixed it. It guess it's "one of those things". – David Tonhofer Mar 7 '18 at 16:21
  • 1
    This should not be closed for "offtopic", it's a genuine question that's got an easy fix (see the answer). – Wouter Verhelst Mar 8 '18 at 15:50

The keyboard input subsystem thought that you had the (left or right) ⎇ Alt modifier depressed. That's how the kernel's built-in terminal emulator translates keys if that modifier is in effect. And the GUI apparently thought that you were performing ⎇ Alt-modified mouse gestures and keystrokes.

A keyboard device that sends explicit press and release events, like PS/2 keyboard devices do, can cause this state if for some reason the specific release event for the modifier key is lost, which could well have happened because you were hibernating your system. (With USB keyboards, this problem is slightly harder to create; because USB keyboard HIDs send an encoding of the instantaneous state of all keys on the keyboard, not press and release events, and so any keyboard state change will have signalled that the modifier key was no longer pressed.)

A reboot in such a scenario is overkill. One can simply press and release the modifier(s) again to get the keyboard input subsystem resynchronized with the actual state of one's keyboard.

Further reading

  • Very astute observation (although the terminal emulator is likely not in-kernel, isn't it agetty what is doing it?). The theory is good although in order to get to the text console I had to actually depress the left-ALT key (CTRL+ALT+F2), which didn't fix things. Still, accepting as answer as this is likely as far as we can get. – David Tonhofer Mar 8 '18 at 18:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.