On Thu, Feb 14, 2008 at 03:08:54PM +1100, Steven Haigh wrote: > > -----Original Message----- > > From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On > > Behalf Of nate > > Sent: Thursday, 14 February 2008 2:46 PM > > To: centos at centos.org > > Subject: Re: [CentOS] Kernel 2.6.18-53.1.13.el5 fails on network. > > > > Indunil Jayasooriya wrote: > > > > > I also got this type of probles once before. pls check initrd image. > > > pls performe below steps. > > > > > While it's always good to make sure your initrd is in a good state, > > the network drivers don't need to be in the initrd (unless your booting > > from NFS or something). They can be loaded fine from > > /lib/modules/`uname -r` > > > > What kind of network chip(s) are in the system? What driver are they > > using?(/etc/modprobe.conf), it'd be helpful to have the output of > > dmesg as well from the kernel that doesn't provide networking support. > > The network is an e100 - dmesg shows the following: > # dmesg | grep e100: > e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI > e100: Copyright(c) 1999-2005 Intel Corporation > e100: eth0: e100_probe: addr 0xdfffe000, irq 169, MAC addr > 00:02:B3:8B:BE:26 > e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex > > Of course, this doesn't give us the exact chip, however mii-tool is a bit > more helpful: > # mii-tool -v eth0 > eth0: negotiated 100baseTx-FD, link ok > product info: Intel 82555 rev 4 > basic mode: autonegotiation enabled > basic status: autonegotiation complete, link ok > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD > flow-control > link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD > > The interesting part for me however, is that certain things unrelated to the > network also fail. I would expect iptables to come up as OK on boot - even > if no network device was configured - as its independent of network > configuration. It also doesn't explain how the firmware microcode update > also fails. > I had similar problem with a Linux system (Fedora) which was using SElinux in enforcing mode (like CentOS is doing by default) after I booted from a CD not supporting SElinux and editing some configuration files (like ifcfg-eth0) which has lost appropriate SElinux labels because of that. This is most probably different from what you see (one kernel working OK, the other not); no-one was tinkering with /lib/modules from not-SElinux CD, right? > > You could write a script for some person at the remote co-lo to execute > > when the system comes up w/o network, the results could be stored in > > a file on the disk and when the system is rebooted again under the > > old kernel you can examine them for possible causes. > > > > Some commands to try: > > dmesg > > ifconfig -a > > mii-tool > > route -n > > ping -c 5 (IP of default gateway) > > arping -c 5 (IP of default gateway) > > arp -an > > lsmod > > I have a bit of trouble with this, as the only person that can do it is > around 30 minutes travel from the colo. As the system boots, I'm thinking of > writing a script that will gather this, then reboot the system after > changing the default=x line in /etc/grub.conf - however obviously I want to > make sure it works 100% before I tell the machine to reboot ;) IP KVM device would be your friend (unfortunately they are not cheap...) > > -- > Steven Haigh > > Email: netwiz at crc.id.au > Web: http://www.crc.id.au > Phone: (03) 9001 6090 - 0412 935 897 Best regards, Wojtek