[ale] Module handling at boot (update)
jeff hubbs
hbbs at mediaone.net
Fri Jan 11 22:35:12 EST 2002
Looks like this error has been discussed before on other lists and it
has to do with certain kernel config options not being enabled -
Kerner/User Netlink Socket and Routing Messages.
Now, I need to see if I can proceed by just changing .config and doing a
recompile or if I have to uninstall and reinstall MOSIX.
- Jeff
jeff hubbs wrote:
> Jpe -
>
> Thanks for the help; module manipulation is something I've only touched
> on to date.
>
> The upshot of my findings is this: when I boot up to the
> MOSIX-install-modified kernel, what appears at the point where eth1
> should be coming up is:
>
> Cannot open netlink socket: address family not supported by protocol
> SIOCGIFFLAGS: no such device
> failed to bring up eth1
>
> lsmod shows the 8139too mdule present but under "Used by" it says "0
> (unused)". modprobe 8139too produced nothing. I tried to remove the
> module and re-install it (rmmod, insmod) and was able to get "1" under
> "Used by" out of lsmod, but trying to bring up eth1 gives same "address
> family not supported by protocol" result.
>
> It looks like I started off with the wrong premise initially; I had said
> that I skipped the Ethernet part of menuconfig and everything i saw up
> to this point seemed to indicate otherwise, so I checked in
> /usr/src/2.4.13/.config and sure enough, I have it there as a module.
> This leads me to believe that I need to Google that error message and
> see what the heck that's really supposed to mean.
>
> - Jeff
>
> Joe Steele wrote:
>
>> Some things you might try:
>>
>> To start with, I presume 8139too is not loaded (check the output of
>> 'lsmod').
>>
>> Does 'insmod 8139too' work? (check output of lsmod again).
>>
>> If 8139too is now loaded: unload it (rmmod 8139too).
>>
>> Does 'modprobe 8139too' work?
>>
>> If 8139too is now loaded: unload it and see if 'modprobe eth1' works.
>>
>> If insmod is failing: What does 'uname -r' say? Try 'strace insmod
>> 8139too' and see if there are any clues for why it is failing.
>>
>> If modprobe is failing: try 'depmod -a' and try the tests again.
>>
>> If modprobe is still failing: try 'depmod -a 2.4.13' and try the
>> tests again.
>>
>> If modprobe now works, there may be something wrong with the way
>> depmod is executed at boot time. Take a look in
>> /etc/rc.d/rc.sysinit. Does /lib/modules/default/ exist? If so, what
>> is it linked to?
>>
>> --Joe
>>
>> -----Original Message-----
>> From: jeff hubbs [SMTP:hbbs at mediaone.net]
>> Sent: Friday, January 11, 2002 1:47 AM
>> To: kenn at refriedgeek.com
>> Cc: ale at ale.org
>> Subject: Re: [ale] Module handling at boot
>>
>> Ken Nagorski wrote:
>>
>>
>>> Hmm, that was strange. I swear I typed a message...
>>>
>>> Anyway. Yes redhat is different from slackware and the fact that you are
>>> using the ifup command says that it is redhat or some form of.
>>> At anyrate. Do this add this line to your /etc/modules.conf
>>>
>>> alias eth0 <module>
>>>
>>> That should do it for you.
>>> Thanks
>>> Ken
>>>
>>
>>
>>
>> That line is ALREADY in modules.conf; perhaps I should explain. This
>> machine was originally set up with Red Hat 7.2. I performed an
>> "express" installation of MOSIX (the clustering extension), which
>> among other things took a stock tarball of the 2.4.13 kernel source,
>> ran menuconfig for me, performed a compile and an install, modified
>> lilo.conf, etc. The problem was, when I went thru menuconfig, I
>> totally forgot about the Ethernet driver and so, the initialization of
>> eth1 (eth0 is the onboard 10base-T NIC; I've disabled it) fails
>> miserably.
>>
>> So, what I'm wanting to do is to patch up my mistake and instruct the
>> compiled (NIC-less) kernel to find and use the right module. If I
>> boot it up with the previous SMP kernel (this is a dual P/133 box),
>> the NIC works normally.
>>
>> At the moment, modules.conf looks like this:
>>
>> alias parport_lowlevel parport_pc
>> alias scsi_hostadapter aic7xxx
>> alias eth0 pcnet32
>> alias eth1 8139too
>>
>> "locate 8139too" produces (leaving out results from /usr/src which I
>> assume are not read by anything at boot time):
>>
>> /lib/modules/2.4.7-10smp/kernel/drivers/net/8139too.o
>> /lib/modules/2.4.7-10/kernel/drivers/net/8139too.o
>> /lib/modules/2.4.13/kernel/drivers/net/8139too.o
>>
>> (Note - at RH7.2 install time, a dual-CPU mobo was duly sensed and the
>> installer placed both a multiprocessor kernel and a uniprocessor
>> kernel in place and selectable by LILO- that's why there are two 2.4.7
>> entries; note that one says "2.4.7-10smp")
>>
>> If /lib/modules/<running_kernel>/kernel/drivers/net is where the ".o"
>> files go, then it doesn't appear to be missing. It just seems as
>> though somewhere downstream of modules.conf in the whole process, a
>> reference is not being made.
>>
>> I could just uninstall MOSIX and start over, but I'd prefer not to
>> have to go through menuconfig and a compile all over again (although
>> it would be fun to watch its CPUs squirm).
>>
>>
>> Thanks,
>> - Jeff
>>
>>
>> ---
>> This message has been sent through the ALE general discussion list.
>> See http://www.ale.org/mailing-lists.shtml for more info. Problems
>> should be sent to listmaster at ale dot org.
>>
>>
>
>
>
>
> ---
> This message has been sent through the ALE general discussion list.
> See http://www.ale.org/mailing-lists.shtml for more info. Problems
> should be sent to listmaster at ale dot org.
>
>
---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.
More information about the Ale
mailing list