[CentOS] how to recreate eth0 - Realtek 8169sc [SOLVED]

Mon Jan 10 13:40:36 UTC 2011
Lisandro Grullon <lgrullon at CityTech.Cuny.Edu>

Sounds like a module conflict/misconfiguration, but anyway glad its working back. have you upgrade this system with the latest kernel build. I am guessing both onboard NICs are the same brand, take a look at messages and see if the card give me problems in the future. make sure you look for packet drops or errors that may hinder a bad NIC in the near future. Put your admin hat on a design a good plan to tackle this issue so you don't sweet it in the near future. Two cents.

>>> Rudi Ahlers <Rudi at SoftDux.com> 1/10/2011 6:18 AM >>>
On Mon, Jan 10, 2011 at 12:08 PM, Rudi Ahlers <Rudi at softdux.com> wrote:
> On Mon, Jan 10, 2011 at 11:49 AM, compdoc <compdoc at hotrodpc.com> wrote:
>> I love realtek - the resources they use tend not to conflict with other
>> cards or hardware, they don't use much cpu time, the drivers are mature, and
>> they don't cost much. What could be better? There does seem to be at least
>> one onboard realtek chipset that can have driver issues, but I use the 8169
>> without problems.
>> But hardware does fail. And any brand of nic can fail in odd ways. I'm
>> guessing you've swapped it out?
> Yes, the NIC might have failed, but how do I tell? lspci still shows
> it as active.
>> Bios settings can change if the on-board battery is dead and the system
>> loses power. (It can set to defaults) But bios settings rarely affect nics -
>> you're more likely to see boot problems from a change in drive boot
>> sequence.
> I already checked, BIOS settings didn't change :)
>> I don't suppose you have a vpn on your lan? I noticed you use the
>> 192.168.1.x address range, which is one of the most common ranges in the
>> world. If someone connects to your vpn from home or workplace, and if they
>> use the same range,  and if theres a bridge, addresses are going to
>> conflict.
> This is purely cause the ADSL router in the office is on the
> subnet, so it's less hassle when it needs to be swapped
> out to get it back up again. No VPN.
>> If you delete your ifcfg-eth0 or ifcfg-eth1 files, centos will recreate them
>> if it sees the nics at boot. But it tends to enable eth0 and disable eth1 or
>> higher. You should have backups of your originals for that reason...
> I've already tried that, but eth0 doesn't automatically get detected.
>> I bet you wish you had a tcp/ip based kvm switch system about now...
> Yes, I supposed I could take one from a client server, or open a
> sealed one, but it's not really necessary. For now I put in another
> D-Link and got the server up that way, but would prefer to use the
> onboard one since I had to take everything out of the 1U chassis,
> which doesn't support more than 1 additional NIC.
>> _______________________________________________

This is really weird, after I installed the 2nd D-Link card and booted
up the server everyone could work again. But I noticed and eth2 being
loaded as well, which could only make sense if the onboard NIC was in
fact still working. And it was. So I took out the D-Link, deleted
eth2, rebooted and it worked again as normal.

Why would this happen, or have happened in the first place? Why would
a NIC just loose it's drivers like that?

Kind Regards
Rudi Ahlers

Website: http://www.SoftDux.com
Technical Blog: http://Blog.SoftDux.com
Office: 087 805 9573
Cell: 082 554 7532
CentOS mailing list
CentOS at centos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos/attachments/20110110/a4f38f35/attachment-0005.html>