2 identical F19 systems, different NIC device names, what's up with that?

[gregscott]

Hello - I just finished reading
http://www.freedesktop.org/wiki/Soft...nterfaceNames/

that tells me F19 has an even newer and better way to name NIC devices. Names are supposed to be stable, predictable, and persistent now. This time we really mean it. Even more than before.

Wonderful.

I have two identical systems here. Bought with the same order, same parts, built at the same time. **Identical** hardware. The hardware starts with Jetway JNF9D-2550 motherboards and both systems have 5 total NIC slots.

I just installed F19 64 bits on both systems. I see files in /etc/sysconfig/network-scripts named ifcfg-enp2s0, ifcfg-enp3s0, ifcfg-enp5s4, ifcfg-enp5s6, ifcfg-enp5s7.

So far so good, I guess. The names are a little different than F15 thru F18, but I can live with it.

But now it gets weird. When I do ip link show, I see p1p1, p2p1, p2p2, p3p1, p4p1 on one system. On the other, I see devices p1p1, p2p1, eth2, p3p1, p4p1.

Note the device named eth2 instead of p2p2 on the second system.

I don't really care what the device names are, but I need them consistent across my systems. My questions:

1 - Why are the pnpn names different than the enpnsn names?
2 - What's going on with that eth2 name?
3 - How do I get rid of all these naming layers and just name it all consistently?

thanks

- Greg Scott

[nirik]

Possibly: https://fedoraproject.org/wiki/Commo...ame-vs-systemd

[muep]

The interface names you mention (p1p1, p2p1 and so on) sound like the ones used by the biosdevname mechanism. The page you linked to describes the new mechanism built into udev. It does not sound like this mechanism is currently being used on your system.

[gregscott]

Yup, Nirik and Muep, that link Nirik mentioned seems to describe it. Sort of. Except the ifcfg-nnnn file names are the new F19 style, but the actual device names are the F15-F18 style. Except one NIC is named eth2 on one system, p2p2 on the other. So the two systems are not consistent with each other, even though the hardware is identical. Somebody once said the definition of insanity is doing the same thing the same way and expecting different results. I built both systems a few hours ago the same way - I don't get why the results are different. Am I witnessing insanity?

I wonder what would happen if I remove that biosdevname package or if I can even remove it?

- Greg

[gregscott]

Actually, for what it's worth, this paragraph is only partially true:

In practice, as things have turned out with the final Fedora 19, it seems that the Fedora installer still uses biosdevname, and writes the interface names produced by biosdevname into the configuration files for each interface. The Package-x-generic-16.pngbiosdevname package is also still installed by default. We therefore expect that Fedora 19 will in fact mostly behave as if biosdevname is still the system in use, both on new installations and upgrades.

Check this out. Note the MAC Addresses that tie the device name with the ifcfg-ethnn file. Something is renaming the devices and doing it differently on different systems. And getting between the ifcfg-nnn file and the actual device name.

First system:

[root@localhost network-scripts]# more ifcfg-enp5s4
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=enp5s4
UUID=88129b87-db47-40df-9b45-265d5859ab0a
ONBOOT=no
HWADDR=00:30:18:A2:A3:3E
PEERDNS=yes
PEERROUTES=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
[root@localhost network-scripts]# ip link show dev p2p2
4: p2p2: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
link/ether 00:30:18:a2:a3:3e brd ff:ff:ff:ff:ff:ff
[root@localhost network-scripts]#


Now the second system:

[root@localhost network-scripts]# more ifcfg-enp5s4
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=enp5s4
UUID=8c9576d4-79b7-46d5-a70e-8d49bb470bc3
ONBOOT=no
HWADDR=00:30:18:AA:F4:20
PEERDNS=yes
PEERROUTES=yes
[root@localhost network-scripts]#
[root@localhost network-scripts]# ip link sho dev eth2
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
link/ether 00:30:18:aa:f4:20 brd ff:ff:ff:ff:ff:ff
[root@localhost network-scripts]#

Go figure. I wonder if there's a workaround?

- Greg Scott

[gregscott]

Hmmm....

That biosdevname package must somehow glom onto the new F19 style device names and superimpose the F15-F18 style names on top. Seems overly complicated to me for no benefit.

But I think I have a workaround for my misnamed device problem. Hopefully this will help others.

First, see what biosdevname package(s) are installed:

[root@localhost network-scripts]# rpm -qa | grep biosdev
biosdevname-0.4.1-4.fc19.x86_64

Next...

yum remove biosdevname

and reboot.

After the reboot, "ip link show" displays the new F19 style network devices. It's tempting to just leave it this way. Simple is good. But the Fedora folks went to some trouble to install this biosdevname backwards compatibility package by default for a reason, so let's put it back and see what happens. . .

Set up an IP address, route, and DNS so this system can find the Internet and do:

yum install biosdevname

and reboot.

And now - "ip link show" displays the F15 - F18 pnpn style names and the reference to eth2 is gone. It's now p2p2 and so both systems are consistent.

So what happened? The only thing I can come up with is, the hardware behaved a certain way during the original Anaconda installation to make the now even more complicated device naming stuff come up with eth2 instead of p2p2 for a device name. When I removed/reinstalled the biosdevname package, the hardware must have responded more to my liking.

Is it OK if I rant a little bit? One major appeal for Linux is simplicity and maintainability, right? But now, with F19, I have this black box RPM package named biosdevname that adds another layer to the device naming mystery and apparently doesn't always get it right. I get that F19 wants an even more generalized approach to device naming, so if this new approach really is better, why add complexity by layering the old-new names on top of the new-new names but not always getting it right? Why not just go with the new-new names by default, document it prominently, and have that biosdevname package available for users who need the old-new names?

thanks

- Greg Scott

[gregscott]

Oh wow. I should close the loop on this. It turns out, biosdevname is a train wreck. Biosdevname listens to BIOS reporting for what NICs are where and then sets up a naming scheme based on that. But not all hardware does that BIOS reporting the way biosdevname expects. There are some bugzillas around this. The net result is, systems that use biosdevname style names may not have consistent NIC names from one boot to the next. My workaround above - to remove biosdevname and then reinstall it - worked that one time only because of random timing.

So that's an implementation problem. But biosdevname also has an architectural problem. Apparently, if you insert a NIC in front of existing NICs, assuming all works properly, all those existing NICs will have a different name and the new NIC will take on the name of an old NIC. You'll have to straighten all this out in the /etc/sysconfig/network-scripts/ifcfg-* files by hand.

The only solution to get consistent device names is remove biosdevname. Just get rid of it if it's already installed and edit your ifcfg* files by hand. If it's a fresh install, install without it. And this is all in a bugzilla too. RHEL 7 defaults to not using it, apparently except for Dell hardware, and I think F21 and newer won't use it anymore.