RE: Kernel 2.6.18-53.1.13.el5 fails on network.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



> -----Original Message-----
> From: centos-bounces@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On
> Behalf Of nate
> Sent: Thursday, 14 February 2008 2:46 PM
> To: centos@xxxxxxxxxx
> Subject: Re:  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.

> 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 ;)

--
Steven Haigh

Email: netwiz@xxxxxxxxx
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux