Spent way too long tonight trying to make sense of the /etc/modules.conf, /etc/modules.d/ and /etc/modprobe.conf, /etc/modprobe.d/ interaction with modules-update and generate-modprobe.conf. Here's what I found: For the 2.6 kernel (who give a *** about 2.4 anymore), we need have _either_ a /etc/modprobe.conf file, OR a /etc/modprobe.d/ directory tree. If we have the .conf file, the .d directory is never scanned. Problem is, if you add a file to the modprobe.d/ directory with a "blacklist" line in it, the combination of modules-update and generate-modprobe.conf eats those lines for lunch, never to be seen again. Either we need to add the ability for those scripts to handle the "blacklist" items properly, or just drop the ability for the .d/ directory to be made into a single config file, as that's not needed at all. Oh, and don't get me started with the old module configuration files, I eventually gave up and just deleted them from my system, which helped me figure this all out... So, any thoughts? And do we really need all those aliases anymore?
the problem is legacy ... packages still install into /etc/modules.d and not /etc/modprobe.d so there is no way for the new modprobe to know about these config files unless we combine them via modules-update the problem here i think is that we have generate-modprobe.conf filter everything when in reality it should only be filtering the files for modules.d so the fix is probably to accumulate the old cruft, filter it through generate-modprobe.conf, and then append the new stuff sort of like: cat /etc/modules.d/* > old-cruft TESTING_MODPROBE_CONF=temp generate-modprobe.conf > old-cruft.filtered cat /etc/modprobe.d/* old-cruft.filtered > /etc/modprobe.conf
Two suggestions, independent of each other: 1. let files in modprobe.d override those in modules.d with the same name, so an ebuild that cares can install both and in each situation exactly one (the right one) will be used. I believe this will make life much easier in the future. 2. use modprobe.d directly instead of generating modprobe.conf to reduce the need for using modules-update for each and every change. However first it should be verified that module-init-tools skip files like *~ and pals. This is just an idea, not a strong wish, as I don't particularly care one way or the other. In terms of commands, building from the example in comment 1: rm -f temp for cfg in /etc/modules.d/*; do if [[ ${cfg} == *~ || ${cfg} == *.bak || ${cfg} == *,v ]]; then continue; fi if [[ -e "/etc/modprobe.d/${cfg##*/}" ]]; then continue; fi cat "${cfg}" >> temp done TESTING_MODPROBE_CONF=temp generate-modprobe.conf \ > /etc/modprobe.d/modutils-legacy rm -i /etc/modprobe.conf
(1) already happens i already explained why (2) cannot be [typically] done also, *~ files and such are already ignored as well
*** Bug 148882 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > (1) already happens > > i already explained why (2) cannot be [typically] done > > also, *~ files and such are already ignored as well > 2 works if the corresponding conf file is missing, I've been trying to do this but an /etc/modules.conf file keeps coming back, not sure when. Where are the relevant docs? I just found out that I needed to edit /etc/hotplug/blacklist using Google, but how was I supposed to know this?
(In reply to comment #5) > Where are the > relevant docs? I just found out that I needed to edit /etc/hotplug/blacklist > using Google, but how was I supposed to know this? /etc/hotplug/blacklist won't help anymore now...
fixed with module-init-tools-3.2.2-r2
