Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

hi. recently (udev-089) udev has started to autoload lots of modules (called
coldplug or whatever), and it's not possible (as of today) to disable this
functionality. so, i had to blacklist (add to /etc/hotplug/blacklist) modules i
don't want at boot time (i.e., ipw2200, eth1394 etc.). it worked fine. after i
upgraded to udev-090, baselayout-1.12.0_pre17-r3, it stopped working. udev now
once again loads ipw2200, eth1394, even when they are blacklisted. upgrading to
hotplug-20040923-r2 didn't help.

I've also noticed that my ipw2100 driver is loaded even though mentioned in
/etc/hotplug/blacklist.  This previously had worked under udev-089.

Ah, now I know why.

Stop using the hotplug blacklist, that has nothing to do with the module
loading anymore, udev
is doing it for you.  Everyone needs to add the blacklist to the modules.conf
file "blacklist module_name"

If you do that, it should work just fine.

This is a frequently encountered problem after upgrading udev. Can we document
this, please? Something like:

<snip>
if has_version '<sys-fs/udev-089' ; then
               ewarn "udev now provides its own coldplug functionality."
               ewarn "If this behaviour is undesired for you, you can"
               ewarn "blacklist the unwanted modules. To blacklist a module,
run:"
               ewarn
               ewarn "    echo \"blacklist module_name\" >>
/etc/modules.d/blacklist"
               ewarn "    modules-update"
               ewarn
</snip>

Also - adding the modules directly into modules.conf is not useful, the changes
will be overwritten next time a user runs modules-update.

after adding "blacklist ipw2200" and other modules to /etc/modules.d/blacklist,
modules-update fails to generate /etc/modprobe.conf. manually running
generate-modprobe.conf shows the problem:
/etc# generate-modprobe.conf 
modprobe: Invalid line 89 in /etc/modules.conf
        blacklist
modprobe: Invalid line 90 in /etc/modules.conf
        blacklist
modprobe: Invalid line 91 in /etc/modules.conf
        blacklist
modprobe: Invalid line 92 in /etc/modules.conf
        blacklist
modprobe: Invalid line 93 in /etc/modules.conf
        blacklist
modprobe: Invalid line 94 in /etc/modules.conf
        blacklist
modprobe: Invalid line 95 in /etc/modules.conf
        blacklist
modprobe: Invalid line 96 in /etc/modules.conf
        blacklist
modprobe: Invalid line 97 in /etc/modules.conf
        blacklist
Failed to to run modprobe. Giving up.
I have module-init-tools-3.2.2.
Btw, what does /etc/hotplug/blacklist do now? Stop module from loading when,
for example, a USB device is inserted (hotplugged)?

(In reply to comment #4)
Yeah, it indeed fails. So, there's no working way to blacklist modules in 090
:( 

> Btw, what does /etc/hotplug/blacklist do now? Stop module from loading when,
> for example, a USB device is inserted (hotplugged)?

Was about to ask the same...

i'm not really interested in black listing individual modules ... i'd prefer to
blacklist everything ... in other words, turn this "feature" off

actually, me too... possibility to do both would be good to cater for
everyone's needs

The module blacklist is the mechanism to prevent modules from being loaded
by udev at startup time.  See Bug #119989 for more talk about this.

Ok, wait, I played around with this some more today, and it's very far
from intuitive.  hotplug and udev are not playing nice here, and the
module.conf
build scripts can't handle blacklisting properly.

So I'll take this and get it working much better, sorry for the noise.

all mine...

*** Bug 131830 has been marked as a duplicate of this bug. ***

Well, it appears the modules-update script is now working a little better
(althought it says it can't make it automatically and that it's then going to
make it by hand, which is a little bit of a weird thing for a script to say)...

post the output of `modules-update -v` and `modules-update -d` as attachments

Ok, 'modules-update -v' gives:

plasma / # modules-update -v
 * Updating /etc/modules.conf ...                                         [ ok
]
 * Updating /etc/modprobe.conf ...
modprobe: Invalid line 120 in /etc/modules.conf
        blacklist
 * Warning: could not generate /etc/modprobe.conf!                        [ !!
]
 * Updating /etc/modprobe.conf by hand ...                                [ ok
]
 * Updating modules.dep ...                                               [ ok
]

modules-update -d gives:

plasma / # modules-update -d
+ false
+ [[ -d /etc/devfs.d ]]
+ type -p modprobe.old
+ GENERATE_OLD=true
++ uname -r
+ KV=2.6.16-gentoo-r5
++ KV_to_int 2.6.16-gentoo-r5
++ [[ -z 2.6.16-gentoo-r5 ]]
+++ KV_major 2.6.16-gentoo-r5
+++ [[ -z 2.6.16-gentoo-r5 ]]
+++ local KV=2.6.16-gentoo-r5
+++ echo 2
++ local KV_MAJOR=2
+++ KV_minor 2.6.16-gentoo-r5
+++ [[ -z 2.6.16-gentoo-r5 ]]
+++ local KV=2.6.16-gentoo-r5
+++ KV=6.16-gentoo-r5
+++ echo 6
++ local KV_MINOR=6
+++ KV_micro 2.6.16-gentoo-r5
+++ [[ -z 2.6.16-gentoo-r5 ]]
+++ local KV=2.6.16-gentoo-r5
+++ KV=16-gentoo-r5
+++ echo 16
++ local KV_MICRO=16
++ local KV_int=132624
++ [[ 132624 -ge 131584 ]]
++ echo 132624
++ return 0
++ KV_to_int 2.5.48
++ [[ -z 2.5.48 ]]
+++ KV_major 2.5.48
+++ [[ -z 2.5.48 ]]
+++ local KV=2.5.48
+++ echo 2
++ local KV_MAJOR=2
+++ KV_minor 2.5.48
+++ [[ -z 2.5.48 ]]
+++ local KV=2.5.48
+++ KV=5.48
+++ echo 5
++ local KV_MINOR=5
+++ KV_micro 2.5.48
+++ [[ -z 2.5.48 ]]
+++ local KV=2.5.48
+++ KV=48
+++ echo 48
++ local KV_MICRO=48
++ local KV_int=132400
++ [[ 132400 -ge 131584 ]]
++ echo 132400
++ return 0
+ [[ 132624 -ge 132400 ]]
+ KERNEL_2_6=true
+ export LC_ALL=C
+ LC_ALL=C
+ CFGFILES=
+ true
+ CFGFILES=' /etc/modules.conf'
+ false
+ true
+ CFGFILES=' /etc/modules.conf /etc/modprobe.conf'
+ false
+ for x in '${CFGFILES}'
+ [[ -r /etc/modules.conf ]]
++ sed -ne 1p /etc/modules.conf
+ [[ ### This file is automatically generated by modules-update != \#\#\#\
\T\h\ i\s\ \f\i\l\e\ \i\s\ \a\u\t\o\m\a\t\i\c\a\l\l\y\ \g\e\n\e\r\a\t\e\d\
\b\y\ \m\o\ d\u\l\e\s\-\u\p\d\a\t\e ]]
+ for x in '${CFGFILES}'
+ [[ -r /etc/modprobe.conf ]]
++ sed -ne 1p /etc/modprobe.conf
+ [[ ### This file is automatically generated by modules-update != \#\#\#\
\T\h\ i\s\ \f\i\l\e\ \i\s\ \a\u\t\o\m\a\t\i\c\a\l\l\y\ \g\e\n\e\r\a\t\e\d\
\b\y\ \m\o\ d\u\l\e\s\-\u\p\d\a\t\e ]]
+ [[ ! -d /etc/modules.d ]]
+ true
+ false
+ [[ ! -e /etc/modules.conf ]]
+ is_older_than /etc/modules.conf /etc/modules.d
+ local x=
+ local ref=/etc/modules.conf
+ shift
+ for x in '"$@"'
+ [[ -d /etc/modules.d ]]
+ is_older_than /etc/modules.conf /etc/modules.d/aliases /etc/modules.d/alsa
/et c/modules.d/ath_pci /etc/modules.d/blacklist /etc/modules.d/i386
/etc/modules.d/ ppp
+ local x=
+ local ref=/etc/modules.conf
+ shift
+ for x in '"$@"'
+ [[ -d /etc/modules.d/aliases ]]
+ [[ /etc/modules.d/aliases -nt /etc/modules.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/alsa ]]
+ [[ /etc/modules.d/alsa -nt /etc/modules.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/ath_pci ]]
+ [[ /etc/modules.d/ath_pci -nt /etc/modules.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/blacklist ]]
+ [[ /etc/modules.d/blacklist -nt /etc/modules.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/i386 ]]
+ [[ /etc/modules.d/i386 -nt /etc/modules.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/ppp ]]
+ [[ /etc/modules.d/ppp -nt /etc/modules.conf ]]
+ return 1
+ return 1
+ vewarn 'Skipping /etc/modules.conf generation (file is newer than
dependencies )'
+ [[ 0 -gt 0 ]]
+ return 0
+ true
+ type -p generate-modprobe.conf
+ false
+ [[ ! -e /etc/modprobe.conf ]]
+ is_older_than /etc/modprobe.conf /etc/modules.d /etc/modprobe.d
+ local x=
+ local ref=/etc/modprobe.conf
+ shift
+ for x in '"$@"'
+ [[ -d /etc/modules.d ]]
+ is_older_than /etc/modprobe.conf /etc/modules.d/aliases /etc/modules.d/alsa
/e tc/modules.d/ath_pci /etc/modules.d/blacklist /etc/modules.d/i386
/etc/modules.d /ppp
+ local x=
+ local ref=/etc/modprobe.conf
+ shift
+ for x in '"$@"'
+ [[ -d /etc/modules.d/aliases ]]
+ [[ /etc/modules.d/aliases -nt /etc/modprobe.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/alsa ]]
+ [[ /etc/modules.d/alsa -nt /etc/modprobe.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/ath_pci ]]
+ [[ /etc/modules.d/ath_pci -nt /etc/modprobe.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/blacklist ]]
+ [[ /etc/modules.d/blacklist -nt /etc/modprobe.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/i386 ]]
+ [[ /etc/modules.d/i386 -nt /etc/modprobe.conf ]]
+ for x in '"$@"'
+ [[ -d /etc/modules.d/ppp ]]
+ [[ /etc/modules.d/ppp -nt /etc/modprobe.conf ]]
+ return 1
+ for x in '"$@"'
+ [[ -d /etc/modprobe.d ]]
+ [[ /etc/modprobe.d -nt /etc/modprobe.conf ]]
+ return 1
+ vewarn 'Skipping /etc/modprobe.conf generation (file is newer than
dependencie s)'
+ [[ 0 -gt 0 ]]
+ return 0
++ grab_depfile
++ local ret=
++ [[ -e /etc/modules.conf ]]
+++ sed -n -e '/^[[:space:]]*depfile=/s:.*=::p' /etc/modules.conf
++ ret=
++ [[ -z '' ]]
++ ret=/lib/modules/2.6.16-gentoo-r5/modules.dep
++ eval echo /lib/modules/2.6.16-gentoo-r5/modules.dep
+++ echo /lib/modules/2.6.16-gentoo-r5/modules.dep
+ depfile=/lib/modules/2.6.16-gentoo-r5/modules.dep
+ [[ -d /lib/modules/2.6.16-gentoo-r5 ]]
+ [[ /etc/modprobe.conf -nt /lib/modules/2.6.16-gentoo-r5/modules.dep ]]
+ exit 0

which part of "as attachments" didnt you understand :P

anyways, this is still a bug in udev/hotplug/whatever ... by your description i
thought it might be an issue in modules-update, but i was mistaken

I think coldplugging by udev is a feature many users would want. I for once
would not want it disabled, because it can avoid a lot of headache. A switch
would be nice, of course, but I'd leave it on by default.

On the other hand, autoloading every module that fits is a real problem.
Bug 131830 duped here in comment 11 has severe security implications, and
should therefore be fixed really soon.

I suggest to copy the contents of /etc/hotplug/blacklist (currently part of
sys-apps/hotplug) to /etc/modules.d/blacklist, adding the blacklist keyword.
You should also look for ebuilds that install files to
/etc/hotplug/blacklist.d, like net-dialup/capi4k-utils and net-dialup/slmodem,
and create corresponding modules.d entries for them as well.

Alternatively you could modify modules-update to take /etc/hotplug/blacklist
and /etc/hotplug/blacklist.d into account as well. That way people could keep
configuring things the way they used to so far. On the other hand, it obscures
the internal workings of hotplug configuration, and people might easily forget
to run modules-update.

(In reply to comment #16)
> I think coldplugging by udev is a feature many users would want. I for once
> would not want it disabled, because it can avoid a lot of headache. A switch
> would be nice, of course, but I'd leave it on by default.

Absolutely not.  My network devices should never come up before my firewall
rules are in place, as an example.

I don't have a problem with the rest of the stuff, but having devices
coldplugged so early really does cause a few issues for Release Engineering.  I
plan on actually filing some bugs for some of this stuff (including patches,
yay!) so it works fine for us.  Luckily, we are still on a version of udev in
stable that exhibits the old behavior, since we're going to have to rewrite how
most of the LiveCD hardware detection is done due to this new functionality.

(In reply to comment #17)
> Absolutely not.  My network devices should never come up before my firewall
> rules are in place, as an example.

I would think that loading a module for a network interface does not
automatically bring that interface up. It is my understanding that you would
still need to "ifconfig up" the thing, and could install your firewall before.
Maybe it would really be nice to move all this coldplugging to runlevel default
or some such, but that might cause nasty dependency issues if you want to use
any coldplugged stuff in boot, and I still don't see the point. Am I off topic?

Well, via the older coldplug init script (before dev did it on its own) it was
recommended to go into "default" anyway.  If you knew you needed something
before then, you added it to /etc/modules.autoload.d/kernel-2.* instead.

The real issue here is that a decision needs to be made one way or another, and
the sooner we know, the better, so we can start reworking all of the LiveCD
tools to work with it.  The biggest issue we have is that we allow for
disabling coldplug functionality from the CD's kernel command line, for extreme
cases where hardware detection caused lockups.  With this being done so early
in the init, it is much harder for us to accomplish it (but not impossible), we
just need to know what we need to do.

This issue here is back on my system, including evbug.
Seems like modules-update silently drops the blacklist entries.
Don't know when this started, but right now I have module-init-tools 3.2.2-r1

As far as I'm aware, as of udev-094 or 096, and the latest copy of baselayout,
you can now stop the automatic loading of modules using the RC_COLDPLUG="no"
line in /etc/conf.d/rc.  There's then a separate variable RC_PLUG_SERVICES that
lets you specify which services should be started automatically during boot
when the devices are detected.

As such Blacklist items in the modules.d directories are no longer necessary
and will not work.  Hope this helps...  5:)

In fact, this bug could probably do with being closed, thinking about it... 
Perhaps when the relevant baselayout and udev versions hit stable?

(In reply to comment #21)
> As far as I'm aware, as of udev-094 or 096, and the latest copy of baselayout,
> you can now stop the automatic loading of modules using the RC_COLDPLUG="no"
> line in /etc/conf.d/rc.  There's then a separate variable RC_PLUG_SERVICES
> that lets you specify which services should be started automatically during
> boot when the devices are detected.

From what I read from the comments, RC_PLUG_SERVICES only has an effect during
bootup if you also have RC_COLDPLUG=yes. And as the name indicates, it's about
services, not modules. The problem for me (according to bug subject) is that
some modules get loaded that should not, so this var is of no use to me. It
might help address the network device example given in comment 17, though.

Generally I'd like to have modules being autoloaded, but there are some
exceptions where I would want a module only if I load it explicitly. Those are
the modules listed in /etc/hotplug/blacklist, especially evbug and eth1394.
For what I want, some kind of module autoloading blacklist is exactly the thing
I need, and right now I can see no way to do this with current versions.

> As such Blacklist items in the modules.d directories are no longer necessary
> and will not work.  Hope this helps...  5:)

I can't see why they would no longer be necessary? First, if they are still
supported by module-init-tools, then please let's have them, to give the
administrator every freedom. I think that's the Gentoo way, isn't it?
If they aren't supported any longer, I'd consider it an upstream regression.

Second, I'd worry about people with default setup automatically opening a
security hole just because they configured the evbug module in kernel. OK,
maybe the device alias built into that module should be considered a kernel bug
in the first place, but right now people would dump a huge amount of input
events just because of this.

No, we need to honor the module blacklisting logic.  It's a upstream thing,
and we would be diverging from all other distros if we take that code out.

I don't know what happened to it, but it wasn't a udev issue, but a modutils
issue.  Anyone know if something happened to upstream to cause this to occur?

As explained in Bug 131378, blacklist entries belong to /etc/modprobe.d/ -
however, it doesn't do anything useful. A quick test:

# echo "blacklist pcspkr" > /etc/modprobe.d/blacklist
# modules-update 
 * Updating /etc/modprobe.conf ...                                             
                                                          [ ok ]
 * Updating modules.dep ...                                                    
                                                          [ ok ]
# grep pcspkr /etc/modprobe.conf
#
# grep pcspkr /etc/modules.conf
#

Hmmm?

It works for me here:

# cat /etc/modules.d/blacklist 
blacklist ohci1394
blacklist shpchp
blacklist snd_intel8x0
# echo "blacklist pcspkr" >> /etc/modules.d/blacklist
quad greg # modules-update
 * Updating /etc/modules.conf ...                                         [ ok
]
 * Updating /etc/modprobe.conf ...
 * Warning: could not generate /etc/modprobe.conf!                        [ !!
]
 * Updating /etc/modprobe.conf by hand ...                                [ ok
]
 * Updating modules.dep ...                                               [ ok
]

# grep black /etc/modprobe.conf
# grep black /etc/modules.conf 
### modules-update: start processing /etc/modules.d/blacklist
blacklist ohci1394
blacklist shpchp
blacklist snd_intel8x0
blacklist pcspkr
### modules-update: end processing /etc/modules.d/blacklist


But something is not using the modules.conf file anymore :(

(In reply to comment #24)
> I don't know what happened to it, but it wasn't a udev issue, but a modutils
> issue.  Anyone know if something happened to upstream to cause this to occur?

modules-update belongs to baselayout, not module-init-tools, and certainly not
modutils. generate-modprobe.conf on the other hand belongs to
module-init-tools, but according to the sources this has not changed between
3.1 and 3.2.2. I still have to debug this combination to see where things get
lost. Anyone knows for which versions the blacklist keyword did work? Because I
know it did work once, when I wrote comment 16.

(In reply to comment #26)
> But something is not using the modules.conf file anymore :(

It is my understanding that the modules.conf file is only for modutils and 2.4
kernels, while 2.6 kernels use modprobe.conf and module-init-tools. Which
kernel are you using?

Udev blacklisting worked for udev-090, I think it may've stopped working around
udev-094 but don't quote me on that...  5:)

(In reply to comment #26)
> It works for me here:
> 
> # cat /etc/modules.d/blacklist 
> blacklist ohci1394
> blacklist shpchp
> blacklist snd_intel8x0
> # echo "blacklist pcspkr" >> /etc/modules.d/blacklist

Yeah, but it doesn't belong there, it belongs to /etc/modprobe.d - otherwise
you'll get the error:

> Warning: could not generate /etc/modprobe.conf! 

And, it's completely ignored when you put it into /etc/modprobe.d *confused*

(In reply to comment #27)
> modutils. generate-modprobe.conf on the other hand belongs to
> module-init-tools, but according to the sources this has not changed between
> 3.1 and 3.2.2. I still have to debug this combination to see where things get
> lost. Anyone knows for which versions the blacklist keyword did work? Because I
> know it did work once, when I wrote comment 16.

Doesn't work w/ module-init-tools-3.2.2-r1.

> It is my understanding that the modules.conf file is only for modutils and 2.4
> kernels, while 2.6 kernels use modprobe.conf and module-init-tools. Which
> kernel are you using?

I guess pretty much irrelevant when falking about udev. It doesn't work w/ 2.4
kernels.

I think it does belong to /etc/modules.d (that's where it had worked for me),
but yeah, it did always tell us that modprobe.conf was broken (it still managed
to generate it "manually" though, whatever that means...).

The problem seems to be it's incredibly unclear *what's* operating on that
file.  It used to be only udev that read it, but now it appears udev doesn't. 
So what does, and what should?  If RC_COLDPLUG="yes", should udev then be
reading the file?  Once udev is reading the file, all we need to do is fix
modules-update not to collapse on blacklist entries...

Created an attachment (id=95346) [details]
module-init-tools-3.2.2-blacklist.patch

(In reply to comment #27)
> I still have to debug this combination to see where things get lost.

OK, I disabled the removing of the error files and got a lot of messages like
this: "Warning: not translating blacklist evbug" which is a message from
generate-modprobe.conf, stating it simply does not handle this keyword. I guess
that needs to be changed, and the attached patch does. I still have to reboot
to test it, though. See you back after the reboot... :-)

(In reply to comment #32)
> See you back after the reboot... :-)

OK, I rebooted and evbug did not get loaded, so I'm happy this works.
I guess this should be included into an module-init-tools revision bump.
I will write an email to pass this patch upstream as well.

(From update of attachment 95346 [details])
no, read the bug report jakub referenced

Ah cool, that makes a *lot* more sense, sorry for doubting you Jakub!  5:(

Now if only something could make a modprobe.d directory, it'd be a fair bit
clearer.  Still I guess once you know...  5:)

You don't need to reboot to test this.

Just do a 'modprobe ALIAS'
where ALIAS is the output of the 'modalias' file for the sysfs entry of the
device
that the module would normally bind to.

So, for evdev, find any input device, and use its file:
   modprobe `cat /sys/class/input/input0/modalias`


And I'm confused, the proposed patch doesn't work?

And this isn't a udev issue, nothing that udev has done should have changed
this behavior, it is just calling 'modprobe' with the alias, that has been
present for quite some time.

Can anybody pls tell me what's the latest status on this?

(In reply to comment #37)
> Can anybody pls tell me what's the latest status on this?
> 

* udev (103) will not coldplug-load modules specified as "blacklist foo" in
/etc/modprobe.conf (fine)
* /etc/hotplug/blacklist is now ignored (fine, but I didn't see any einfo about
this when merging udev-103 when it got stable)
* trying to put "blacklist foo" in /etc/modules.conf (through /etc/modules.d)
will result in warning on modules-update and it won't work anyway (fine)
* putting "blacklist foo" in /etc/modprobe.d/ (as suggested) does not get into
modprobe.conf - ignored (see bug 145962 blocking this one) so now you can only
put it in modprobe.conf manually and have it lost on next modules-update...

*** Bug 157824 has been marked as a duplicate of this bug. ***

Hopefully, this should be fixed now:

# echo "blacklist pcspkr" > /etc/modprobe.d/blacklist
# modules-update 
 * Updating /etc/modprobe.conf ...                                             
                                                         [ ok ]
 * Updating modules.dep ...                                                    
                                                         [ ok ]
# grep pcspkr /etc/{modules,modprobe}.conf
/etc/modprobe.conf:blacklist pcspkr

You'll need >=sys-apps/baselayout-1.12.7-r2 and
>=sys-apps/module-init-tools-3.2.2-r2 for this to work...

sys-apps/hotplug installs /etc/hotplug/blacklist which is completely ignored,
causing regression to stuff like Bug 128962. 

Should the file be installed by udev into /etc/modprobe.d w/ appropriate
blacklist syntax now, or by module-init-tools, or... ???

there is no reason at all /etc/hotplug should be tracked by module-init-tools,
or any file like /etc/hotplug/blacklist

(In reply to comment #40)
> Hopefully, this should be fixed now:

While it's fixed in module-init-tools, the thing is plain completely ignored by
udev and it's still loading the pcspkr module. Plus udev maintainer has been
MIA for 2 months as an added bonus.

One other idea is that:
Use something like load-modules.sh from
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/udev/?cvsroot=Current&only_with_tag=CURRENT

They basically have a modprobe-wrapper to respect blacklisting, as the
blacklist keyword found in newer module-init-tools just disables aliases like 
pci:v00008086d00001076sv00008086sd00001176bc02sc00i00.

But if some modalias-sysfs-key returns pcspkr that gets loaded, without
respecting blacklists.

Also udev-rules sometimes calls modprobe, like for sd_mod/sr_mod that cannot be
blacklisted.

Following my last comment, I suggest to create
/etc/modules.blacklist.d/
for storing blacklist entries.

And then either writing a similar modprobe-wrapper to respect blacklisting, or
to write a patch for modprobe to get it a flag.
--respect-blacklist
Approach wrapper is faster, but approach patch is cleaner.

udev-104-r11 (and -r10) implement the wrapper-based blacklisting, by using the
blacklist-lines from modprobe.conf

(In reply to comment #46)
> udev-104-r11 (and -r10) implement the wrapper-based blacklisting, by using the
> blacklist-lines from modprobe.conf

Stable now, closing.