[CentOS] Why Kudzu, Why?

[John Hinton]

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