Garrick Staples wrote:
On Wed, Jan 23, 2008 at 09:39:09PM -0500, Michael Semcheski alleged:
So I have a CentOS 5 machine, which I recently did a 'yum update' on.
Everything went fine, but I rebooted as a precaution (just to confront
any problems which might arise the first time after an update).
And sure enough, when the machine came back up, the network didn't
work. Luckilly, someone said (and I quote) 'mv
/etc/sysconfig/networking-scripts/ifcfg-eth0.bak
/etc/sysconfig/networking-scripts/ifcfg-eth0 and blame kudzu'...
So, what did I do wrong, or what should I have done differently?
What's the reasoning behind this? I'll bet there is some rationale,
and I'd like to understand it.
The answer to your question lies in /etc/sysconfig/networking/profiles/
/etc/rc.d/rc.sysinit runs /usr/sbin/system-config-network-cmd to setup the
correct network profile. But I think the profile code can get triggered in
kudzu too.
I've fought similar issues over the years on various Proliant servers
and if I recall, back to Redhat 7 machines even. If there is more than
one nic interface in them, Kudzu will one time find one and then on the
next boot maybe find the other replacing the first it found. It's a
pain! I never really understood why it would change what it found during
the initial install after a reboot.
I haven't disabled Kudzu on most of my systems, but I really do wonder
if there is really any reason to keep it running after the initial
system install. These servers might get a new drive from time to time,
only replacing a drive in the array with a like drive. Maybe some
additional ram. Almost never any other hardware changes... I'm fairly
confident that these changes are all handled entirely by the system's
bios, either machine or raid interface bios.
Can anybody give a good reason to keep it running in a server non-gui
environment?
I guess Kudzu is still very weak in this area..... maybe getting worse.
John Hinton
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
