[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: preventing that a module is being loaded

mike wrote:
On Mon, 2008-10-27 at 18:04 -0400, Brian Thompson wrote:
Geert Stappers wrote:
Op 20081026 om 19:19 schreef Brian Thompson:
Has anyone had any success with disabling/blacklisting a
kernel module? The Debian docs show the following but
it's not working for me on 2.6.18-6-sparc64... The module
still loads.
It was a long time ago that I succesfull blacklisted a kernel module.

Sometimes two different modules claim support for the same device, usually because two slightly different versions of the device exist, requiring different kernel modules to operate. In such situation udev loads both kernel modules, with unpredictable results. To avoid this problem, you can prevent any module (let's say, tulip) from loading by creating an arbitrarily named file, containing a line

     blacklist tulip
That doc doesn't tell the full path of the "black list file"

Being curious about the full path, I searched on system here available
and found /etc/modprobe.d/blacklist It didn't contain module names I had add myself, so now I'm curious if /etc/modprobe.d/blacklist works for the original poster.

Geert Stappers

The docs refer to an "arbitrarily named file", so I'm assuming any files
located in /etc/modprobe.d get parsed. I tried both creating a new file
containing the blacklist command and adding the blacklist command to
/etc/modprobe.d/blacklist, and in both cases the module still loads.

As Mark suggested in another posting, I think I'm going to try rebuilding
the initrd to avoid the module in question.


Have you tried moving the module from the directory to somewhere else instead of blacklisting per se?
I know that'd be easier than going through the entire blacklisting process.


The module in question is a network driver. I did actually try renaming
the module in /lib/modules/2.6.18-6-sparc64/kernel/drivers/net/tulip
from "dmfe.ko" to "dmfe.ko.orig" but it still loads...  I'm guessing the
copy that's loading is coming from somewhere else (initrd).


Reply to: