EL 4.0 and how it does Networking now.

Waldher, Travis R Travis.R.Waldher at boeing.com
Tue May 31 15:11:57 UTC 2005


I've learned a few things this Memorial day.

1) lsmod - the "used by" column isn't as signifigant as it used to be
with the 2.4.x kernels.  This actually changed after the 2.5.48 kernel
and up.  If lspci shows the devices, and they appear to be functioning.
As in, the interface comes up and you can use it.  That is good enough.


Apparently there's been changes to the way the lsmod feature works.  I
requested Redhat to document those changes, including their replacement,
OR fix the lsmod command to work the way it always has.

2) modules.conf is now modprobe.conf.  
	The "below" nomenclature no longer works:
		"below bonding e1000 bcm5700"
	The "options" feature appears to work the same, but I won't know
for 	ure until I get past #3.

3) The bonding driver.  Apparently, someone decided that no one would
ever want to use more than 1 interface.  So they changed it to only
support one.  When you attempt to bring up the second bonding interface,
you get this:

	"bonding1 device bond1 does not seem to be present, delaying
initialization."

There is an entry in
/usr/src/kernels/2.6.9-5.EL-smp-i686/include/linux/if_bonding.h that
controls this.

The snag is, I'm not 100% sure where I modify it with the 2.6 kernel.
The best documentation I've found implies that it would work on a 2.4
kernel.  I've got a call in to Redhat for this, but I'll be upset if
they tell me it's a development problem and I don't have development
support.

Even if I do find the part of the header file I need to modify... how do
I build it?  It's built as a module, not in to the kernel.  But there is
no bonding.spec file that I could find, as is there is no rpm source to
build from either.  So, do I recompile the kernel and the module change
is picked up at the same time?  I don't know yet.

I could get the bonding rpm from elsewhere and build it like normal, but
I would rather use what Redhat shipped so they can't pull a "well that
wasn't ours so it's not our problem" should there ever be a problem in
the future.




More information about the Redhat-install-list mailing list