# Module autoloading weirdness

## hazelnusse

I'm perplexed:  All my kernel modules are loading at boot time, totally normal, but I have nothing at all in the files /etc/modules.autoload.d/kernel-2.6 (or kernel-2.4).  There is nothing in either of those files, yet all my modules: agpgart, fglrx, ipw_2200, and others are all getting loaded somehow.  Is it magic?  Where is the configuration file that  lets you change them?  I have been using Gentoo for over two years now, and in the past, if I wanted a module loaded, it was necessary for it to be in kernel-2.6.  Is this information being stored somewhere else?

Thanks,

Dale

----------

## troymc

Look into udev/hotplug/coldplug and you should find your answers.

troymc

----------

## hazelnusse

 *troymc wrote:*   

> Look into udev/hotplug/coldplug and you should find your answers.
> 
> troymc

 

No I wasn't able to find my answers there.  Can you be more specific?  I've done a text string search in the /etc directory for all the modules that are being loaded at boot, and no files that are found have anything to do with module loading....  

Why would this change in the first place?  Which file do I need to edit, for instance to prevent my wireless module from being loaded at boot time if I don't want to use wireless?  

Thanks,

Dale

----------

## thepustule

For some completely inexplicable reason, the coldplug functionality is being merged into udev.  Even though this is clearly NOT what udev is supposed to be doing!

I'm going to have to mask my udev below 0.89 to keep my system from being ruined!

----------

## troymc

 *hazelnusse wrote:*   

>  *troymc wrote:*   Look into udev/hotplug/coldplug and you should find your answers.
> 
> troymc 
> 
> No I wasn't able to find my answers there.  Can you be more specific?
> ...

 

Sorry if I wasn't clear. I didn't mean that as a directory path. udev, hotplug and coldplug are userspace applications that autodetect hardware & load the modules for it.  In general, they are "good" things.

 *thepustule wrote:*   

> 
> 
> For some completely inexplicable reason, the coldplug functionality is being merged into udev. Even though this is clearly NOT what udev is supposed to be doing!
> 
> I'm going to have to mask my udev below 0.89 to keep my system from being ruined!
> ...

 

I fully understand your frustration.  I don't know who decided that just because you have the hardware that you MUST want the module loaded immediately & constantly.  I thought that the whole idea of an autoloading, modular kernel was to only load the modules you need, when you need them.  That damned eth1394 module is a particular peeve of mine.  Some moron thinks that everyone in the world who has a firewire interface wants to use it as a network device. WTF?    :Evil or Very Mad: 

troymc

----------

## thepustule

Indeed.

Have you ever actually tried to use eth1394 with a cable between 2 computers?  It's hard enough to get it working with Linux on the other end, let alone any other OS...

Is there a way to influence these decisions?

----------

## troymc

 *thepustule wrote:*   

> Is there a way to influence these decisions?

 

Violence or cash.     :Shocked: 

troymc

----------

## nephros

I completely agree, especially with what troymc said above.

The udev devs deal with that in their FAQ (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ)

 *Quote:*   

> Q: But udev will not automatically load a driver if a /dev node is opened
> 
>    when it is not present like devfs will do.
> 
> A: Right, but Linux is supposed to load a module when a device is discovered
> ...

 

I couldn't disagree more.

 *Quote:*   

> Q: Oh come on, pretty please.  It can't be that hard to do.
> 
> A: Such a functionality isn't needed on a properly configured system. All
> 
>    devices present on the system should generate hotplug events, loading
> ...

 

I used to do exactly that. Now I cannot anymore.

Can someone explain how they think this can be done?

udev is among the first things to get started on system bootup, (probably even before / is mounted rw, haven't checked) and will load the whole shebang in /lib/modules long before any script can kick in.

Or am I supposed to keep an empty (minimal) modules.conf for boot time and use some hackish script to replace it sometime after the system is running? Kind of defeats the purpose of modules.conf doesn't it?

----------

## Gergan Penkov

At least it should respect some blacklist!

It is simply ridiculous

----------

## dsd

coldplug will become more configurable soon

remember you are using the testing tree

as for module loading when /dev node is opened, that happens anyway. if you want that functionality, just create the device nodes. you probably want to unmerge udev and install static-dev.

----------

## troymc

 *Gergan Penkov wrote:*   

> 
> 
> At least it should respect some blacklist!
> 
> It is simply ridiculous
> ...

 

/etc/hotplug/blacklist completely excludes those modules from autoloading. We want them all autoloaded - just not all loaded at boot.

 *dsd wrote:*   

> 
> 
> as for module loading when /dev node is opened, that happens anyway.
> 
> 

 

Yes, the kernel's autoloading of modules upon first use is the behaviour we know and love.

The udev team seems to be conflating dynamic device node creation and module loading in a way that is short-circuiting this behaviour.

 *dsd wrote:*   

> 
> 
>  if you want that functionality, just create the device nodes. you probably want to unmerge udev and install static-dev.
> 
> 

 

C'mon guys, be reasonable. Are you seriously suggesting that we have to go back to the 90s and manually handle our /dev nodes and that the functionality we've enjoyed for the past 6 years is no longer available?

I've had floppy.o built as a module for almost 10 years now, and the only time it is ever loaded is when I've mounted a floppy. Now, if I have the module built, it has to be loaded at boot?  or I have to go back to loading it manually, and creating the device node manually?

Plus, items like eth1394 are firewire devices. They should only be loaded when that device is used/present. I have modules built for a bunch of USB stuff - my printers, a scanner, a modem, etc. Should they all be autoloaded at boot, too?

I guess it is simply a matter of semantics. What does the term autoload mean? Loaded every boot and kept persistently? or loaded when needed and unloaded when not?  

In the past, it's always been loaded/unloaded as needed.

 *dsd wrote:*   

> 
> 
> coldplug will become more configurable soon
> 
> remember you are using the testing tree 
> ...

 

Understood. It's just an annoyance to me NOW.      :Very Happy: 

And, yes, I do need to go read & learn more about this new "feature" that is really messing with my world. I don't seem to understand their mindset.

troymc

----------

## Gergan Penkov

 *troymc wrote:*   

>  *Gergan Penkov wrote:*   
> 
> At least it should respect some blacklist!
> 
> It is simply ridiculous
> ...

 

This seems to be only theory.

/var/log/messages

```
...

May 20 11:55:01 gero Freeing unused kernel memory: 152k freed

May 20 11:55:01 gero ath_hal: module license 'Proprietary' taints kernel.

May 20 11:55:01 gero ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)

May 20 11:55:01 gero ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)

May 20 11:55:01 gero ACPI: PCI Interrupt Link [APCF] enabled at IRQ 22

May 20 11:55:01 gero ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 22 (level, high) -> IRQ 177

May 20 11:55:01 gero PCI: Setting latency timer of device 0000:00:02.0 to 64

May 20 11:55:01 gero ohci_hcd 0000:00:02.0: OHCI Host Controller

May 20 11:55:01 gero ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1

May 20 11:55:01 gero ohci_hcd 0000:00:02.0: irq 177, io mem 0xdf003000

May 20 11:55:01 gero wlan: 0.8.4.2 (svn 1531)

May 20 11:55:01 gero ath_rate_amrr: 0.1 (svn 1531)

May 20 11:55:01 gero ath_pci: 0.9.4.5 (svn 1531)

May 20 11:55:01 gero Linux agpgart interface v0.101 (c) Dave Jones

May 20 11:55:01 gero usb usb1: configuration #1 chosen from 1 choice

...
```

/etc/hotplug/blacklist

```
#

# Listing a module here prevents the hotplug scripts from loading it.

# Usually that'd be so that some other driver will bind it instead,

# no matter which driver happens to get probed first.  Sometimes user

# mode tools can also control driver binding.

#

# Syntax:  driver name alone (without any spaces) on a line. Other

# lines are ignored.

#

# uhci ... usb-uhci handles the same pci class

usb-uhci

# usbcore ... module is loaded implicitly, ignore it otherwise

usbcore

# tulip ... de4x5, xircom_tulip_cb, dmfe (...) handle same devices

de4x5

# At least 2.4.3 and later xircom_tulip doesn't have that conflict

# xircom_tulip_cb

dmfe

#evbug is a debug tool and should be loaded explicitly

evbug

# Don't hotplug eth1394, bug #128962

eth1394

shpchp

ath_pci

ath_hal

wlan

```

/etc/modules.autoload.d/kernel-2.6

```
# /etc/modules.autoload.d/kernel-2.6:  kernel modules to load when system boots.

#

# Note that this file is for 2.6 kernels.

#

# Add the names of modules that you'd like to load when the system

# starts into this file, one per line.  Comments begin with # and

# are ignored.  Read man modules.autoload for additional details.

# For example:

# 3c59x

#ath_pci

loop

ndiswrapper

squashfs

unionfs

nvidia

ide-cd

svgalib_helper

snd_cmipci

snd_intel8x0
```

Now if this is a working solution, I simply do not want to load the atheros drivers, I use ndiswrapper in the moment.

----------

## troymc

 *Gergan Penkov wrote:*   

>  *troymc wrote:*    *Gergan Penkov wrote:*   
> 
> At least it should respect some blacklist!
> 
> It is simply ridiculous
> ...

 

So udev even ignores blacklist?!  Unbelievable!    :Evil or Very Mad: 

troymc

----------

## dsd

 *troymc wrote:*   

> The udev team seems to be conflating dynamic device node creation and module loading in a way that is short-circuiting this behaviour.

 

seems a little odd to bring this up now, given that its been happening for years, and its not related to coldplugging. but yes, this is how udev does things.

 *Quote:*   

> I've had floppy.o built as a module for almost 10 years now, and the only time it is ever loaded is when I've mounted a floppy. Now, if I have the module built, it has to be loaded at boot? or I have to go back to loading it manually, and creating the device node manually? 

 

my advice to you, and every other manual compile kernel user we have, is avoid modules where possible. build floppy support directly into your kernel image, and accept the fact that it uses near zero memory until you actually mount a floppy. this wasnt the case with 2.4, but 2.6 contains a new driver model which means there is almost zero expense for loading modules that you arent using.

if you insist on living any other way without good reason, then you'll have to make some sacrifices, tinker with things, or whatever else.

 *Quote:*   

> I have modules built for a bunch of USB stuff - my printers, a scanner, a modem, etc. Should they all be autoloaded at boot, too? 

 

usb is hotpluggable, so no (assuming the devices are disconnected). are they being autoloaded even without the devices attached?

even though usb might be more suited for hotplugging and module autoloading like this, i still suggest that you build support for your hardware into the kernel image, unless you have good reason not to. the kernel is much better at autoloading its own components than userspace is at loading modules.

----------

## dsd

if it helps your understanding at all, udev's coldplug functionality is a slightly more complicated version of this:

```
  for i in /sys/block/*/*/uevent; do echo 1 > $i; done

  for i in /sys/class/*/*/uevent; do echo 1 > $i; done

  for i in /sys/bus/*/devices/*/uevent; do echo 1 > $i; done
```

that is, it generates hotplug events for all devices already present on the system.

hotplug events are usually only generated at the point devices are physically attached.

----------

## Gergan Penkov

This has nothing to do with udev, at least in my case (or it is even more complicated), somehow earlier kernels, do not load the modules in this way.

Writing some udev rule did not help in my case, as the modules are loaded before udev kicks in, so it does not create the devices with these rules but the modules are loaded, or at least this was after a short debugging, what really helped now, is this file:

```
cat /etc/modules.d/blacklist

blacklist ath_hal

blacklist ath_pci

blacklist ath_rate_amrr

blacklist wlan

blacklist wlan_scan_sta

```

and probably this udev rule (I haven't tested it without them for now and it is probably superfluous)

```
 cat /etc/udev/rules.d/01-atheros.rules

SUBSYSTEM=="module",    DRIVER=="ath*", OPTIONS="ignore_device,last_rule"

SUBSYSTEM=="module",    DRIVER=="wlan*",        OPTIONS="ignore_device,last_rule"
```

but now at least all works as I want it.

----------

## Gergan Penkov

The problem here is that just not listing sth in modules autoload, with earlier udev and kernels, prevented them from loading, now I must blacklist sth in order not to be loaded automagically.

----------

## troymc

 *dsd wrote:*   

> 
> 
>  *troymc wrote:*   The udev team seems to be conflating dynamic device node creation and module loading in a way that is short-circuiting this behaviour. 
> 
> seems a little odd to bring this up now, given that its been happening for years, and its not related to coldplugging. but yes, this is how udev does things.
> ...

 

Hmmmm....maybe I have been living under a rock and never noticed, but then I only switched to udev sometime late last year.    :Razz: 

I'm going thru the udev page right now, to try and understand some of these changes.

 *dsd wrote:*   

> 
> 
>  *Quote:*   I've had floppy.o built as a module for almost 10 years now, and the only time it is ever loaded is when I've mounted a floppy. Now, if I have the module built, it has to be loaded at boot? or I have to go back to loading it manually, and creating the device node manually?  
> 
> my advice to you, and every other manual compile kernel user we have, is avoid modules where possible. build floppy support directly into your kernel image, and accept the fact that it uses near zero memory until you actually mount a floppy. this wasnt the case with 2.4, but 2.6 contains a new driver model which means there is almost zero expense for loading modules that you arent using.
> ...

 

For hardware drivers I've been moving this way for awhile now. If it's built in the box, it's built in the kernel. Only external modular devices (USB, firewire, scsi, etc) are built as modules. I've just been resistant about some devices that rarely ever get used like floppy.o and ftape.o. I have another old workstation with a SCSI card & a bunch of old scsi devices hanging off of it. I left the whole SCSI subsystem modular and used to only load it when I needed to use one those devices. But now I'm finding that the SCSI subsystem loads at boot whether I want it to or not. 

 *dsd wrote:*   

> 
> 
>  *Quote:*   I have modules built for a bunch of USB stuff - my printers, a scanner, a modem, etc. Should they all be autoloaded at boot, too?  
> 
> usb is hotpluggable, so no (assuming the devices are disconnected). are they being autoloaded even without the devices attached?
> ...

 

No, but that's my point about the eth1394 module. It IS being autoloaded. This is not a Firewire controller module, this is a module to make your firewire port look like an ethernet NIC. It is a firewire client device and it should not get autoloaded at boot any more than my USB printer modules should.

I have helped several people who had problems because, during the gentoo install, this module gets loaded first and becomes eth0 and net-setup fails, then they configure everything for their onboard NIC as eth1, rebuild their kernel w/o eth1394, reboot, and now their NIC is eth0. So they end up confused twice over.  Add a wireless device in there too, and the confusion level rises even more. (This has come up several time in the Installing Gentoo forum - do a quick search for eth1394 in there & look at the network issues.)

And, on a side note: Thank you for spending some of your time helping us out on these forums. It is very important to us, and very much appreciated.

troymc

----------

## dsd

yes, i'm aware of those problems, the situation isnt great but it is improving. possible solutions are: use udev to automatically rename your net interfaces to more appropriate names, based on their mac address. e.g. on my home router system, i have "wan" and "lan" rather than eth0 and eth1. another approach is configuring the new baselayout (1.12) to configure network interfaces based on their mac address, rather than their interface name.

a possible improvement for net-setup is to make it print out the details of the interface before the user configures it. you can get this info from sysfs, e.g:

mac address: cat /sys/class/net/eth0/address

device type (pci/usb/etc): readlink /sys/class/net/eth0/device

driver: readlink /sys/class/net/eth0/device/driver

for pci devices, the manufacturer/product name could also be deduced by looking at /sys/class/net/eth0/device/{device,vendor} and then looking up those ID's in the pciutils database.

maybe it would be worth filing a feature request bug for this.

i expect eth1394 will get blacklisted from udev-coldplug when it becomes more configurable. it was blacklisted from hotplug-coldplug due to it being rarely used yet causing a lot of confusion in this area.

your general argument against coldplugging eth1394 isnt complete though:

usb and firewire are both multifunction buses but you cant compare them network-wise. you can network computers through eth1394 just by connecting a standard firewire cable between them (comparable to an ethernet card with Xover ethernet cable) - this is not possible with usb. so, you should view firewire as a multifunction bus *and* network adapter, whereas you can only view usb as a multifunction bus.

now, viewing firewire as a network adapter, compare it to an ethernet adapter. ethernet card modules (8139cp, forcedeth, those kind) are autoloaded on boot regardless of whether they are actually connected to anything. same with eth1394 in this example. makes sense to a certain degree, right?

----------

## troymc

 *dsd wrote:*   

> 
> 
> now, viewing firewire as a network adapter, compare it to an ethernet adapter. ethernet card modules (8139cp, forcedeth, those kind) are autoloaded on boot regardless of whether they are actually connected to anything. same with eth1394 in this example. makes sense to a certain degree, right?

 

Sorry, I'm having a hard time getting my head around that one.

Just because a device can be configured as a network device doesn't mean it should be by default.

By that logic we should also be autoloading IrLAN, IrNET, PLIP, SLIP  and a host of other possible interfaces.

Wouldn't it make more sense to configure the NICs as NICs and leave the other stuff to the user?

troymc

----------

## dsd

PLIP and SLIP are not hardware-specific right? they are general upper layers, so they wont be autoloaded with this kind of system.

IR networking modules are (or should be, if hotplug-capable) autoloaded if IR networking hardware is present, exactly the same as eth1394, exactly the same as other networking hardware.

i'm not judging whether or not this makes sense in a distro environment - i'm just saying why it happens. a networking piece of hardware is attached, so the networking driver for that hardware is autoloaded. ethernet, firewire, wireless, IR all fall into this category.

the hotplug architecture is quite simple:

a device is attached, the bus driver (e.g. pci, usb) generates a hotplug event. the hotplug event is passed to the userspace hotplug agent. the agent examines the device, and examines any modular drivers which claim to support it. the new device is a networking-capable firewire adapter, and there is a module on the system which claims to support networking-capable firewire adapters, so it gets loaded.

there is no additional logic involved, nothing like "lets see, this is a firewire adapter, and firewire isn't networking only, and 99% of firewire users dont actually use the networking part, not to mention the number of users who get confused when this module is loaded, so lets not load this one today"

its plain and simple: it sees a device, and finds a driver which claims to support that device, so it loads that driver

----------

## troymc

 *dsd wrote:*   

> PLIP and SLIP are not hardware-specific right? they are general upper layers, so they wont be autoloaded with this kind of system.

 

No, actually I see PLIP as a direct analog of this eth1394 issue. It simply uses the parallel port instead of the firewire port. modprobe plip and I have a ethernet device ready to configure & connect, just need a cable.

```

# modprobe plip

# ifconfig plip0 192.168.1.1

# ifconfig

 ...

plip0     Link encap:Ethernet  HWaddr FC:FC:C0:A8:01:01  

          inet addr:192.168.1.1  P-t-P:192.168.1.1  Mask:255.255.255.255

          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:10 

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:7 Base address:0x378 

```

SLIP is the same, it just seems like an upper layer because we generally use modems and need to run some other software to manage the modem and make the initial connection. None of that is needed with a direct cable connection (null modem cable), however a usermode program is necessary to attach the driver to a specific serial port (slattach). So maybe that would exempt this one.

 *dsd wrote:*   

> IR networking modules are (or should be, if hotplug-capable) autoloaded if IR networking hardware is present, exactly the same as eth1394, exactly the same as other networking hardware.

 

Again, no. The IR networking modules are not autoloaded. At least not on my system. But all I have to do is modprobe them and I have a working interface.  I've tried looking for the rules for this in the udev rules files, but I don't understand the rules files enough yet.  I can't even identify the rule which is loading the eth1394 module.     :Confused: 

```

# modprobe irlan

# ifconfig -a

    ...

irlan0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  

          BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:4 

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

```

 *dsd wrote:*   

> 
> 
> a device is attached, the bus driver (e.g. pci, usb) generates a hotplug event. the hotplug event is passed to the userspace hotplug agent. the agent examines the device, and examines any modular drivers which claim to support it. the new device is a networking-capable firewire adapter, and there is a module on the system which claims to support networking-capable firewire adapters, so it gets loaded.
> 
> there is no additional logic involved, nothing like "lets see, this is a firewire adapter, and firewire isn't networking only, and 99% of firewire users dont actually use the networking part, not to mention the number of users who get confused when this module is loaded, so lets not load this one today"
> ...

 

Well, that logic is pretty straight forward and does make sense to me.

But, I guess I just don't see it being applied to any other non-networking specific device except firewire.  But, if it has been, since the others generally use non ethx names, I haven't seen anyone confused by extra network interfaces. So maybe the eth1394 interface has just managed to intrude into my daily conciousness by causing confusion.

And I definitely don't recall giving MY approval for this change!    :Laughing: 

troymc

----------

## Gergan Penkov

Well this is fine and dandy, but my problem is with drivers, which are not part of the kernel-tree (madfiwi-ng and ndiswrapper), if such drivers are causing for example kernel-panic (this behaviour begins to resemble a little bit the windows one)?

----------

## dsd

in some ways, parallel is comparable to firewire. it is a multi-function bus (you can connect all kinds of devices to it), and you can use it as a raw networking device with no extra hardware (plip/eth1394).

however, the parallel subsystem is completely non-hotpluggable, mainly because it is not possible to detect which kind of peripheral device is attached. it is also considered legacy. if it wasnt, the plip module would be automatically coldplugged in the same way.

 *Quote:*   

> I've tried looking for the rules for this in the udev rules files, but I don't understand the rules files enough yet.  I can't even identify the rule which is loading the eth1394 module.     

 

i know that it is expected that the hotplug blacklist is not obeyed during coldplugging, but i can't offer an explanation for that at this point. this is my understanding:

rules are mostly for naming devices, setting device permissions, taking actions when devices are created, things like that.

additionally, they control responses to "uevents" (this is the new form of hotplug event). the default ruleset simply invokes the old hotplug agent when this happens:

```
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd $env{SUBSYSTEM}"
```

when a device is attached, the kernel generates a hotplug uevent, which causes that rule to execute the userspace hotplug, which in turn loads the module.

udev coldplugging is simply the process of udev asking the kernel to generate uevents for every connected device. the kernel will do so, which will trigger the above rule to run (as if the device had just been plugged in). hotplug will then do the module loading.

i must either be wrong somewhere, or missing something, because the above implies that the hotplug blacklist would come into effect. if i dont get a chance to look into it beforehand, i'll ask the lead udev developer when i meet with him next month  :Smile: 

----------

## dsd

just noticed the section titled "Autoloading modules" in the udev rules file (thats new). that almost certainly has something to do with it.

----------

## dsd

did a bit of hacking on net-setup to reduce confusion with the network interface names:

http://dev.gentoo.org/~dsd/net-setup-1.gif

http://dev.gentoo.org/~dsd/net-setup-2.gif

will finish that off and hopefully get it included in the next release

----------

## troymc

 *dsd wrote:*   

> did a bit of hacking on net-setup to reduce confusion with the network interface names:
> 
> http://dev.gentoo.org/~dsd/net-setup-1.gif
> 
> http://dev.gentoo.org/~dsd/net-setup-2.gif
> ...

 

Nice!  I think that will help a lot of people with multiple interfaces!    :Very Happy: 

troymc

----------

## I.C.Wiener

Please, provide at least some option in udev.conf or somewhere else to turn this autoloading-shit off.

Since I upgraded udev my network cards get swapped every time I boot. eth0 becames eth1 and twice versa - EVERY TIME!!! No way to adopt!

My soundcards are getting loaded in the wrong order, even though I set things up in /etc/modules.d/alsa like:

```

alias snd-card-0 snd-emu10k1

alias snd-card-1 snd-intel8x0

```

Alsa worked fine and handled the module-loading properly, since udev interfered everthing goes wrong!

I am the User, damnit! I want to decide what modules are being loaded during boot and which are not.

----------

## letzterfreiercoolername

 *I.C.Wiener wrote:*   

> Please, provide at least some option in udev.conf or somewhere else to turn this autoloading-shit off.
> 
> Since I upgraded udev my network cards get swapped every time I boot. eth0 becames eth1 and twice versa - EVERY TIME!!! No way to adopt!
> 
> My soundcards are getting loaded in the wrong order, even though I set things up in /etc/modules.d/alsa like:
> ...

 

Well, I won't swear here, but I'd like to, too!

My networkadapters (NIC, wireless, and that eth1394 thingie) change at every boot, too.

Especially evil is that I have to use vmware (I use gentoo in my daytime job) with a "bridged to primary NIC" network setup.

Guess how hard it is to guess the correct NIC id at next boot, so that I can configure the vmware config files correctly...

So I want to double my preposters demand (in a friendlier way): 

 * either give us a way to exclude certain hardware from being autoloaded in random order

 * or give us a way to provide the loading order in a config file etc. I'd even use kernel command line options, but they only work for compiled-in drivers.

Pleeeeeeaseeeeee!

----------

## letzterfreiercoolername

Ok, I am done now, and it works!

I read http://www.reactivated.net/writing_udev_rules.html , especially section http://www.reactivated.net/writing_udev_rules.html#example-netif ,

then investigated my NICs' hardware/MAC addresses, 

then put

```

# this is my ethernet NIC, recognized by MAC address

KERNEL=="eth*", SYSFS{address}=="00:11:d8:59:d1:f9", NAME="eth0"

# this is TCP over firewire (eth1394)

KERNEL=="eth*", SYSFS{address}=="00:11:d8:00:00:03:5b:e1", NAME="eth1"

# this is my PCI wireless card

KERNEL=="ra*",  SYSFS{address}=="00:11:d8:58:8e:db", NAME="ra0"

```

into /etc/udev/rules.d/10-local.rules

Then I removed any ethX related "alias ethX drivername" mapping from /etc/modules.d/aliases and ran modules-update.

I tried for 5 completely coldstarts now, no flipping ethX names anymore!

Yeehaa!

CAUTION: _Your_ device IDs will be different, these above are altered examples!

What basically happens here, is that if a device named eth? is loaded and it fits a MAC address, I assign a fixed name to it.

@I.C.Wiener: you could do the same to your NICs and sth similar to your sound cards: I'd try to either use the pci bus address or the driver name (you have different cards, don't you?) instead of a MAC address.

Time needed for this 2h 35min. I should have done earlier. If only Daniel Drake (dsd) had not put the solution to my problems in one of the last paragraphs of his wonderful documentation ...  :Wink: 

----------

## Polynomial-C

Hi,

alright I was also hit by this fscking bug (yes, I call this a big, fat bug in udev).

It seems as all this trouble is caused by udevtrigger. If you let udev get started with udevstart, no unnecessary module is loaded at boottime.

Of course you have to alter the startscript of udev which is located in /lib/rcscripts/addons/udev-start.sh

```
--- /usr/portage/sys-fs/udev/files/udev-start-096.sh    2006-07-15 19:16:52.000000000 +0200

+++ /usr/local/portage/sys-fs/udev/files/udev-start-096.sh      2006-07-18 15:26:49.000000000 +0200

@@ -17,18 +17,18 @@

 populate_udev() {

        # populate /dev with devices already found by the kernel

-       if [ $(get_KV) -gt "$(KV_to_int '2.6.14')" ] ; then

-               ebegin "Populating /dev with existing devices through uevents"

-               local opts=

-               [[ ${RC_COLDPLUG} != "yes" && $(udev_version) -ge "96" ]] && \

-                       opts="--no-scan-bus"

-               /sbin/udevtrigger ${opts}

-               eend $?

-       else

+#      if [ $(get_KV) -gt "$(KV_to_int '2.6.14')" ] ; then

+#              ebegin "Populating /dev with existing devices through uevents"

+#              local opts=

+#              [[ ${RC_COLDPLUG} != "yes" && $(udev_version) -ge "96" ]] && \

+#                      opts="--no-scan-bus"

+#              /sbin/udevtrigger ${opts}

+#              eend $?

+#      else

                ebegin "Populating /dev with existing devices with udevstart"

                /sbin/udevstart

                eend $?

-       fi

+#      fi

        # loop until everything is finished

        # there's gotta be a better way...
```

I can only hope that the udev-devs will work on a way to stop this nasty behaviour in a smarter way than I did (above all, udevstart is seen as deprecated and will unfortunately be removed in a future version of udev).

Cheers

Poly-C

----------

## Philantrop

 *Polynomial-C wrote:*   

> alright I was also hit by this fscking bug (yes, I call this a big, fat bug in udev).

 

Looks more like a bug in Gentoo, IMHO. However udev is started, it shouldn't autoload any modules. That's not its job.

----------

## __jata__

 *Polynomial-C wrote:*   

> Hi,
> 
> alright I was also hit by this fscking bug (yes, I call this a big, fat bug in udev).
> 
> 

 

And it seems, I am in as well. I have Apacer 12in1 card reader and PVR-350 card in my box. Now very funny situation is happening:

udev initialize usb subsystem and the appropriate modules are loaded and, more-less in the same time ivtv driver is loaded as well. It seems, the initializing routines are in collision, so if ivtv is activated first, everything works. If my card reader is found earlier, the initialisation of ivtv is messed up and my system freezes totally with message 'ivtv0 warning: Decoder firmware dead!". At that moment there is only one help: hard reset of computer. At the moment I have to start computer approximately 10 times to reach useable system! Once booted, all works well without any problems. In the past I was able to choose the modules loading order and, based on experience, I never had such screwed PC if ivtv was initialized first.

Very nice, I like it   :Evil or Very Mad: 

----------

## Polynomial-C

Okay,

in this comment was said that this (mis)behaviour could be switched off by setting 

```
RC_COLDPLUG="no"
```

 in /etc/conf.d/rc. On my two ~x86 machines with udev-096-r1 this works but there are reports that this doesn't work as well (maybe because >=udev-096 is needed for that as udevtrigger has to be called with --no-scan-bus option which was introduced in gentoo's udev-096 first). Also the module-blacklisting mentioned in that comment doesn't work either.

So before you alter the udev-startscript you maybe update to >=udev-096-r1 (don't use =udev-096 as it has errors concerning the paths of some helper-apps) and try that RC_COLDPLUG="no" first.

[edit]>=udev-099 is using a new syntax for udevtrigger which replaces --no-scan-bus option: udevtrigger --attr-match=dev[/edit]

Cheers

Poly-C

----------

## __jata__

 *Polynomial-C wrote:*   

> Okay,
> 
> in this comment was said that this (mis)behaviour could be switched off by setting 
> 
> ```
> ...

 

Okay, and I am the one, RC_COLDPLUG does not work for... I tried before I sent the post. Analogically, blacklisting of ivtv module does not work as well. My udev IS 0.96-r1.

So far, there is only one reliable way: the comment-out the appropriate lines in udev-start.sh, as you wrote above.

----------

## Philantrop

No, __jata__, you're not alone. I've tried both RC_HOTPLUG and RC_COLDPLUG before I even knew about this thread and that bug. I will try it again soon as the might have been a baselayout update since I last tried but abusing udev like it is currently done is annoying.

----------

## Philantrop

 *Polynomial-C wrote:*   

> this (mis)behaviour could be switched off by setting 
> 
> ```
> RC_COLDPLUG="no"
> ```
> ...

 

Okay, for me RC_COLDPLUG="no" works now - sort of. Now udev doesn't load any modules anymore but it doesn't create the device nodes either which is even worse because the kernel can't autoload the modules anymore when I try to access them.

Blacklisting doesn't work for me either.

I just want udev to create the device nodes and leave the rest to me. Shouldn't be that hard, should it?

----------

## __jata__

 *Philantrop wrote:*   

> Blacklisting doesn't work for me either.

 

And THIS seems to me to be crucial point: if blacklisting was working, we would have always a chance to blacklist modules with some specialty (special parameters, special order of loading e.t.c). And the rest of modules could be even loaded automatically (or automagically?), because there is low risk of confusion. And, of course, the mechanism of loading should respect 'static' assignments, i.e. if eth0 is certain NIC with certain module, connected somewhere and eth1 is another NIC, they should be initialized in this order to fullfil expected functionality. The same is about sound cards e.t.c. It is really bad, when every restart of the system means, you have to seek carefully, if the physically the same hardware is (logically) stll the same for OS (and regularly modify your settings accordingly to the result of udev actions).

----------

## Gergan Penkov

how are you guys blacklisting? as it should work no matter what for kernel or udev, or baselayout you are having.

----------

## Philantrop

/etc/hotplug/blacklist

 *Quote:*   

> # Syntax:  driver name alone (without any spaces) on a line. Other
> 
> # lines are ignored.
> 
> 

 

Exactly like that.

----------

## Gergan Penkov

 *Gergan Penkov wrote:*   

> This has nothing to do with udev, at least in my case (or it is even more complicated), somehow earlier kernels, do not load the modules in this way.
> 
> Writing some udev rule did not help in my case, as the modules are loaded before udev kicks in, so it does not create the devices with these rules but the modules are loaded, or at least this was after a short debugging, what really helped now, is this file:
> 
> ```
> ...

 

and this works for me

----------

## Philantrop

 *Quote:*   

> cat /etc/modules.d/blacklist
> 
> blacklist bttv
> 
> blacklist video_buf
> ...

 

 *Quote:*   

> SUBSYSTEM=="module",    DRIVER=="bttv", OPTIONS="ignore_device,last_rule"

 

```
modules-update

```

 *Quote:*   

>  * Updating /etc/modules.conf ...                                                                               [ ok ]
> 
>  * Updating /etc/modprobe.conf ...
> 
>  * Warning: could not generate /etc/modprobe.conf!                                                              [ !! ]
> ...

 

```
rmmod tuner tvaudio  bttv video_buf firmware_class compat_ioctl32  v4l2_common btcx_risc  ir_common tveeprom videodev

killall udevd

ls -l /dev/v4l*
```

 *Quote:*   

> ls: /dev/v4l*: No such file or directory
> 
> 

 

```
udevd &

udevtrigger

lsmod | grep -i "bttv"

```

 *Quote:*   

> bttv                  172148  0
> 
> video_buf              22148  1 bttv
> 
> firmware_class         10560  1 bttv
> ...

 

----------

## Gergan Penkov

hm well it seems it is not an universal solution, although it works very well for me.

look if /etc/modules.conf & /etc/modprobe.conf get regenerated at all or if it has the blacklist entries.

[EDIT]Probably it works for me because the ndiswrapper "takes" the device a little bit later on, I should try also to blacklist the ndiswrapper moduke and see if anything gets loaded - probably this is the problem[/EDIT]

----------

## Philantrop

Yes, mod*.conf get updated but it doesn't work anyway.

I'm curious to hear about your ndiswrapper test. :-)

----------

## Gergan Penkov

well it does not work, I assume that I'm just lucky to have found some sort of solution  :Smile: 

It loads ndiswrapper even after blacklisting it, but I'm not sure when, I haven't had the time to debug it and didn't want to stop all the services, which depend on net.wlan0 so it could be that net.wlan0 is forcing the module loading.

At least the madwifi-drivers don't get loaded for me as was the case before the blacklisting - but I still don't see what have made them change the behaviour in this rather controversial way.

----------

## t0mcat

are there any updates on this?

actually the only way to prefer ndiswrapper module to the kernel one (bcm43xx, wich i need to use kismet, but it's quite slower than ndiswrapper driver) was to downgrade udev to the stable ebuild...

i just wanted a blacklist function... turning totaly off module-autoloading isn't viable imho.

----------

## Gergan Penkov

Well, I gave up on this one, after some upgrade nothing was able to prevent the loading of the madwifi-drivers and I had to unload them (there are 6-7 modules) and load ndiswrapper per hand. So I ended searching for solution and found snapshot drivers not in portage for madwifi, which at the end worked for me. So now I'm using madwifi-ng with a custom build  :Smile: 

----------

## theomega

Is there realy no solution for this problem? I realy dont want my wireless-lan-modules to be loaded all the time. So please(!) tell me how to fix this?

----------

## Philantrop

See this bug:

https://bugs.gentoo.org/show_bug.cgi?id=130766

It doesn't seem to be a problem considering for how long it's been open... Sensible module auto-loading with Gentoo? Hardly possible.

----------

## Element Dave

 *dsd wrote:*   

>  *troymc wrote:*   The udev team seems to be conflating dynamic device node creation and module loading in a way that is short-circuiting this behaviour. 
> 
> seems a little odd to bring this up now, given that its been happening for years, and its not related to coldplugging. but yes, this is how udev does things.
> 
>  *Quote:*   I've had floppy.o built as a module for almost 10 years now, and the only time it is ever loaded is when I've mounted a floppy. Now, if I have the module built, it has to be loaded at boot? or I have to go back to loading it manually, and creating the device node manually?  
> ...

 

This attitude is completely idiotic.  Why on earth would anyone assume that one would want to use a device simply because it is attached to the system?  Only a subset of devices present are ever used on most systems.  There are many reasons for not wanting certain device drivers and/or other modules loaded all of the time: preventing resource conflicts is certainly one.  How does one even know which modules are going to be automagically loaded, and when?

It's quite a mess when users are creating module blacklists in multiple directories (which probably aren't even parsed) and swapping trade secrets in forums ('psst: set RC_COLDPLUG="no"') in an attempt to override the default module loading behavior.  If only people would prepare documentation before even coding the software.

----------

## alexiadeath

 :Shocked:  This sucks. So there is no currently working  blacklist for the UDEV autoloader?

This damn thing is loading evbug module thats a debugging module for Christs sake that craps my messages log full of noise on boot!  :Rolling Eyes:  this is torture. Really! Anybody has a clue what could be done about that?

----------

## depontius

 *alexiadeath wrote:*   

>  This sucks. So there is no currently working  blacklist for the UDEV autoloader?
> 
> This damn thing is loading evbug module thats a debugging module for Christs sake that craps my messages log full of noise on boot!  this is torture. Really! Anybody has a clue what could be done about that?

 

Darn! I was just looking into the evbug thing again, and got to this thread, searching for "prevent module load". I even looked in /etc/hotplug/blacklist, and found evbug in there. By the way, "rmmod evbug" makes the chatter stop, as you would expect. I hadn't bothered with it too much because when the logs rotate, the chatter should be highly compressible and not take up too much space. Incidentally, I don't remember selecting it on my kernel build... I think someone clicked it on by default.

But it makes looking for anything in /var/log/messages a real pain in the neck.

So I've just added "/sbin/rmmod evbug" to "/etc/conf.d/local.start". An ugly hack, and there may be a little chatter before it's executed, but better than nothing. I know deselecting it in the kernel build is the right way to go, and next time I need to build a kernel, I will.

----------

## BitJam

I found this page to be extremely helpful for understanding how the udev coldplug works:

https://wiki.archlinux.org/index.php/ModaliasPrimer

It might not directly address the problems people are trying to solve here but it sure helped me understand what the heck is going on.  One possible work-around would be to write your own udev coldplug that specifically allows for a blacklist.  I haven't tested it but something like this might work:

```
list_cold_plug_modules() {

    for alias in $(find /sys/devices -name modalias | xargs cat); do

        modprobe -R $alias

    done

}

for module in $(list_cold_plug_modules | sort -u); do

    case ",$BLACK_LIST," in

        ,$module,) ;;

        *) modprobe $module;;

    esac

done
```

Edit: Removed "echo" that disabled the final modprobe command.

----------

