Score:0

Network interface logical name changed on upgrade from 18.04 to 20.04 on multiple servers

cn flag

I am seeing network interface names change on multiple servers after an 18.04 -> 20.04 upgrade done via do-release-upgrade. Before the upgrade, I had not done any customization of NIC logical names, and was using the default predictable interface name, which was enp96s0f0 and enp96s0f1 for the onboard Intel X722 NIC. These are Supermicro X11 DPi-NT motherboards.

After the upgrade, enp96s0f0 has been renamed to eno0, which broke my network config via netplan. enp96s0f1 has not been renamed and is still there.

Why would this be happening? What files can I look for to see if it is Ubuntu configuration doing this? I checked for anything related to persistent-net-rules in /etc/udev/rules.d/ and did not see any files.

Update with some information: dmesg shows this on 18.04:

i40e 0000:60:00.0 enp96s0f0: renamed from eth0

but this on 20.04:

i40e 0000:60:00.0 eno0: renamed from eth0

Here's information about the interfaces, on an updated machine where enp96s0f0 has been renamed to eno0:

$ lspci | grep X7
60:00.0 Ethernet controller: Intel Corporation Ethernet Connection X722 for 10GBASE-T (rev 09)
60:00.1 Ethernet controller: Intel Corporation Ethernet Connection X722 for 10GBASE-T (rev 09)

$ ethtool enp96s0f1
Settings for enp96s0f1:
    Supported ports: [ TP ]
    Supported link modes:   1000baseT/Full 
                            10000baseT/Full 
    Supported pause frame use: Symmetric Receive-only
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  1000baseT/Full 
                            10000baseT/Full 
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Speed: 10000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: Unknown
Cannot get wake-on-lan settings: Operation not permitted
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: yes

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether $MAC brd ff:ff:ff:ff:ff:ff
3: ens1f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether $MAC brd ff:ff:ff:ff:ff:ff
4: enp96s0f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether $MAC brd ff:ff:ff:ff:ff:ff
5: ens1f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether $MAC brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether $MAC brd ff:ff:ff:ff:ff:ff
    inet $IP brd $IP scope global bond0
       valid_lft forever preferred_lft forever
    inet6 $IPV6 scope link 
       valid_lft forever preferred_lft forever
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.