[CentOS] Re: network config files in centos 5 changing

[Scott Silva]

Jerry Geis spake the following on 4/26/2007 1:23 PM:
>> Scott Silva spake the following on 4/26/2007 12:25 PM:
>>> / Scott Silva spake the following on 4/26/2007 12:04 PM:
> />>>/ Jerry Geis spake the following on 4/26/2007 11:53 AM:
> />>>>>/ i believe i had mentioned this already on this list:
> />>>>>/ have had same problems with my asus m2npv-vm board  (onboard
> />>>>>/ forcedepth nic) the first days with the board under fedora 6 -
> would
> />>>>>/ say no big diff's to centos-
> />>>>>/ the fedora way goes:
> />>>>>/ 1. move or delete /etc/sysconfig/hwconf
> />>>>>/ 2. move or delete /etc/modprobe.conf
> />>>>>/ 3. run kudzu afterwards => this writes new hwconf, modprobe.conf
> />>>>>/ 4. bring your nic's down: ifdown ethx
> />>>>>/ 5. remove the driver via modprobe -rv <your-nic-driver>
> (forcedepth)
> />>>>>/ 5a. maybe to be sure: lsmod|grep -i <your-nic-driver>
> />>>>>/ 6. reload the driver via modprobe -sv ...
> />>>>>/ 7. fix your mac-addr-settings via system-config-network
> />>>>>/ 8. compare your mac's in hwconf _and_ via ifconfig
> />>>>>/ steps 4-6 are also performed via reboot (grrrrrrrrrr: m$ world
> tasks),
> />>>>>/ but your are able to exclude if this files were changed again after
> />>>>>/ step 3. (ls -l /etc/sysconfig/hwconf => date/time !)
> />>>>>/ a hint of another problem !
> />>>>>/ if there are still diff's, then it's another problem i don't know a
> />>>>>/ solution for, yet, but i remember ethx order changes and
> therefore mac
> />>>>>/ mismatches at late fedora 5/early fedora 6 kernels.
> />>>>>/ try and report !
> />>>>>/ okay ?
> />>>>>/ -- />>>>>/      ronald
> />>>>/ Ronald,
> />>>>/
> />>>>/ Thanks for the above. However, sadly it did not work.
> />>>>/ Also I see no way in the system-config-network to set a MAC address.
> />>>>/ I was in the character mode here not X.
> />>>>/
> />>>>/ This is SOOO bizzar. Again, when I started I had 2 Asus M2N-MX
> boards.
> />>>>/ One was giving the invalid MAC address and one seemed OK.
> />>>>/ Both had the forcedeth driver loaded for onboard network.
> />>>>/
> />>>>/ I bought 2 gigabyte motherboards (DIFFERENT BIOS) and I have the
> same
> />>>>/ issue. One board is working and the other is giving the invalid MAC
> />>>>/ address.
> />>>>/ Both gigabytes have the forcedeth driver.
> />>>>/
> />>>>/ I tried loading centos 4 but it does not even recognize the
> forcedeth
> />>>>/ device at all.
> />>>>/ even manually loading.
> />>>>/
> />>>>/ I'm at a loss. I have a script file that runs and sets things up
> the way
> />>>>/ I want after boot up. Not pretty - but I guess it works.
> />>>>/
> />>>>/ Jerry
> />>>/ This appears to be a bug in the forcedeth driver and the chipset.
> The driver
> />>>/ seems to pull the current MAC address from a register, and writes
> it back
> />>>/ differently. The systems with the trouble must allow this write to
> take place,
> />>>/ and it changes the MAC address for the next boot.
> />>>/ I think if you add a HWADDR: xx:xx:xx:xx:xx:xx  command to the
> ifcfg script,
> />>>/ it might stick. You will have to find your real MAC address on
> your own, but
> />>>/ it might be on a sticker somewhere on the board, or in a service
> tag on the
> />>>/ equipment.
> />>>/
> />>/ Ignore the HWADDR line. I am pretty sure that is the wrong command,
> but I
> />>/ can't find the right one anywhere.
> />>/ />>/ You could try the NVidia network driver, or manually compile
> the forcedeth
> />>/ 0.60 driver, which is reported to fix this. Maybe upstream will add
> this
> />>/ driver to their kernels so it can flow back to CentOS.
> />>/ />I found the command just as I hit send.
>> Try MACADDR=<MAC-address> in the if-cfg file.
>> Look at this page for more details.
>> http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/s1-networkscripts-interfaces.html
>>
> 
> 
> Scott,
> 
> THanks - I tried this just now and it did not work... The new kernel is
> working but iptables is not compiled in???
> 
> Jerry
This was in response to using the original kernel. Using the newest kernel
source will leave you out in the cold as far as support is concerned. It might
just be more prudent to add another card and wait to see if redhat updates the
 forcedeth code in the next kernel.

You could look at the kernel source rpm to see what patches are added by
redhat. That might give you some clue on what is missing.

-- 

MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!