I thought that my desktop had a usb keyboard, but when I checked it doesn't. Anyway, since the motherboard will boot up without a keyboard, I think you are in luck. I don't think you need to edit the bios. If you can get the usb_hid and usb_core modules loaded at boot time, you may not need to unplug and replug the keyboard.
Take a look at which kernel devices are built in and which are modules.
zcat /proc/config.gz will give you the configuration of your running kernel, assuming that that feature was enabled. ( This assumes a 2.6 kernel I believe ). I was surprised to find out that USB_KBD is unset on both my computers. There is a ATKBD device
1730 # Input Device Drivers
1735 # CONFIG_KEYBOARD_LKKBD is not set
2649 # USB Input Devices
2661 # USB HID Boot Protocol drivers
2663 # CONFIG_USB_KBD is not set
2664 # CONFIG_USB_MOUSE is not set
I would suggest an experiment. Before reseating the USB keyboard plug, try to log in remotely with ssh and look at the output of lsmod. ( You can't do that locally if before the keyboard works. ) Are the usb_core and usb_hid
modules loaded. Use something like "lsmod >modulelist1". New unplug the keyboard and plug it in again. And enter "lsm >modulelist2". Now compare the module list. If there is another module loaded, then you want it to load earlier.
If you don't need to interact with the keyboard, such as entering a password to access an encrypted partition, then you might not need to have the USB_HID module in initrd.
Looking at my laptop, there is an /etc/init.d/boot/S03.boot.loadmodules script.
case "$1" in
# Read variable for sysconfig and load all mentioned modules
echo Loading required kernel modules
for I in $MODULES_LOADED_ON_BOOT ; do
if ! modprobe -n $I > /dev/null 2>&1 ; then continue ; fi
rc_status -v1 -r
If I had the same problem, I could simply try adding usbhid and usbcore to the list and see if that works. If you have a similar config script, or can add "modprobe usbcore" and "modprobe usbcore" to an appropriate boot script like linuxrc, you might go for it even if it is a kludge.
Otherwise, we're not chasing a moving target, we are entering the Rabbit hole!
Look in your /etc/hotplug.conf or a script in /etc/hotplug.d/. My system doesn't use hotplug as much as most distro's, so I just have an entry for a USB Kino Shuttle device. There may be an auto vs hotplug option. I have nothing on my system to check against because it uses udev/hal and scripts to do all this. I think that auto may be a better option. But I may be getting confused with the "hwup" script option.
Also check if you have a hwup script. Here is a line from my system's udev rules:
80-sysconfig.rules:SUBSYSTEM=="usb", ACTION=="add", RUN+="/sbin/hwup usb-devpath-%p -o hotplug"
You're system may be configured differently. Like you said, you are trying to hit a moving target, while moving yourself.
That is how they screened tail gunners in WWII. Skeet shooting from the back of a flatbed trailer.
You may be interested in reading the kernel source's /usb/hotplug.txt documentation. Excerpt:
In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
into the bus with power on. In most cases, users expect the devices to become
immediately usable. That means the system must do many things, including:
- Find a driver that can handle the device. That may involve
loading a kernel module; newer drivers can use module-init-tools
to publish their device (and class) support to user utilities.
- Bind a driver to that device. Bus frameworks do that using a
device driver's probe() routine.
- Tell other subsystems to configure the new device. Print
queues may need to be enabled, networks brought up, disk
partitions mounted, and so on. In some cases these will
be driver-specific actions.
This involves a mix of kernel mode and user mode actions. Making devices
be immediately usable means that any user mode actions can't wait for an
administrator to do them: the kernel must trigger them, either passively
(triggering some monitoring daemon to invoke a helper program) or
actively (calling such a user mode helper program directly).
Those triggered actions must support a system's administrative policies;
such programs are called "policy agents" here. Typically they involve
shell scripts that dispatch to more familiar administration tools.
Because some of those actions rely on information about drivers (metadata)
that is currently available only when the drivers are dynamically linked,
you get the best hotplugging when you configure a highly modular system.
My documentation states that udev and hal helper scripts are used in place of a hotplug configuration. It doesn't go any further, such as what in kde is involved when you insert a pen drive. The udev rules pertain to adding a device, but the hal part is still a bit of a mystery.
A moving target! We are battling a hydra from a trapeze.
And I forgot to mention dbus.
Sorry I couldn't be more helpful. There is some good udev documentation I need to study that even shows a block diagram. I would have to study that document and map each config file and script to the diagram before truly understanding it.
Naah! Too much work. Besides the stew I'm heating up for supper is starting to turn into gruel. But to be perfectly honest, I personally would prefer to eat gruel and battle a hydra, before editing my bios with an external tool.