Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 130766

Summary: udev-090: module blacklisting stopped working
Product: Gentoo Linux Reporter: Eugene Pavlovsky <heilong>
Component: [OLD] Core systemAssignee: udev maintainers <udev-bugs>
Status: RESOLVED FIXED    
Severity: major CC: base-system, brebs, caster, gengor, heiko, ikelos, jakub, jasmin-genbug, jrmalaq, marco.calviani, Martin.vGagern, mike, philantrop, releng, sven.koehler, ti.liame, tkrah, toni__arnold, troworld, vapier
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 145962    
Bug Blocks: 119989, 126089, 128962, 129047    
Attachments: module-init-tools-3.2.2-blacklist.patch

Description Eugene Pavlovsky 2006-04-21 13:02:26 UTC
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.
Comment 1 Mike Auty (RETIRED) gentoo-dev 2006-04-21 14:13:30 UTC
I've also noticed that my ipw2100 driver is loaded even though mentioned in /etc/hotplug/blacklist.  This previously had worked under udev-089.
Comment 2 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-04-21 22:00:25 UTC
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.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-04-21 23:45:43 UTC
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.
Comment 4 Eugene Pavlovsky 2006-04-22 00:11:07 UTC
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)?
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2006-04-22 00:19:15 UTC
(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...
Comment 6 SpanKY gentoo-dev 2006-04-22 00:35:47 UTC
i'm not really interested in black listing individual modules ... i'd prefer to blacklist everything ... in other words, turn this "feature" off
Comment 7 Eugene Pavlovsky 2006-04-22 03:01:42 UTC
actually, me too... possibility to do both would be good to cater for everyone's needs
Comment 8 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-04-22 15:52:18 UTC
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.
Comment 9 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-04-22 20:59:34 UTC
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.
Comment 10 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-04-22 20:59:47 UTC
all mine...
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2006-04-30 14:35:17 UTC
*** Bug 131830 has been marked as a duplicate of this bug. ***
Comment 12 Mike Auty (RETIRED) gentoo-dev 2006-05-02 14:18:29 UTC
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)...
Comment 13 SpanKY gentoo-dev 2006-05-02 20:20:05 UTC
post the output of `modules-update -v` and `modules-update -d` as attachments
Comment 14 Mike Auty (RETIRED) gentoo-dev 2006-05-03 01:02:56 UTC
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
Comment 15 SpanKY gentoo-dev 2006-05-03 16:21:37 UTC
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
Comment 16 Martin von Gagern 2006-07-07 06:13:21 UTC
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.
Comment 17 Chris Gianelloni (RETIRED) gentoo-dev 2006-07-07 07:08:59 UTC
(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.
Comment 18 Martin von Gagern 2006-07-20 16:32:03 UTC
(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?
Comment 19 Chris Gianelloni (RETIRED) gentoo-dev 2006-07-20 16:51:58 UTC
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.
Comment 20 Martin von Gagern 2006-08-17 06:15:59 UTC
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
Comment 21 Mike Auty (RETIRED) gentoo-dev 2006-08-17 10:40:40 UTC
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:)
Comment 22 Mike Auty (RETIRED) gentoo-dev 2006-08-17 10:41:54 UTC
In fact, this bug could probably do with being closed, thinking about it...  Perhaps when the relevant baselayout and udev versions hit stable?
Comment 23 Martin von Gagern 2006-08-17 11:08:49 UTC
(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.
Comment 24 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-08-28 23:45:13 UTC
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?
Comment 25 Jakub Moc (RETIRED) gentoo-dev 2006-08-29 00:11:36 UTC
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?
Comment 26 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-08-29 00:22:39 UTC
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 :(
Comment 27 Martin von Gagern 2006-08-29 00:32:43 UTC
(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?
Comment 28 Mike Auty (RETIRED) gentoo-dev 2006-08-29 00:38:00 UTC
Udev blacklisting worked for udev-090, I think it may've stopped working around udev-094 but don't quote me on that...  5:)
Comment 29 Jakub Moc (RETIRED) gentoo-dev 2006-08-29 00:38:51 UTC
(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*
Comment 30 Jakub Moc (RETIRED) gentoo-dev 2006-08-29 00:42:01 UTC
(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.
 

Comment 31 Mike Auty (RETIRED) gentoo-dev 2006-08-29 00:45:21 UTC
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...
Comment 32 Martin von Gagern 2006-08-29 00:57:11 UTC
Created attachment 95346 [details, diff]
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... :-)
Comment 33 Martin von Gagern 2006-08-29 01:16:34 UTC
(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.
Comment 34 SpanKY gentoo-dev 2006-08-29 14:36:59 UTC
Comment on attachment 95346 [details, diff]
module-init-tools-3.2.2-blacklist.patch

no, read the bug report jakub referenced
Comment 35 Mike Auty (RETIRED) gentoo-dev 2006-08-29 14:51:59 UTC
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:)
Comment 36 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-08-29 23:36:26 UTC
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.
Comment 37 Eugene Pavlovsky 2006-11-13 02:18:23 UTC
Can anybody pls tell me what's the latest status on this?
Comment 38 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2006-11-28 11:56:34 UTC
(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...
Comment 39 Jakub Moc (RETIRED) gentoo-dev 2006-12-11 13:49:05 UTC
*** Bug 157824 has been marked as a duplicate of this bug. ***
Comment 40 Jakub Moc (RETIRED) gentoo-dev 2006-12-14 04:15:25 UTC
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...
Comment 41 Jakub Moc (RETIRED) gentoo-dev 2006-12-14 05:08:40 UTC
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... ???
Comment 42 SpanKY gentoo-dev 2006-12-15 21:40:35 UTC
there is no reason at all /etc/hotplug should be tracked by module-init-tools, or any file like /etc/hotplug/blacklist
Comment 43 Jakub Moc (RETIRED) gentoo-dev 2007-01-15 10:43:56 UTC
(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.
Comment 44 Matthias Schwarzott gentoo-dev 2007-01-23 15:59:25 UTC
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.
Comment 45 Matthias Schwarzott gentoo-dev 2007-01-23 18:02:06 UTC
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.
Comment 46 Matthias Schwarzott gentoo-dev 2007-02-13 00:16:10 UTC
udev-104-r11 (and -r10) implement the wrapper-based blacklisting, by using the blacklist-lines from modprobe.conf
Comment 47 Jakub Moc (RETIRED) gentoo-dev 2007-02-23 01:19:44 UTC
(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.