A little birdy told me that Michael A. Peters said:

] Michael Semcheski wrote: ] > 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. ] ] I don't know but I always disable kudzu after initial install on machines that ] don't change hardware because I've had similar things happen to me in ] pre-fedora redhat. I leave it on my laptop though.

just as a quick mention... i have noticed that when running the CentOS5 Xen kernel, with the default Xen configuration, "rebooting" had a tendency to reset the hardware MAC address to the fictional MAC created by the "network-bridge" script. (this may not effect all hardware, but i have seen it definately effect the "tulip" driver)

this behavior only happened on reboots, and a complete poweroff/poweron always reset the MAC to it's original value.

i "solved" it (re: prevented this behavior) by changing the Xen configuration to use "network-route" instead of the default bridge behavior... but this, no doubt, has other ramifications beyond solving the problem.

just wanted to mention this in case it's causing anyone similar headaches...

B. Karhan simon@pop.psu.edu PRI/SSRI Unix Administrator

On Jan 23, 2008 10:02 PM, John R Pierce pierce@hogranch.com wrote:

I'd probably have diff'd the files before overwriting to see wtf was hosed.

That was my first thought.

There was no ifcfg-eth0, only ifcfg-eth0.bak.

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

John Hinton wrote:

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.

I've been disabling kudzu on all of my systems immediately after kickstart(along with a slew of other services) for years now. New ram is picked up automatically(unless your on 32-bit and need to upgrade to a PAE kernel or something). I don't change the local disk count but many systems are constantly getting/removing disks from the SAN, (primarily software iSCSI), no kudzu needed. When I manipulate FC connected systems I just use the /proc/scsi/scsi interface, it's fairly simple.

Also most of my servers have dual network ports, and most are on only one network so I bond the interfaces together(active/failover) so either/or/both NICs can be plugged in and it'll work fine.

Running about 90 RHEL/CentOS systems at my current place, had around 350 at my last job.

nate