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 at pop.psu.edu PRI/SSRI Unix Administrator