[root@gsvlfl-ns-1 html]# /sbin/ifconfig : error fetching interface information: Device not found [root@gsvlfl-ns-1 html]# /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:90:27:4D:A5:C0 inet addr:209.208.0.2 Bcast:209.208.0.127 Mask:255.255.255.128 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28394921 errors:0 dropped:0 overruns:0 frame:0 TX packets:27046925 errors:0 dropped:0 overruns:0 carrier:0 collisions:181003 txqueuelen:100 Interrupt:11 Base address:0x6400 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:46189 errors:0 dropped:0 overruns:0 frame:0 TX packets:46189 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 This happens infrequently enough that I've not tried to look into what's causing it.
*** Bug 7777 has been marked as a duplicate of this bug. ***
This smells like a failure while loading a module. Can you verify that the ethernet module is not loaded using lsmod when ifconfig fails?
The module is definitely loaded as I log in over the network to check the servers and incidentally generate the error.
The critical question is whether the module is loaded at the time ifconfig fails. So, just to verify, are you saying that you've seen ifconfig fail *while* you were logged in from the network? There may be other module loads causing ifconfig to occaisionally fail, not just the NIC driver.
Yup, the network driver (eepro100) was definitely loaded when ifconfig fails, it has to be loaded as I ssh in via eth0. The only other module loaded is the aic7xxx.
Does this bug still exists with newer kernels/newer distribution? If not i'll be closing this bug in 2 weeks as 'WORKSFORME' in the current release. Read ya, Phil
Closing this bug due to inactivity. Read ya, Phil