[ale] Module handling at boot

[Joe Steele]

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.