Mates: I think I've found the cause and the cure -- but not the answer.
OK, next go round it complains that it is now looking for another hardware address for eth1 - no changes to the system... It is looking for the NIC at 00:04:5a:87:c8:43. WTF? OK, easy enough: cp eth-id-00:4c:69:6e:75:79 eth-id-00:04:5a:87:c8:43; rm eth-id-00:4c:69:6e:75:79. rcnetwok restart -- it works! Reboot. I understand that the pci bus and the order that devices are activated and their addresses are dynamic. But where do I stop the randomness??
The problem seems to be in /etc/udev/rules.d/30-net_persistent_names.rules. The question [bug] is how in the heck duplicate entries got created in the first place. Something in SuSE setup must have created the first entry. Of course, the hardware address is wrong, but for some reason it is there. As noted, this must be a popular MAC address given the 372 references to it on Google. Also, it must have worked following installation since Yast and online update were able to connect during set up. # This rules are autogenerated from /sbin/rename_netiface. But you can modify # them, but make sure that you don't use an interface name twice. Also add such # interface name rules only in this rules file. Otherwise rename_netiface will # create wrong rules for new interfaces. # It is safe to delete a rule, as long as you did not disable automatic rule # generation. Only if all interfaces get a rule the renaming will work # flawlessly. See also /etc/udev/rules.d/31-net_create_names.rules. # # Read /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names for # further information. # # Use only a-z, A-Z and 0-9 for interface names! # SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:4c:69:6e:75:79", IMPORT="/sbin/rename_netiface %k eth0" SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:04:5a:87:c8:43", IMPORT="/sbin/rename_netiface %k eth1" Then on subsequent reboot, the network failed because there is no NIC that corresponds to eth-id-00:4c:69:6e:75:79. Also, due to the multiple entries in /etc/udev/rules.d/30-net_persistent_names.rules above, eth0 would fail and the NIC with the real MAC address of 00:04:5a:87:c8:43 would load as eth1. This caused no end of WTFs? Reading the list, I know I'm not the only poor sucker that has pulled his hair out over this problem. The problem seems to be that somewhere during initial setup, if Yast can't guess the right driver or MAC for the NIC, it makes one up that will work. Then it leaves the guessed at MAC and device in the above file. This is a big problem. I'll leave it to the Gurus to figure out who?, what?, where?, when?, how? and why? this happens and how? to fix it. Thanks for all that replied. If you have lost eth0 and don't know why you can't get it back, I'll bet that it is for the same reason. -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --