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 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... :-)
(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 on attachment 95346 [details, diff] module-init-tools-3.2.2-blacklist.patch 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.
