Something weird is going on with my keyboard. The keyboard is a USB-connected Unicomp, which works absolutely flawlessly once the computer is up and running. However, GRUB 2 (specifically, 1.99-27+deb7u1 as shipped in Debian Wheezy) isn't quite so happy. The failure modes make this a little difficult to test, but here's what I've been able to deduce thus far:

  • The keyboard status LEDs flash during the POST, so the keyboard is detected (I also get a report "Detected: ... 1 Keyboard"); I've got maybe one "no keyboard detected" error from the POST, nowhere near enough to deduce any pattern to that, and I've been rebooting the system quite a few times in different ways lately
  • On a power on from a full power off with the front panel power button, everything seems to work great
  • On a reboot (either using reboot or Control+Alt+Delete in a booted system or in GRUB), the keyboard works in GRUB maybe every other time I try
  • If I hit the Reset button on the computer to reboot, the keyboard consistently does not work in GRUB when the boot loader comes back, and many times does not react to key presses during the POST either

What's even more weird is that I don't recall the computer acting like this before. I'm hoping it's unrelated, but it seems to have started acting up right around when I hooked up the UPS to some more things around my desk, instead of only having hooked it up to the computer and monitor. (No, the UPS is nowhere near overloaded; the load is reported as being in the range 7-20% depending on usage; around 15-16% of maximum load when the computer is up and running normally.)

I've Googled and found the suggestion to load the GRUB 2 modules uhci and usb_keyboard. I added a GRUB_PRELOAD_MODULES declaration specifying the two of them to /etc/default/grub and re-ran update-grub (there is now insmod uhci and insmod usb_keyboard in my /boot/grub/grub.cfg), but that does not seem to have changed anything.

I've moved the keyboard to another USB port, which does not appear to have helped. I would try an offboard USB controller if I had one handy.

BIOS/UEFI setup reports legacy USB support and legacy USB 3.0 support as enabled, and even if it didn't, I don't see why it would sometimes work and sometimes not, especially when many times the only difference between the two is which side of a warm reboot it's on.

The motherboard is an ASUS M5A97 Pro with UEFI version 1007 02/10/2012.

I can't think of any other configuration changes I've done that coincide with when the computer started acting up. The logs do mention an upgrade of linux-image on Aug 1, and that I reinstalled (it's noted as upgrade, but the from-version and to-version are identical) grub-pc on Aug 2, but both of those was a week before I even bought the UPS, and two weeks before I hooked it up to more than just the computer and monitor (I take care to not change too many things at once). uname -r reports 3.2.0-4-amd64.

I'm running out of ideas to try. How can I get my USB keyboard to work consistently in GRUB 2? What else can I check?

  • I've had related symptoms but on an unrelated setup (Win8+MS wireless usb kb). Either in grub or when coming back from "sleep", the mouse would work but not the kb. I haven't had the issue for a while now and what happened in between was that I reinstalled from scratch with format on the whole drive. I have no clue what did it but most of the time when it happened, unplugging then replugging the usb connection usually solved it.
    – user44370
    Aug 23, 2013 at 22:19
  • I think the answer to this may lie in a BIOS that's not resetting some critical control register on soft-boots. If a hard-boot (power cycle) makes things work fine, it is very likely code that runs before grub is ever loaded that's at issue.
    – msw
    Aug 24, 2013 at 3:18
  • I can confirm my setup includes an older Asus board, with AMI bios.
    – user44370
    Aug 24, 2013 at 4:29
  • @msw Yes, I'm getting that feeling too (which is why I mentioned both the motherboard model and BIOS/UEFI version) but what puzzles me is that it seems to have started just recently, coinciding with a completely unrelated change and not being anywhere near any change which would seem relevant. If something wasn't getting reset properly I'd also expect using the reset button to work better, but from my experiments it seems to do worse.
    – user
    Aug 24, 2013 at 11:15
  • 1
    I just noticed on the ASUS web site for the M5A97 Pro that there have been half a dozen new BIOS versions, several of which are listed as "Enhance compatibility with some USB devices". They are now at 1604 whereas I'm at 1007. Going to give upgrading a try and see if that helps.
    – user
    Aug 24, 2013 at 11:27

1 Answer 1


Well, I kinda-sorta found out what's wrong. I still don't know what's the underlying problem, though.

Upgrading the UEFI/BIOS to the most recent version (currently 1604) did not help, despite the fact that a few interim releases were specifically advertised as "enhance compatibility with some USB devices" (which appears to have been my exact problem). In fact, if anything, it seemed to make matters worse, but in a good way: the system started consistently failing to be able to use the keyboard on a warm reboot. Consistent errors are always easier to debug and fix.

By applying the scientific method (form a hyphothesis, figure out a way to test it, test and refine), I was able to determine that the most likely culprit is my USB mouse or more generally having a USB pointing device of mine connected.

I started out by disconnecting everything USB-connected that wasn't absolutely necessary to test the failure case, so the only peripheral which was on the USB bus was the keyboard. That worked. So I added things back, one at a time, testing as thoroughly as I could between each change. Things started acting up by the time I added the desk hub, to which I had hooked up two devices: my mouse and drawing tablet. After some back-and-forth, I unplugged both of those but left the hub connected; still had the same issues. Plugging only either the hub, the mouse or the tablet directly into the USB ports on the motherboard got me back to where I started, which meant that one or more of those were causing my problems.

I can do without the tablet, but using the computer with no pointing device gets rather tiresome really fast, so I dug around in my spare computer cables box and found a USB to PS/2 adapter which I thought I'd give a try. Having plugged the mouse into the adapter and the adapter into the PS/2 mouse/keyboard port on the motherboard, things seem to be working. I did as full a test as I could think of and each time the system came back completely normally.

My current working hypothesis is that something has caused damage to the USB hub which may have propagated to the tablet and mouse, and that this damage is somehow causing my problems. (The only two non-host devices I've had connected to the hub is the mouse and tablet.) That doesn't fully explain why connecting the mouse through a USB-PS/2 adapter seems to work just fine, but a guess is that it might have something to do with how the BIOS handles the different devices (it does not seem to recognize a "PS/2" mouse as a mouse, but I can certainly live without the mouse in the UEFI setup).

I'll be able to test this hypothesis further next week, assuming I can borrow a USB mouse from work.

For now, disconnecting the hub and tablet and having moved the mouse to the PS/2 port appears to be good enough.

  • IANAEE, but USB has always seemed to me to be unduly sensitive to trivial variation in signal levels sigh. On the other hand Science. It works.
    – msw
    Aug 24, 2013 at 14:45
  • 1
    @msw Indeed it does. When all else fails, the scientific method is usually worth trying, even if (as in this case) it means crawling around on the floor for an hour and a half testing different combinations...
    – user
    Aug 24, 2013 at 16:33
  • I'm having the same problem except that I have no external USB devices connected to the laptop in question. I often have to hold down the power button to cold-boot, boot back to the LUKS password prompt, and try again. If I hit enter and the cursor goes to the next line, I know it worked that time. If it doesn't, it's another attempt after a cold-boot.
    – xendi
    May 11, 2021 at 23:44
  • (1/) Commenting a million years later, but this is really interesting. The idea that hitting Reset triggers the failure state should not be technically possible; you're taking $everything offline for half a second when you do that. This suggests the problem *has to* be electrical. Your mention that this started around the time of introducing a new UPS only makes me squint at electricity more.
    – i336_
    Aug 18, 2022 at 0:29
  • (2/) I had an interesting situation a while back where my PC decided one day after a power failure not to turn on anymore. "Oh noooo", etc etc; ok first step unplug everything I can from the back... and we're back up and running. Cue "wat?!", iterative reconnecting, and a dozen reboots; and I finally isolated a new USB hub I connected shortly before the power failure. Oooohh... but... what can a USB hub do? This was a simple USB 2.0 hub with a power brick - perfectly innocent, right? Well it used a 5V power brick, so simply bridged the little DC power jack with the 5V and GND USB lines.
    – i336_
    Aug 18, 2022 at 0:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .