[aklug] Re: Grokking modprobe.conf

On 02/25/2011 11:25 AM, Arthur Corliss wrote:
> On Fri, 25 Feb 2011, Kevin Miller wrote:
>
>> Sorry for being dense but I'm still not getting it. In the breakdown
>> above, what's the rule part, what's the module and what are the actions?
>>
>> Is the rule called fred? Which is also a module?
>
> You'll have to pardon my poor vernacular. How about this:
>
> {type of rule} {module it applies to} {command/options}
>
> The first field states what it applies to, i.e., is it an install, options,
> remove, blacklist rule, etc. The second field is the name of the module
> this specific rule applies to (fred, in this case). The remainder is the
> relevant command, options, etc.

Ah. So what it's saying is more or less this; when you install module
fred use this rule: first install barney. Now we have barney loaded,
but not fred yet, so now install fred. But install the *module* fred,
and only the module fred, rather than the *rule* that pertains to fred.
  I.e, what it's saying to ignore is not the fred module, but the
install command. I guess in my mind, I was making 'install' and
'instantiate' equivalent.

If I'm still completely missing it holler.

>> There's lots of modules referenced in modprobe.conf, so why don't they
>> all need an --ignore-install afterwards? I presume that when modprobe
>> runs it sees that my NIC is already up, so doesn't try to load the
>> driver again. Why does that not happen with fred?
>
> Modprobe may never run at all, it really depends on how the system is
> configured. Some boot scripts may call modprobe explicitly to load
> necessary modules. Udev can call it on demand whenever it sees a hardware
> change with a device ID it knows is matched to a particular module. Some
> modules, say for a random protocol, may need to be invoked manually before
> usage.

Interesting. Just grepped /etc/init.d on my Debian & SLES systems. Did
see a number of calls to it.

> To answer your last question, you're right that if a module is already
> loaded it isn't reloaded. That should hold true with fred as well. But an
> install rule trumps the actual loading of a module, the shell commands are
> executed in lieu of loading the module. Which is why you have to tell it to
> modprobe it again in the install rule shell command section but tell it to
> ignore the install rule this time so it does the default behavior of loading
> the actual module instead of executing more shell commands.

That makes sense.

> I really hope I haven't made this more confusing...

Not at all. The haze is slowly clearing. It all gets back to the
slackware thread (lolcats not withstanding!). This stuff isn't always
easy the first time around but sometimes one just has to bite the bullet
and actually try to think a bit.

What precipitated my interest is I have a SUSE Linux Enterprise Server
11 SP1 running on top of a hyper-v host. A kernel update recently came
'm not sure that it's being installed when I boot under the previous
kernel though, but I don't see the 'FATAL' line. And it doesn't hang.
down the pike and when I reboot the screen displays:
   FATAL: Module hv_blkvsc not found.

Then hangs a few lines later. Not sure if it's related or not.

Before rebooting I can see the hv_blkvsc.ko in
   /lib/modules/2.6.32.27-0.2-default/extra

Why it's not seen I don't know.

I knew modprobe was the place to go to see what modules get loaded so
started poking around and found this in
/etc/modprobe.d/hyperv_pvdrivers.conf

# Install HyperV paravirtualized drivers
install ide_core /sbin/modprobe hv_blkvsc 2>&1 ; /sbin/modprobe \
--ignore-install ide_core
install ata_piix { /sbin/modprobe hv_blkvsc 2>&1 || /sbin/modprobe \
--ignore-install ata_piix; }

To get back up and running I revert to an earlier snapshot. The odd
thing is, ide_core and ata_piix are loaded but the hv_blksvc module
isn't but I don't see the 'FATAL' line. But at least it doesn't hang.
Other hv_* modules are loaded.

mx2:~ # lsmod | grep hv_
hv_timesource 1311 0 [permanent]
hv_netvsc 29339 0
hv_vmbus 49371 1 hv_netvsc

mx2:~ # lsmod | grep ide_core
ide_core 121827 2 ide_pci_generic,piix
mx2:~ # lsmod | grep ata_piix
ata_piix 24426 2
libata 201103 2 ata_generic,ata_piix

So now I understand modprobe better. But I'm still stumped regarding
the situation that caused all this. Good thing it's a Friday.

Thanks again. I appreciate your taking the time to explain it Arthur...

-- 
Kevin Miller
Juneau, Alaska
http://www.alaska.net/~atftb
In a recent poll, seven out of ten hard drives preferred Linux.
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.