SRU justification:
Impact (from Scott):
The ub driver is an old attempt for a slow USB Block Device driver,
it hasn't been maintained in quite a while and we don't have an easy
way to enable it.
libusual is a strange mechanism for the kernel to auto-select between
usb-storage and ub. It works by stealing the aliases from them both
and modprobe'ing (from the kernel) the other module when a device is
connected.
The trouble is that because it's built into the kernel, on machines with
particularly fast init, it could be trying to call it before the initramfs
has even been switched to - or before the initramfs has called "depmod".
In either case, since there's no modules.alias/modules.dep files, the
modprobe call with fail and the USB storage device will not be enabled.
Plugging a second USB storage device in will magically cure the problem.
Fix: Attched patch to disable those modules. This bumps ABI as the libusual functions go missing. All IDs automagically go over to usb-storage.
Testcase: Booting from usb storage with a quick host.
---
Continuing from bug #363038
Pete Graner's problem with the Dell Latitude XT was that the kernel was calling "modprobe usb-storage" before the initramfs has run "depmod" to initialise the module db.
This was all crack.
There's no reason to have the kernel call modprobe in this way, it was caused by something called "libusual" which steals all of usb-storage's aliases and then modprobes it. The intent is that it allows you to alternate between "usb-storage" and "ub".
Not only is "ub" very crufty and unmaintained, but we can do that kind of switching in userspace these days.
Disabling libusual in the kernel config means that usb-storage gets modprobe aliases just like every other driver, and is loaded by udev just like every other driver. Race condition solved, laptop boots.
Patch has been committed to Karmic kernel tree