[aklug] Re: Grokking modprobe.conf

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Sun Feb 27 2011 - 13:09:08 AKST

On Fri, 25 Feb 2011, Kevin Miller wrote:

> 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.

You're spot on.

> 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

Just as a point of clarification: modprobe.{d/*,conf} won't list
everything, only what needs special handling. Many hardware drivers are
loaded by udev purely on the basis of device IDs which are embedded in the
driver itself. Those drivers keep a list of every PCI, etc., ID that the
module supports. Unless you're overriding module defaults for various
parameters you won't find any mention of them in the modprobe stuff at all.

> # 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

This is just a guess, since I've not used hyperv, but perhaps your kernel
update was a generic update that also installed a generic initramfs image.
You may need to update your initramfs so it grabs your actual vm config.
That's the only reason I can think of off-hand that would cause those files
to be ignored.

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

:-) Good luck!

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sun Feb 27 13:09:24 2011

This archive was generated by hypermail 2.1.8 : Sun Feb 27 2011 - 13:09:25 AKST