Modules, Modprobe, and Modutils: Migration Issues from Linux 2.4 to 2.6

When I migrated from Linux 2.4 to 2.6, I had some trouble with modules loading. In particular, when I booted the machine, my bcm5700.ko module didn't get control of my Ethernet interface; instead, a module called "eth1394" did instead. And then another module, tg3, took a whack at the interface as well; tg3 is the default ethernet driver, but Broadcom recommends their own bcm5700 module instead.

When my Ethernet insterface didn't work at all after booting into 2.6.8, I used "lsmod" to determine what modules were installed, and after loading and unloading modules, starting and stopping networking, and reading /var/log/messages to see how the boot went, discovered that bcm5700 wasn't loading but did work if loaded. This was very puzzling, because /etc/modules.conf was very explicit in trying to load bcm5700 for the eth0 interface.

I went to the /etc/modutils directly and tried to get the eth1394 (which is listed as "ip1394" in the log for unknown reasons) to stop loading. I used:

alias eth1393 off
alias tg3 off

to get these two modules to never load. (The commands went into a file called "networking-A7V8X" that I use to control kernel modules related to networking.) I rebuilt /etc/modules.conf using update-modules, rebooted the machine — and the modules loaded anyway.

In other words, /etc/modules.conf was being ignored by modprobe during boot time.

Eventually I stumbled across the answer by reading the man page for modprobe instead of just skimming it. Modprobe has changed between 2.4 and 2.6. The old information my /etc/modutils and /etc/modules.conf is not read under 2.6, and the Debian upgrade process won't automatically migrate my custom configurations from 2.4 to 2.6.

2.6 uses a /etc/modprobe.d directory, and it does not need a "/etc/modprobe.conf" file; it reads all the appropriate *.conf files and compiles the information at boot time. Very handy, actually.

To solve the problem of the eth1394 and tg3 grabbing the Ethernet interface, I used the "alias x off" commands I list above, placed them in a file in /etc/modprobe.d, and rebooted. This time the system functioned as expected and the Ethernet system used the proper bcm5700.ko driver.

I realize that there are other ways to force a particular driver/module to associate with a particular physical interface (use the "mapping" keyword in /etc/network/interfaces), but this one works for me as I don't need eth1394 for anything at the moment.