From: "Per Jessen"
Per Jessen wrote:
david rankin wrote:
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.
Yep, I would report that to Novell - bugzilla.novell.com. Especially given that some apparently bogus MAC-address is found and entered.
I did some more googling, and I'm beginning to think 00:4c:69:6e:75:79 is somehow a default MAC-address created/assigned by the tulip driver when it cannot find a MAC-address on the device itself.
Yep, I've just now had a look at the tulip driver - the 00:4c:69:6e:75:79 is exactly that, a fake MAC-address:
tulip_core.c:
char last_phys_addr[6] = {0x00, 'L', 'i', 'n', 'u', 'x'};
When no EEPROM is found, the MAC-address is setup as the above. ('L'=0x4C, 'i'=0x69, 'n'=0x6e, ... etc).
I could suspect this whole thing to be caused by a faulty NIC that sometimes reports a MAC-address, and sometimes doesn't. At install-time, it didn't and you ended up with 00:4c:69:6e:75:79 = "Linux". Sometime later the NIC did come up with a MAC-address, and YaST can't help but conclude you've got two NICs.
Per, This is the most plausable explanation I can think of. But what it doesn't explain (or what I'm definately not smart enough to understand) is how on initial boot the system was able to use the 'fake' MAC address for online update, etc.. It could be the card itself getting flakey, but I don't think so. It seems more likely that there is something in the install process that causes Yast to pull the default MAC instead of the MAC from the card. Oh, well, at least I have learned quite a bit more about device and interface initialization by this exercise. -- 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 --