Description of problem: start_udev is run before dkms_autoinstaller during the boot process. By re-running start_udev if new modules are installed, the supported hardware will be re-detected and the proper modules loaded. This is very important for hotplug devices with out of kernel drivers. I would attach a patch, but this is pretty basic behaviour.
I'm sorry, this had escaped me for so long. Adding Harald for his perspective on calling start_udev, as it's not something I've looked into before. Harald, if new modules are built and installed into the /lib/modules tree, and depmod is run, does udev need to know of this?
Adding Kay for his perspective as well.
It's probably enough to run: udevtrigger or even: udevtrigger --subsystem-match=<bus> --subsystem-match=<bus> if you know the buses you installed drivers for.
Kay was faster :)
That all sounds good. I am also working on adding dkms support to the new-kernel-pkg script. This will allow dkms kernel modules to be built and removed directly from kernel rpm scripts. This should allow for better notification if a dkms module fails to build and can allow us to "fallback" to the last fully working kernel until the problem is fixed.
Here's what I'm proposing to put into DKMS to address this. This goes at the end of 'dkms install'. How's this look? Without parsing the module for modinfo, I don't know the bus. Should I do something like: modinfo aic7xxx.ko | grep ^alias | awk '{print $2}' | awk -F: '{print $1}' to get each of the busses and pass that? diff --git a/dkms b/dkms index 13dbc54..98ce503 100755 --- a/dkms +++ b/dkms @@ -1247,6 +1247,11 @@ function install_module() fi fi + # Notify udev if we installed something for the currently running kernel + if [ -x /sbin/udevtrigger -a "${kernelver_array[0]}" == "$(uname -r)" -a "${arch_array[0]}" == "$(uname -m)" ]; then + /sbin/udevtrigger + fi + echo $"" echo $"DKMS: install Completed." }
2.0.17.5 is released with the above patch. Closing.