On Mon, Jan 10, 2011 at 12:08 PM, Rudi Ahlers Rudi@softdux.com wrote:
On Mon, Jan 10, 2011 at 11:49 AM, compdoc compdoc@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 192.168.1.0 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?
Rudi, 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@SoftDux.com 1/10/2011 6:18 AM >>>
On Mon, Jan 10, 2011 at 12:08 PM, Rudi Ahlers Rudi@softdux.com wrote:
On Mon, Jan 10, 2011 at 11:49 AM, compdoc compdoc@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 192.168.1.0 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?
Hey,
If it happens again, or maybe it might show in /var/log/messages, if there was a MAC address conflict in the ifcfg files. I've seen where eth0 won't come on as the MAC address set in the cfg file wasnt matching. Some times it fails with a message on an ifdown ifup, sometimes it doesn't. Now that eth2 was created and the MAC is matching it works. The pieces line up but doesn't mean that it was happened. Just an idea.
Tommy C.
On Jan 10, 2011, at 6:18 AM, Rudi Ahlers Rudi@SoftDux.com wrote:
On Mon, Jan 10, 2011 at 12:08 PM, Rudi Ahlers Rudi@softdux.com wrote:
On Mon, Jan 10, 2011 at 11:49 AM, compdoc compdoc@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 192.168.1.0 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 SoftDux
Website: http://www.SoftDux.com Technical Blog: http://Blog.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Tommy, I think your scenario only pertain to those of us that clone macs with different prefixes, we are assuming that rudi is using the original MAC from the actual device. Not two macs are equal unless you change the physical device parameters via mac-changer/modification. Let's hope he is not aliasing the original mac with a multi-fake mac group link to the original NIC.
Tommy E Craddock Jr tommy@hivelocity.net 1/10/2011 8:54 AM >>>
Hey,
If it happens again, or maybe it might show in /var/log/messages, if there was a MAC address conflict in the ifcfg files. I've seen where eth0 won't come on as the MAC address set in the cfg file wasnt matching. Some times it fails with a message on an ifdown ifup, sometimes it doesn't. Now that eth2 was created and the MAC is matching it works. The pieces line up but doesn't mean that it was happened. Just an idea.
Tommy C.
On Jan 10, 2011, at 6:18 AM, Rudi Ahlers Rudi@SoftDux.com wrote:
On Mon, Jan 10, 2011 at 12:08 PM, Rudi Ahlers Rudi@softdux.com wrote:
On Mon, Jan 10, 2011 at 11:49 AM, compdoc compdoc@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
192.168.1.0 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?
On Mon, Jan 10, 2011 at 8:58 AM, Lisandro Grullon lgrullon@citytech.cuny.edu wrote:
Tommy, I think your scenario only pertain to those of us that clone macs with different prefixes, we are assuming that rudi is using the original MAC from the actual device. Not two macs are equal unless you change the physical device parameters via mac-changer/modification. Let's hope he is not aliasing the original mac with a multi-fake mac group link to the original NIC.
I've also had kernel updates change the name of the module for the NIC, and fail to detect or reload it successfully in /etc/modprobe.conf. (Don't *GET* me goiing devices changing from /dev/hda to /dev/sda, or switching numbering due to really poor vendor patches.)
(Don't *GET* me goiing devices changing from /dev/hda to /dev/sda[>] ...)
[>]
In centos, you can at least mount your storage drives like this:
[root@yourpc ~]# blkid /dev/sdb1: LABEL="sixtb" UUID="f5ef20af-fd54-4f5e-8fce-2d4f262fcfbf" TYPE="ext4"
Then add this at the bottom of fstab: (using your own uuid and type)
UUID= f5ef20af-fd54-4f5e-8fce-2d4f262fcfbf /mountpoint ext4 defaults 0 0
The uuid doesn't change.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
compdoc -
Lisandro Grullon -
Nico Kadel-Garcia -
Rudi Ahlers -
Tommy E Craddock Jr