Results 1 to 4 of 4
Enjoy an ad free experience by logging in. Not a member yet? Register.
How does the kernel know which modules to load?
I ask because I have a handmade system originally based on Slackware 13.37 and I am in the process of upgrading it to Slackware 14. I built my new kernel using the same configuration file as before (except for setting DEVTMPFS and DEVTMPFS_MOUNT because modern udevs require them). I upgraded udev, removed module-init-tools (which Slack 14 doesn't use) and installed kmod instead.
The system boots but it no longer loads most of my drivers. In particular my ethernet card doesn't work and there is no usb. I can still load the drivers by hand and they work fine but they aren't loaded automatically any more.
I have some interesting udevd errors which may be relevant:
Bind failed. No such file or directory
udevd error binding udev control
Unfortunately they don't say which file or directory is causing the problem and they don't appear in any of the system logs so I can't tell at what point they occur.
Is it actually udev that loads the drivers?
- Join Date
- Apr 2012
- Virginia, USA
According to this Debian Linux Kernel Handbook - Managing the kernel modules
it is udev that loads them.
Well, I've got a little bit further. I noticed that udevd wasn't actually running so I started it by hand using the init script that came with it. It ran normally and all the missing drivers appeared as if by magic. So there's nothing wrong with udev or the kernel; it's a timing error of some kind.
I googled that udevd creates a socket file called /run/udev/control, where it listens for uevents from the kernel; when udevd is started by hand, this file duly appears. It is not there directly after booting and I think the error messages about "error binding udev control socket" and "file not found" must refer to the failure to create it. Probably this is a fatal error which causes udevd to exit.
Now I need to find out what causes this failure.
Sorted it! There has been a huge leap in udev versions between Slackware 13.37 and Slackware 14. A major change is that udevd now creates its control socket in /run/udev, not /dev/.udev. That means that /run must be writeable. For a while there was a fallback to /dev/.udev in case /run was read-only but that was later removed.
Slackware 13.37 had /run on the root partition (which is read-only at this stage to allow for it being fsked). The new sysvinit scripts create a tmpfs on /run so that udevd can create its socket there, but I was using a much simpler script of my own which didn't have this wrinkle. So it worked with the old udev but not with the new one.
I have now updated my script to mount a tmpfs before running udevd and that has fixed the problem. It's very satisfying when you can solve a problem like this. Makes you feel empowered!