Network Interface names differ between BIOS / UEFI

[Jochen Blacha]

Out of a discussion (with Stuart Langridge) about SystemD's new interface naming convention I discovered the following inconsistency in device naming on a BIOS vs a UEFI system...

Using QEmu, set to act as a "440FX BIOS" system, and booting up the Ubuntu MATE 16.04.2 LTS ISO I get the following output from "ifconfig" ...

eth0 Link encap:Ethernet HWaddr CA:FE:15:60:0D:70
          inet addr:192.168.0.105 Bcast:192.168.0.1 Mask:255.255.255.0
          inet6 addr: fe80::b19a:de94:6e2c:37b7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:9100 Metric:1
          RX packets:54071 errors:0 dropped:0 overruns:0 frame:0
          TX packets:48515 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:22009423 (20.9 MiB) TX bytes:25690847 (24.5 MiB)
          Interrupt:16

Doing the same thing again but with QEmu being set to act as a "Q35 UEFI" system (using the OVMF firmware) "ifconfig" gives me ...

enp0s3 Link encap:Ethernet HWaddr CA:FE:15:60:0D:70
          inet addr:192.168.0.105 Bcast:192.168.0.1 Mask:255.255.255.0
          inet6 addr: fe80::b19a:de94:6e2c:37b7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:9100 Metric:1
          RX packets:27003 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16171 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11000712 (10.2 MiB) TX bytes:8563615 (8.1 MiB)
          Interrupt:16

NOTE: The same is true on my desktop system (UEFI capable), the network interface is "enp0s5" not "eth0".

The later one would be more like what I would expect as SystemD's documentation goes to great lengths to try and explain the new naming convention for network interfaces.

This inconsistency could actually lead to further problems down the road with other packages ... for example Samba. The default example config reads "bind interfaces = 127.0.0.0/8 eth0" (commented out though) where "eth0" is not really a good example default because with SystemD it no longer exists (at least on a UEFI system - and I had that issue with several friends already where I told them "uncomment 'bind interfaces'" to have samba only bind/listen to the desired interfaces ... and then it not working because there's no "eth0"). It might be better to determine and append the lan/subnet post-install (i.e. 192.168.0.0/24) or settle on a uniform device naming convention for the network interfaces.

The problem should be reproducible by simply booting a installation ISO on a BIOS and UEFI system (or accordingly configured VM).

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1695089/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Jochen Blacha (jochen-blacha)]

Well, since a bug has to be filed against a package... I'd guess "systemd" though I would say it's somehow related to systemd-network (which doesn't seem to have a package)

[Dimitri John Ledkov (xnox)]

systemd-networkd is not a separate binary package, and the networkd daemon and units are simply shipped by the systemd binary package.

Anyway, launchpad only tracks bugs by source package, and the source package in question is good enough to be left as "systemd".

[Dimitri John Ledkov (xnox)]

To further troubleshoot this, it would be interesting to see the output of what udevadm thinks about these interfaces:

E.g. output of:
$ udevadm info -p /sys/class/net/eth0

and

$ udevadm info -p /sys/class/net/enp0s3

For the BIOS / UEFI case. Note that changing the boot type from bios to uefi on the fly is not that well support, as different sets of packages are installed / expected to be available by BIOS vs UEFI installations.

In general, udevd has been disabling persisten interface naming for the virtual machines due to instability of those interfaces. But it is interesting that "stable" names are picked for the UEFI case.

[Dan Streetman (ddstreet)]

please reopen if this is still an issue