Bug Description

Binary package hint: initramfs-tools

In the event of a problem with the boot sequence, or if the break option is passed on the kernel command line, the initramfs drops to a shell to allow the admin to try and recover, but the USB keyboard drivers are not loaded, so if one does not have a PS/2 Keyboard, one can not recover the system.

This is only a problem with break=premount or earlier. break=mount happens after hal/udev have loaded drivers for everything.

Note that some servers don't _support_ ps/2 keyboards anymore. e.g. I have a rack of Dell PE1950 machines with a KVM-over-IP that connects to 1 USB port and their VGA out. I don't think the PE1950 even has a PS/2 port anywhere.

The best fix for this is probably in scripts/functions:panic(). It already does
modprobe i8042
modprobe atkbd
before dropping to a shell.

So just add maybe
modprobe ehci-hcd
modprobe hid
to that. I think that's right. I'll see if I can boot a machine with a ps/2 and usb kbd attached, and load modules until the USB kbd starts working at break=premount.

Hmm, I don't know how to detect the right USB controller module. ehci-hcd is for usb2.0 machines, and older hardware only has uhci-hcd or ohci-hcd. There might be laptops with no ps/2 ports, broken internal keyboards, and only USB1.1 support. Other than that, this fix would be enough for most people, since USB keyboards are most often used on newer computers. At least USB1.1 computers will have PS/2 ports...

The line we want to match with grep is
H: Handlers=kbd
(that line has a trailing space.)
In a fully running kernel, the line is e.g.
H: Handlers=kbd event1

It's ok to load both USB modules, esp. since this only happens with break=whatever, or some other panic. So they won't be loaded for most people's normal boots. When we're trying handle errors, it's better to be safe. And it won't load anything extra if a keyboard of any kind is known to the kernel, thanks to grep on /proc/bus/input/devices.

I'm not aware of USB host drivers other than ohci and uhci; They should work for almost all hardware ever. ehci-hcd isn't needed for keyboards, and is not sufficient for using them. I guess it _only_ handles USB2.0 HighSpeed devices.

After modprobing both USB HCD drivers, I exitted from the break=premount shell, and the boot continued normally from my USB drive. ehci-hcd was loaded properly and both keyboards work after boot. (K8V mobo, Via K8T800 chipset.)

USB module loading order: Linux 2.6.27.3's changelog says that Linux will now warn if ehci isn't loaded before o/uhci. And that it has always been better to load ehci first. So panic() should load ehci-hcd first, then try the other two, in case the user works around a problem and goes on to boot up.

Perhaps one of these options would make a sensible default in this day and age, or at least something obvious to note with an appropriate message when dropping to an initfamfs shell? This would have saved quite a few 'hard lockup' reboots on my system over the last few months before I discovered the reason.

* Include usbhid in the list of modules we probe in the panic function,
since we may panic before udev runs and most keyboards are USB these
days. Closes: #229732.
* Add ohci_pci to the list of USB host modules included in the initramfs,
needed on some systems and not a built-in driver in Ubuntu.
LP: #1238194.
-- Steve Langasek <email address hidden> Thu, 24 Oct 2013 13:40:43 -0700

Have uploaded the fix for this to trusty, but managed to use the wrong changelog syntax. Here's the changelog entry for the upload:

initramfs-tools (0.103ubuntu2) trusty; urgency=low
.
* Include usbhid in the list of modules we probe in the panic function,
since we may panic before udev runs and most keyboards are USB these
days. Closes: #229732.
* Add ohci_pci to the list of USB host modules included in the initramfs,
needed on some systems and not a built-in driver in Ubuntu.
LP: #1238194.