modprobe doesn't work; why is modprobe.conf deprecated in slack 12?
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
the problem is: when i open up /etc/modprobe.conf, it tells me that it's deprecated:
# /etc/modprobe.conf (old location for Linux 2.6+ config)
# The use of this config file is deprecated.
# Instead, create files in the /etc/modprobe.d/ directory
# containing modprobe options.
# For more information, see "man modprobe.conf".
so i created /etc/modprobe.d/ipw3945 and added the following lines to it:
as you can see, i changed "modules.d" to "modprobe.d" because i don't have "modules.d" in /etc, but i do have "modprobe.d". it seems like a slackware-12-specific thing; i was hoping other slack users had come across this and could help me with it.
what am i supposed to do about modprobe.conf? do i ignore the message and insert the given text, or do i try to work with /etc/modprobe.d/ipw3945? if so, why won't it work?
(also, do i have to make a modprobe file for the ieee80211 module, or will it load automatically when ipw3945 is modprobed?)
one other question: in /etc/rc.d i have rc.modules for the generic kernel (22.214.171.124-smp), but none for my current kernel (126.96.36.199). during boot, rc.modules-188.8.131.52-smp is called up even though i'm booting to a 184.108.40.206 kernel. why don't i have a rc.modules-220.127.116.11? (and how do you get/make one?)
thanks for any and all help.
Last edited by aquilolumen; 08-20-2007 at 06:12 PM.
my rc.modules doesn't point to a specific kernel, just "$(uname -r)". i'm confused because there are only "rc.modules-18.104.22.168" and "rc.modules-22.214.171.124-smp" in /etc/rc.d. i think this is the reason why some sound modules are not working, and i was wondering if there was a way to get it to load the appropriate rc.modules for the right kernel version during boot.
yes, i mentioned having slack 12 in the first line.
As far as I am aware when the ipw3945 driver along with the associated microcode and daemon are installed, everything gets loaded automatically. There should be an ipw395 automatically created in /etc/modprobe.d. At least that's how my installation went (I used Alien Bob's slackbuilds and sources http://www.slackware.com/~alien/slackbuilds/ipw3945/). When your system is started everything should work without any input on your part.
/etc/rc.d/rc.modules is a symlink to one of the two module files in the you etc/rc.d/ directory - which is based on your kernel - in my case its the "SMP" version. I suppose each would have the relevent modules, based on kernel configuration, uncommented. If you are you need a particular module which is not being loaded automatically just uncomment it in the rc.modules file. If the command to load it is not available (as in the case of the acpi modules (processor, thermal, fan and so on)) just add a "/sbin/modprobe 'module_name'" command to the file. That should work provided of course the module is availble on the system.
Adding the necessary options to a file (any file, but it's a good idea for your sanity to use intuitive names) in /etc/modprobe.d/ should work just fine - have a look at modprobe.conf(5) for more information.
About "modules.d" - this is possibly from the 2.4.x kernel days; the old modutils (which is the 2.4 kernel's version of module-init-tools) used /etc/modules.conf, so it probably supported /etc/modules.d/ as well. Alternatively, some distributions (including whatever intel uses for testing) might patch module-init-tools to look in /etc/modules.d/ instead of or in addition to /etc/modprobe.d/ - whether either of these ideas is correct, and if so, which one, is anybody's guess; it's not important enough at this point for me to research it any further.
To make a long story short(er), the recommended way to do what you're wanting is to create a file in /etc/modprobe.d/ - do it that way. If, however, you prefer to use /etc/modprobe.conf, it will also work, as there's a symlink in /etc/modprobe.d/ pointing to that file.
On the subject of /etc/rc.d/rc.modules*, you'll need to have a look at /etc/rc.d/rc.S to understand how that works. I'll break up the code segment to elaborate, but you'll probably wish I'd just shut up :-)
# This loads any kernel modules that are needed. These might be required to
# use your ethernet card, sound card, or other optional hardware.
# Priority is given first to a script named "rc.modules.local", then
# to "rc.modules-$FULL_KERNEL_VERSION", and finally to the plain "rc.modules".
# Note that if /etc/rc.d/rc.modules.local is found, then that will be the ONLY
# rc.modules script the machine will run, so make sure it has everything in
# it that you need.
if [ -x /etc/rc.d/rc.modules.local -a -r /proc/modules ]; then
echo "Running /etc/rc.d/rc.modules.local:"
In other words, if /etc/rc.d/rc.modules.local exists and is executable, we'll use it and move on. That's nice, because you probably already know exactly which modules you want to load, regardless of what kernel you're using. Therefore, you can make a custom rc.modules.local with those modules listed in it, and then you don't have to worry about this any more. I'll paste or post a link to my custom rc.modules.local at the end of this.
elif [ -x /etc/rc.d/rc.modules-$(uname -r) -a -r /proc/modules ]; then
echo "Running /etc/rc.d/rc.modules-$(uname -r):"
. /etc/rc.d/rc.modules-$(uname -r)
Assuming you're running kernel version 126.96.36.199-smp, this means that if rc.modules-188.8.131.52-smp exists and is executable, we'll use it and move on. This will happen by default if you're using one of the stock kernels and haven't modified anything pertaining to this in the /etc/rc.d/ directory.
elif [ -x /etc/rc.d/rc.modules -a -r /proc/modules -a -L /etc/rc.d/rc.modules ]; then
echo "Running /etc/rc.d/rc.modules -> $(readlink /etc/rc.d/rc.modules):"
If neither of the first two cases are true, but you have an rc.modules symlink pointing to another file, then use it and move on.
elif [ -x /etc/rc.d/rc.modules -a -r /proc/modules ]; then
echo "Running /etc/rc.d/rc.modules:"
Finally, if rc.modules is an actual file and is executable, use it. (Note that this should not be the case on any modern system, and it's not recommended either, as that file will be wiped on install/upgrade of any kernel-modules packages).
Finally, here's my rc.modules.local:
# rc.modules 11.0 Tue Jul 25 14:38:32 CDT 2006 pp (rb), pjv
# Modified for custom use by Robby Workman 20070818
# Determine the version of the running kernel:
# Also determine a "short release" such as 2.4, 2.6, etc.
SHORTREL=$(echo $RELEASE | cut -f 1,2 -d .)
### Update module dependencies ###
# If /usr is mounted and we have 'find', we can try to take a shortcut:
if [ -x /usr/bin/find -a -e /lib/modules/$RELEASE/modules.dep \
-a /lib/modules/$RELEASE/modules.dep -nt /etc/modules.conf ]; then
NEWMODS="$(/usr/bin/find /lib/modules/$RELEASE -type f -mindepth 2 -newer /lib/modules/$RELEASE/modules.dep)"
# Only rebuild dependencies if new module(s) are found:
if [ ! "" = "$NEWMODS" ]; then
echo "Updating module dependencies for Linux $RELEASE:"
echo "Module dependencies up to date (no new kernel modules found)."
else # we don't have find, or there is no existing modules.dep, or it is out of date.
echo "Updating module dependencies for Linux $RELEASE:"
# ACPI Stuff
# Power scaling
# Kernel MPPE module for PPTP VPN
Last edited by rworkman; 08-20-2007 at 09:06 PM.
Reason: Forgot to add rc.modules.local sample
i didn't have an ipw3945 automatically created in /etc/modprobe.d (i didn't use Alien Bob's slackbuilds; i kinda wish i had), so i had to make one myself. that could be the reason why modprobe is not working.
thanks for telling me about the symlink, but the issue remains that it's not pointing to a module file with my kernel version on it. the two module files present are 184.108.40.206 and 220.127.116.11-smp, but my kernel is 18.104.22.168. ... am i missing something...?
thank you for pointing me in the right direction on creating a /etc/modprobe.d/ipw3945, as well as for the abundance of information relating to rc.modules. using your config, i created a new file "rc.modules.local" in /etc/rc.d. the problem remains, however, that modprobe is not doing its job. this must be because /etc/modprobe.d/ipw3945 file is faulty, probably because i created it, and i don't know how to correct it.
That modules.d/ directory referenced above was neither of the things I suggested - instead, it appears to be analogous to Slackware's /etc/rc.d/rc.modules*
For the purposes of this discussion, /etc/rc.d/rc.modules loads modules, while /etc/modprobe.d/* sets special options for (or blacklists) those modules when they load.
I'd have to see the whole installation document to give you better ideas from here, but maybe that gets you pointed in the right direction. Honestly though, you might be better off to have a look at what Eric Hameleers (alienBOB) has and try using it.
ahhh... interesting distinction. (i didn't misread the installation doc, did i? goes to check. no.) it looks like i assumed that slackware's "modprobe.d" was analogous to "modules.d", but i guess it isn't...
since i've put a lot of work into installing the ipw3945 driver, i want to stick with it until it becomes futile (which hopefully won't happen). i wish i'd known about alien bob's slackbuild earlier, though. even so, i'm glad i installed the driver by hand; i learned a lot of things on the way.
anyways! i'm looking at alien bob's slackbuild.ipw3945 doc, trying to figure out some clues...
from what i can tell with my limited understanding of programming language, it looks like there is a /etc/modprobe.d/ipw3945 file, so we were on the right track. i tweaked a few more things, but none of it has worked so far... i'll come back to this tomorrow.
Usually, when you see a # or $ in examples, it means that's a command that should be run from your shell.
The first line appends "install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; /sbin/ipw3945d --quiet" to /etc/modprobe.d/ipw3945 file. echo is a command used to output stuff and >> redirects the output. The \ characters tells the shell interpreter that the same command line continues below.
So the actual content of /etc/modprobe.d/ipw3945 should be:
ahh. thank you for explaining the nuances of that code to me -- i knew there was something wrong with it... it was just a simple matter of coding misinterpretation. the modprobe works perfectly now.
so let me get the straight: you removed "# echo" and "\" because those were to let me know how they were meant to be interpreted by the shell. you removed the ">> /etc/modprobe.d/" because... the modprobe command already knows that the driver is supposed to be in "/etc/modprobe.d" -- it was just to let me know where the driver should've been located?
Those where shell commands you should have ran form command line. But the echo command is missing quotes and there for wont work. The >> means append to a file. So if you ran these two commands you would have a file /etc/modprobe.d/ipw3945 with the correct info in it without having to edit the file with a text editor.
echo will print everything in the quotes, >> redirects the output of echo from the screen and appends it to a file.
the back slash ("\") just means a line break and does nothing but make the command easier to read.
If you want to see this work just run these two commands.
okay, i've been running everything as root -- "modprobe ipw3945" and "dhcpcd eth1" -- but now i want to be able to do everything as non-root (but not necessarily during boot). so i decided to follow ipw3945's instructions on 'running as non-root', and now i have a whole new set of problems.
now, when i try the load the driver as root, i have to do "modprobe ipw3945" as well as "ipw3945d" (the daemon) after that. the daemon won't load by itself, even though i have /etc/modprobe.d/ipw3945 configured as thus:
so basically, i seem to be having problems with daemon permissions. i'd like to be able to the load the driver+daemon as non-root in one step. can anyone help me with this? i'd also like to know how to run dhcpcd as non-root, if possible.