Ethernet interface strageness?

[Scott Olsen]

Hi Everyone,

Has anyone ever received a CPS-MSP platform with multiple entries in:

/etc/udev/rules.d/30-net_persistent_names.rules

...resulting in interfaces at ETH3 and ETH4?  Is this typical, or have I got a weirdo here?  The following was in the above mentioned file...

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:25:90:0e:2c:e8", IMPORT="/l                         ib/udev/rename_netiface %k eth0"

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:25:90:0e:2c:e9", IMPORT="/l                         ib/udev/rename_netiface %k eth1"

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:25:90:0e:2c:eb", IMPORT="/l                         ib/udev/rename_netiface %k eth3"

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:25:90:0e:2c:ea", IMPORT="/l                         ib/udev/rename_netiface %k eth4"

Where checking the actual hardware revealed only two actual ethernet adapters:

/etc/udev/rules.d # lshal | grep mac_address

  net.80203.mac_address = 161330638058  (0x25900e2cea)  (uint64)

  net.80203.mac_address = 161330638059  (0x25900e2ceb)  (uint64)

Could they have been in the image used to stage the servers?  Highly unlikely due to the serial nature of the reported MAC addresses. 

Any ideas?

[Gerald Burgess · Accepted solution]

It's an easy problem to fix, but I agree it's odd that it would show up on a new server.

We normally see that on systems that have had all the disks in the raid moved onto a new system.  If the chassis has to be swapped for example.

If I had to hazard a guess, I'd say the box of disks that were included with your server were originally set up for the chassis just ahead of it in line.

To fix it just go into this file:

/etc/udev/rules.d/30-net_persistent_names.rules  You can change the reference to eth3 to say eth0.  Either that or delete the lines that look like this:

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:30:48:cc:d6:b3", IMPORT="/lib/udev/rename_netiface %k eth1"

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:30:48:cc:d6:b2", IMPORT="/lib/udev/rename_netiface %k eth0"

When you reboot the system it automatically recreates the subsystem lines if they aren't there.

Either way you'll need to reboot the system for the changes to take effect.

[Scott Olsen]

I bet it is exactly as you had theorized. This server was part of a multiple server order with several identical configurations. I checked the SN# associations on the disk set and server 3 times, and absolutely assured I had the proper set.  Still, on first boot, it indicated that all the disks previously configured were missing.  I powered down the server and re-checked all the physical drive members to ensure they were seated properly in the enclosure.  On a second boot, I was informed that a Foreign disk configuration was detected and whether or not to import it.  At this point, I was pretty much resigned to the fact that I may have to re-image the server for reasons unknown, so I figured... hey, why not import it and see what happens?  Next boot... SLES loads up no issue.  Only thing that seemed off were the "ghost adapters" and the ETH interface numbering being offset as a result.

I agree, it's not a difficult fix, but unless you know where to look, a person could burn a lot of time trying to figure out WTH was going on.  At least we have it in a searchable forum now ;-)

Cheers!