Why does the driver rename my NIC?

berndbausch · 02-09-2019, 09:14 PM

I have a bunch of identical Proliant blades (I think they are identical) networked via virtual connect. They run OpenSuse 15.

Each blade has four NICs, which show up as eth0..eth3. Except that one blade lists them as eth0, eth2, eth3, eth4.

During system startup (way before udev kicks in) I can see this in the message buffer:

Code:

$ sudo dmesg |grep renam
[   17.515161] be2net 0000:06:00.1 rename3: renamed from eth1
[   17.544737] be2net 0000:06:00.2 eth4: renamed from eth2
[   17.594555] be2net 0000:06:00.1 eth2: renamed from rename3

eth3 is not renamed.

Adding net.ifnames=0 biosdevname=0 to the kernel parameters doesn't change anything. The interfaces are still renamed in this erratic way.

I know about predictable network interface names, but here they are unpredictable. Any suggestions how I can get the original names?

Brains · 02-09-2019, 09:47 PM

Not sure which file OpenSuse uses, but may be one of the examples here. On my current OS Fedora, it's a matter of changing the name of the file /etc/sysconfig/network-scritps/ifcfg-eth5 and change the name in the file also for DEVICE=

berndbausch · 02-09-2019, 10:20 PM

Yes, I know I can use udev, or work around the problem by adapting my configuration to the new names, which is simpler than fiddling with udev rules. I used the second option.

But either approach requires me to change the set up of my system software. This strikes me as a band-aid solution.

Ideally, I want to find out what motivates the kernel or NIC driver to change the interface name. This should help me understand how the servers are different.

Or at least, is there a way to prevent this change from happening in the first place?

Brains · 02-09-2019, 11:12 PM

You could try to recreate the /etc/udev/rules.d/70-persistent-net.rules if it exists, example: mv /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules.bac to back it up. A reboot should reproduce it or can be done from command line with: /sbin/udevadm trigger --type=devices --action=add
I found this article marked solved.

Brains · 02-09-2019, 11:26 PM

I'm guessing information in that file is based on the information in the /etc/sysconfig/network-scritps/ files, as per the suggestion in that last link, there may be an error in one or more, since you should have four in there, maybe UUID or as mentioned, unprintable error.
EDIT: You can also compare those scripts with the ones in the other blades, might spot the issue

mrmazda · 02-10-2019, 10:36 PM

Only very recently I discovered that openSUSE's historic use of /etc/udev/rules.d/70-persistent-net.rules isn't any more needed, and could very well be the reason for eth1 being skipped. All that's needed is net.ifnames=0; no need for biosdevname=0 (which isn't included in any of my openSUSE installations).

A MAC address in /etc/sysconfig/network/ifcfg-eth1 also might be the cause. IME, normally there will not be one in an openSUSE installation.

berndbausch · 02-11-2019, 04:44 AM

I don't think the interface is renamed by udev, but rather the driver or kernel without request to rename it. it's currently hard to double check that right now, as I can't afford to reboot the server.

My ifcfg files don't contain UUIDs or MAC addresses. They are identical across the blades, except for IP addresses (in fact, all eth[0-4] are members of bridges).

When I have a chance to explore that further and if I find anything, I will report the result. For now I just adapted my configuration to the new interface numbering and focus on other problems.

jefro · 02-11-2019, 08:54 PM

I think this is a good starting place. https://doc.opensuse.org/documentati...a.network.html