Find the answer to your Linux question:
Results 1 to 4 of 4
When you boot Linux, the kernel mostly loads drivers for your hardware automatically without you needing to specify them in /etc/modules.d . But how does it find them? I ask ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,184

    How does the kernel know which modules to load?


    When you boot Linux, the kernel mostly loads drivers for your hardware automatically without you needing to specify them in /etc/modules.d. But how does it find them?

    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?
    "I'm just a little old lady; don't try to dazzle me with jargon!"

  2. #2
    Linux Engineer
    Join Date
    Apr 2012
    Location
    Virginia, USA
    Posts
    881
    According to this Debian Linux Kernel Handbook - Managing the kernel modules
    it is udev that loads them.

  3. #3
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,184
    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.
    "I'm just a little old lady; don't try to dazzle me with jargon!"

  4. #4
    Linux Engineer hazel's Avatar
    Join Date
    May 2004
    Location
    Harrow, UK
    Posts
    1,184
    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!
    "I'm just a little old lady; don't try to dazzle me with jargon!"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •