La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 22 septembre 2021 à 08:42:45
-
Interface réseau d'un serveur qui passe du nom "em1" à "eth0"
OS : Ubuntu-Server 20.04 LTS (Installation avec 14.04 puis mise à jour 14.04 ⇒ 16.04 ⇒ 18.04 ⇒ 20.04)
L'incident est survenu lors d'une bascule du noyau GA (5.4) vers le noyau HWE (5.11 actuellement)
cf Tutoriel pour comprendre et changer de noyaux Linux avec Ubuntu 20.04 LTS (https://lafibre.info/serveur-linux/noyaux-linux/)
et là plus de réseau avec le reboot sur le noyau 5.11. En repassant en 5.4, le réseau est disponible.
Voici les infos de dmes | grep bnx2 :
Noyau 5.4, le réseau est ok :
[ 2.992331] bnx2: QLogic bnx2 Gigabit Ethernet Driver v2.2.6 (January 29, 2014)
[ 3.040639] bnx2 0000:01:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d4:ae:52:ce:c5:c7
[ 3.107974] bnx2 0000:01:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d4:ae:52:ce:c5:c8
[ 3.259068] bnx2 0000:01:00.1 em2: renamed from eth1
[ 3.352484] bnx2 0000:01:00.0 em1: renamed from eth0
[ 7.277952] bnx2 0000:01:00.0 em1: using MSIX
[ 8.329572] bnx2 0000:01:00.1 em2: using MSIX
[ 10.341387] bnx2 0000:01:00.0 em1: NIC Copper Link is Up, 1000 Mbps full duplex
[ 12.988454] bnx2 0000:01:00.1 em2: NIC Copper Link is Up, 1000 Mbps full duplex
Noyau 5.11, le réseau ne fonctionne pas car em1 et em2 sont introuvables :
[ 2.947141] bnx2 0000:01:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d4:ae:52:ce:c5:c7
[ 2.978902] bnx2 0000:01:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d4:ae:52:ce:c5:c8
/etc/network/interfaces
auto em1.74
iface em1.74 inet static
[...]
iface em1.74 inet6 static
[...]
auto em2
iface em2 inet static
[...]
iface em2 inet6 static
[...]
Si le réseau ne fonctionne plus, c'est que les interfaces ont changées et sont maintenant eth0 et eth1. Dans le fichier /etc/network/interfaces la configuration n'a pas évoluée et est restée en em1 et em2 !
Je bascule la configuration de /etc/network/interfaces avec eth0 et eth1 :
auto eth0.74
iface eth0.74 inet static
[...]
iface eth0.74 inet6 static
[...]
auto eth1
iface eth1 inet static
[...]
iface eth1 inet6 static
[...]
Avec le noyau 5.11, tout est ok avec eth0 et eth1 :
[ 2.205286] bnx2 0000:01:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d4:ae:52:ce:c5:c7
[ 2.270052] bnx2 0000:01:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d4:ae:52:ce:c5:c8
[ 7.013505] bnx2 0000:01:00.1 eth1: using MSIX
[ 7.195388] bnx2 0000:01:00.0 eth0: using MSIX
[ 10.320555] bnx2 0000:01:00.0 eth0: NIC Copper Link is Up, 1000 Mbps full duplex
[ 10.320717] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 10.320849] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.74: link becomes ready
[ 11.902520] bnx2 0000:01:00.1 eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ 11.902666] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
La ligne bnx2: QLogic bnx2 Gigabit Ethernet Driver v2.2.6 (January 29, 2014) n’apparaît plus avec le noyau 5.11 mais cela n’empêche pas le fonctionnement.
Tentative de repasser sur le noyau 5.4 pour voir si la configuration réseau fonctionnera, mais non. Les interface réseau n'ont définitivement pas le même nom selon le noyau sélectionné au boot.
Noyau 5.4, le réseau est ko :
[ 2.953540] bnx2: QLogic bnx2 Gigabit Ethernet Driver v2.2.6 (January 29, 2014)
[ 2.970762] bnx2 0000:01:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d4:ae:52:ce:c5:c7
[ 3.032210] bnx2 0000:01:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d4:ae:52:ce:c5:c8
-
Depuis le changement du système de nommage des cartes réseaux pour avoir un nom "stable" des interfaces, j'ai beaucoup plus d'instabilités que quand les noms étaient simplement "ethX"... Que ce soit sur du debian ou du ubuntu.
Sur des VMs, je passe d' "enpXsY" à "enoX" en les changeant d'hyperviseurs, pour l'instant pas eu ce bug lors de mises à jours kernel (heureusement!), sur mon PC fixe dual boot Windows/Linux, dès que je lance Windows et que je repars sur Linux ou même juste quand Linux fait une update du kernel, je change aussi de "enpXsY" à "enoX" et inversement.
C'est très usant car à chaque fois je perds le réseau et je dois reconfigurer le bon nom de la carte dans mes confs. ça me rassure de voir que je ne suis pas le seul à voir ce bug, je me demande quand va-t-il être résolu définitivement... Ce nouveau système de nommage est très sympathique en théorie mais dans la pratique ça n'est pas très stable et c'est source de nombreux problèmes...
-
J'ai cherché voir si le bug était remonté, mais on voit pleins de remontée de changement de nom d'interface.
Exemple d'une qui est bien documentée et qui explique la source du problème : https://access.redhat.com/solutions/2592561
Ma peur est que le nom des interface soit rétabli dans une prochaine mise à jour de systemd. J'hésite à doubler ma configuration réseau avec les deux nom d'interfaces (eth0 et em1 , eth1 et em2), sachant que les deux ne peuvent pas être actif simultanément.
-
Tu as changé qqch dans grub ?
Que dit la ligne GRUB_CMDLINE_LINUX_DEFAULT ?
-
Non, je n'ai pas touché à la configuration réseau ou à Grub
cat /etc/default/grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
Pour SystemD, je n'ai touché qu'à une chose : réactiver le Watchdog matériel, la mise à jour ayant remis le fichier de sa version par défaut avec watchdog désactivé.
sed -i -e "s/#RuntimeWatchdogSec=0/RuntimeWatchdogSec=120/g" /etc/systemd/system.conf
sed -i -e "s/#ShutdownWatchdogSec=10min/ShutdownWatchdogSec=10min/g" /etc/systemd/system.conf
Vérification : sed -e '/^#\|^$/d' /etc/systemd/system.conf
[Manager]
RuntimeWatchdogSec=120
ShutdownWatchdogSec=10min
Surtout les changements de noyaux se sont fait une fois que j'avais terminé de tout configuré.
-
Le problème de renommage des interfaces réseau, je le connaissais, et il est documenté chez Proxmox. Mais cela ne me semble pas être le problème ici, où tout simplement avec des cartes 4 ports, 2 10 Gb, et deux 1 Gb, celles 1 Gb disparaissent de ce qui est détecté, d'après ce que j'ai lu.
-
Ce n'est pas un bug. C'est systemd qui change.
Pour pas s'emmerder, il faut juste manuellement configurer le nom des interfaces.
Exemple dans /etc/systemd/network/10-eth0.link:
[Match]
MACAddress=00:11:22:33:44:55
[Link]
Name=eth0
Match contre l'adresse MAC, facile. Puis on donne un nom à l'interface.
-
Merci pour l'astuce @cali, je me la note !
-
Une astuce de cali-té :P
-
Attention, le renommage des noms des interfaces n'est pas un bug, mais une "feature" de systemd. Par contre, la disparition de deux interfaces des cartes Broadcom bnx2 semble bien être un bug, lié d'après ce que je venais de voir, à SRV-IO dans le BIOS.
-
A noter que Netplan (je ne l'utilise pas sur ce serveur), le réseau est capable de fonctionner quand le nom de l'interface ne correspond pas.
Sur un PC tournant avec Ubuntu server 20.04 (kernel 5.11) avec enp3s0 comme interface réseau, j'ai cette configuration de netplan :
cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
ethernets:
enp3s0:
optional: true
dhcp4: true
dhcp6: false
version: 2
voici ip addr :
$ ip addr
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: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c0:3f:d5:64:e8:d6 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.19/24 brd 192.168.0.255 scope global dynamic enp3s0
valid_lft 86357sec preferred_lft 86357sec
inet6 fe80::c23f:d5ff:fe64:e8d6/64 scope link
valid_lft forever preferred_lft forever
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ac:7b:a1:94:a0:6b brd ff:ff:ff:ff:ff:ff
Dmesg :
$ dmesg | grep r8169
[ 1.902676] libphy: r8169: probed
[ 1.923621] r8169 0000:03:00.0 eth0: RTL8168g/8111g, c0:3f:d5:64:e8:d6, XID 4c0, IRQ 93
[ 1.926442] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 2.006354] r8169 0000:03:00.0 enp3s0: renamed from eth0
[ 10.312317] Generic FE-GE Realtek PHY r8169-300:00: attached PHY driver (mii_bus:phy_addr=r8169-300:00, irq=MAC)
[ 10.512329] r8169 0000:03:00.0 enp3s0: Link is Down
[ 13.461583] r8169 0000:03:00.0 enp3s0: Link is Up - 1Gbps/Full - flow control rx/tx
J'ai utilisé une option de Grub pour que l'interface ne soit pas renommée :
sudo nano /etc/default/grub
J'ai rajouté net.ifnames=0 biosdevname=0 sur la ligne GRUB_CMDLINE_LINUX :
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
sudo update-grub
sudo reboot
Dmesg :
$ dmesg | grep r8169
[ 1.826413] libphy: r8169: probed
[ 1.834133] r8169 0000:03:00.0 eth0: RTL8168g/8111g, c0:3f:d5:64:e8:d6, XID 4c0, IRQ 91
[ 1.839497] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 9.827499] Generic FE-GE Realtek PHY r8169-300:00: attached PHY driver (mii_bus:phy_addr=r8169-300:00, irq=MAC)
[ 9.999571] r8169 0000:03:00.0 eth0: Link is Down
[ 12.918463] r8169 0000:03:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Malgré cela, netplan configure sans aucun problème le réseau. "altname enp3s0" apparaît dans ip addr, c'est lui qui a du être utilisé :
$ ip addr
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c0:3f:d5:64:e8:d6 brd ff:ff:ff:ff:ff:ff
altname enp3s0
inet 192.168.0.19/24 brd 192.168.0.255 scope global dynamic eth0
valid_lft 85980sec preferred_lft 85980sec
inet6 fe80::c23f:d5ff:fe64:e8d6/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ac:7b:a1:94:a0:6b brd ff:ff:ff:ff:ff:ff
altname wlp2s0
-
J'ai encore un cas où systemd change le nom des interfaces réseau !
Là ce n'est pas un vieux serveur comme celui de LaFibre.info, mais un système récent et la carte est une carte 2x 25 Gb/s, une Mellanox Technologies MCX4421A-ACQN ConnectX-4 Lx EN OCP,2x25G.
- Avec le noyau linux 5.4 :
mlx5_core 0000:c1:00.0 enp193s0f0: renamed from eth0
mlx5_core 0000:c1:00.1 enp193s0f1: renamed from eth1
- Avec le noyau linux 5.11 : np0 est ajouté au nom déjà long pour le port 0 et np1 pour le port 1
mlx5_core 0000:c1:00.0 enp193s0f0np0: renamed from eth0
mlx5_core 0000:c1:00.1 enp193s0f1np1: renamed from eth1
Dans les deux cas, c'est Ubuntu 20.04, j'ai juste demandé à avoir le kernel HWE pour avoir un noyau plus récent.
-
La convention de nommage systemd : https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
Les "np0" et "np1" viennent de https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184, le kernel a donc renseigné phys_port_name avec "p0" ou "p1".
A partir du kernel 5.2, il y a https://github.com/torvalds/linux/commit/af3836df9a59e7339d60c9c46729a7d9094d0582 qui construit un phys_port_name à partir du devlink_port.
Et le changement final qui a activé tout ça pour cette carte est arrivé avec le kernel 5.7 : https://github.com/torvalds/linux/commit/c6acd629eec754a9679f922d51f90e44c769b80c#diff-0da1e572ba1380c2e2ac04d8a1b05a903415d16a99cc07bcdaa1497a7c0d690aR17
Le port est déclaré avec le numéro de fonction PCI, qui est déjà utilisée pour "f0"/"f1", d'où le changement de nom avec l'information dupliquée.
Ça semble un peu bizarre, mais depuis peu le driver semble supporter des cartes qui n'ont pas la notion de fonction PCI : https://github.com/torvalds/linux/commit/1021d0645d593ea86193c5fc371e33e5b208e14d
Dans ce cas, il n'y aura probablement pas de f0/f1, et donc les np0/np1 sont importants.
Je me demande si dans systemd le numéro de fonction ne pourrait pas être ignoré quand il y a un nom de port renseigné, mais ça ne changerait pas le fait que des changements dans les drivers peuvent, potentiellement involontairement, modifier le nom des interfaces.
-
J'ai encore eu un serveur sous Ubuntu server 20.04 où l'interface a changé de nom, mais chose nouvelle cela eu lieu suite à un reboot où le noyau n'avait pas changé (5.4.0-144-generic avant reboot et aprés reboot, le reboot était pour vérifier que Ookla serveur se lance au redémarrage du serveur, sans aucun lien avec une évolution du noyau).
La carte réseau en question :
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet
Flags: bus master, fast devsel, latency 0, IRQ 16
I/O ports at e000 [size=256]
Memory at f0004000 (64-bit, prefetchable) [size=4K]
Memory at f0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Kernel driver in use: r8169
Kernel modules: r8169
Nom de l'interface réseau à l'origine : p4p1
Nom de l'interface réseau après reboot : eth0
Le changement du nom de la carte dans /etc/network/interfaces a été fait à t=8406 sec dans le dmesg ci-dessous :
$ dmesg | grep r8169
[ 0.972612] r8169 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 0.977987] r8169 0000:02:00.0 eth0: RTL8168evl/8111evl, 90:2b:34:61:18:d6, XID 2c9, IRQ 27
[ 0.981607] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 8406.955660] RTL8211E Gigabit Ethernet r8169-0-200:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-0-200:00, irq=IGNORE)
[ 8407.152092] r8169 0000:02:00.0 eth0: Link is Down
[ 8410.104052] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow control off
Bref, je pense que je vais forcer le nom de mes interfaces pour les serveurs qui n'utilisent pas Netplan.
-
Pour forcer le nom de l'interface, j'ai suivi la solution proposée par Cali.
Exemple avec un serveur qui possède 3 cartes réseau :
- 2x Broadcom NetXtreme II BCM5716 1000Base-T intégrées
- 1x Intel Ethernet Controller 10-Gigabit X540-AT2 sur carte PCI-Express
Situation avant : Les interfaces se nomment respectivement eno1, eno2 et enp1s0
# dmesg | grep -e ixgbe -e bnx2
[ 1.916830] bnx2 0000:02:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d0:67:e5:e9:ba:b4
[ 1.992674] bnx2 0000:02:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d0:67:e5:e9:ba:b5
[ 2.067633] bnx2 0000:02:00.0 eno1: renamed from eth0
[ 2.215307] bnx2 0000:02:00.1 eno2: renamed from eth1
[ 2.445372] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver
[ 2.459405] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
[ 2.825705] ixgbe 0000:01:00.0: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8 XDP Queue count = 0
[ 2.945325] ixgbe 0000:01:00.0: 32.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x8 link)
[ 3.072428] ixgbe 0000:01:00.0: MAC: 3, PHY: 0, PBA No: G54042-005
[ 3.072431] ixgbe 0000:01:00.0: a0:36:9f:31:81:5a
[ 3.220244] ixgbe 0000:01:00.0: Intel(R) 10 Gigabit Network Connection
[ 3.221260] ixgbe 0000:01:00.0 enp1s0: renamed from eth0
[ 17.912646] bnx2 0000:02:00.0 eno1: using MSIX
[ 21.021636] bnx2 0000:02:00.0 eno1: NIC Copper Link is Up, 1000 Mbps full duplex
Je crée 3 fichiers :
/etc/systemd/network/10-eth0.link
[Match]
MACAddress=d0:67:e5:e9:ba:b4
[Link]
Name=eth0
/etc/systemd/network/10-eth1.link
[Match]
MACAddress=d0:67:e5:e9:ba:b5
[Link]
Name=eth1
/etc/systemd/network/10-eth2.link
[Match]
MACAddress=a0:36:9f:31:81:5a
[Link]
Name=eth2
Ne pas oublier de modifier le fichier /etc/network/interfaces avant de redémarrer !
Situation après : Les interfaces sont renommées deux fois pour revenir avec le nom eth0, eth1 et eth2
# dmesg | grep -e ixgbe -e bnx2
[ 1.884979] bnx2 0000:02:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d0:67:e5:e9:ba:b4
[ 1.887897] bnx2 0000:02:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d0:67:e5:e9:ba:b5
[ 1.892101] bnx2 0000:02:00.0 eno1: renamed from eth0
[ 2.044372] bnx2 0000:02:00.1 eno2: renamed from eth1
[ 2.410280] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver
[ 2.410282] ixgbe: Copyright (c) 1999-2016 Intel Corporation.
[ 2.750480] ixgbe 0000:01:00.0: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8 XDP Queue count = 0
[ 2.852492] ixgbe 0000:01:00.0: 32.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x8 link)
[ 2.976427] ixgbe 0000:01:00.0: MAC: 3, PHY: 0, PBA No: G54042-005
[ 3.007609] ixgbe 0000:01:00.0: a0:36:9f:31:81:5a
[ 3.166265] ixgbe 0000:01:00.0: Intel(R) 10 Gigabit Network Connection
[ 3.167374] ixgbe 0000:01:00.0 enp1s0: renamed from eth0
[ 13.073045] bnx2 0000:02:00.0 eth0: renamed from eno1
[ 13.202516] bnx2 0000:02:00.1 eth1: renamed from eno2
[ 13.230700] ixgbe 0000:01:00.0 eth2: renamed from enp1s0
[ 19.624093] bnx2 0000:02:00.0 eth0: using MSIX
[ 22.814094] bnx2 0000:02:00.0 eth0: NIC Copper Link is Up, 1000 Mbps full duplex
Plus de risque de changement de nom à l'avnir !
-
J'ai vu une ou deux fois des serveurs dont les interfaces ont changé de nom après une mise à jour du BIOS ! Allez comprendre la prédictibilité de tout ce bazar. :) (en plus des noms à rallonge, du style enp13s14f0)
-
J'ai vu une ou deux fois des serveurs dont les interfaces ont changé de nom après une mise à jour du BIOS ! Allez comprendre la prédictibilité de tout ce bazar. :) (en plus des noms à rallonge, du style enp13s14f0)
Parfois une mise à jour de BIOS change l'ordre d'énumération des ports PCIe, ce qui change les noms d'interface générés.
J'ai encore eu un serveur sous Ubuntu server 20.04 où l'interface a changé de nom, mais chose nouvelle cela eu lieu suite à un reboot où le noyau n'avait pas changé (5.4.0-144-generic avant reboot et aprés reboot, le reboot était pour vérifier que Ookla serveur se lance au redémarrage du serveur, sans aucun lien avec une évolution du noyau).
[...]
Nom de l'interface réseau à l'origine : p4p1
Nom de l'interface réseau après reboot : eth0
"p4p1" ce n'est pas un nom systemd, ça ressemble à biosdevname (qui existait en 18.04, mais plus en 20.04).
Si le paquet était sur la machine, et a finalement été supprimé, ça peut expliquer la perte de ce nom.
Mais il devrait y avoir le renommage systemd, à moins qu'il soit désactivé (via un net.ifnames=0 sur la ligne de commande kernel ?).
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html indique qu'on peut obtenir des informations avec "udevadm test-builtin net_id /sys/class/net/eth0".
Sinon, http://changelogs.ubuntu.com/changelogs/pool/main/s/systemd/systemd_245.4-4ubuntu3.20/changelog indique "Add support for the v247 network naming scheme, but keep v245 as default".
C'est daté de septembre, mais la mise à jour n'a été poussée dans focal-updates qu'en novembre.
Ca reste plus ancien que le kernel 5.4.0-144-generic, mais début mars systemd-245.4-4ubuntu3.20 a été poussé dans focal-security, donc si le serveur applique uniquement les mises à jour de sécurité, alors c'est à ce moment là qu'il a mis à jour systemd.
Ils ont en pratique pris https://github.com/systemd/systemd/pull/17352, qui détecte des cas où il y a un bridge PCIe dans un slot hotplug (et donc les noms générés pourraient être identiques).
Je vois un éventuel risque de bug si hotplug_slot vaut 0, il y a eu des corrections plus tard : https://github.com/systemd/systemd/pull/19237/commits/19ed9a114c et https://github.com/systemd/systemd/pull/19237/commits/c304cb0146.
Mais ça affecte ID_NET_NAME_SLOT, pas ID_NET_NAME_PATH (et sauf si "net.ifname-policy" ou NamePolicy est changé quelque part, il devrait l'utiliser si le premier n'est pas disponible).
-
C'est un serveur installé avec Ubuntu server 15.04, en 2015. Il a depuis été mis à jour.
Cela explique la présence de biosdevname
J'ai regardé /etc/default/grub :
J'ai la ligne
GRUB_CMDLINE_LINUX=""
Pour empêcher systemd de renommer les interfaces (autre solution), il faudrait avoir
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"Ce n'est pas le cas.
Je ne sais pas ce qui bloque le renommage, d'où l'idée de forcer ça via un fichier /etc/systemd/network/10-eth0.link
-
Mais est-ce que biosdevname est toujours installé ?
S'il est là, normalement son renommage est prioritaire sur celui de systemd.
Le comportement de systemd est configuré par :
- /lib/systemd/network/99-default.link
- d'une manière générale tout *.link dans /lib/systemd/network ou /etc/systemd/network
-
biosdevname ne semble pas installé :
# apt list biosdevname
En train de lister... Fait
Comme il n'est plus pris en charge avec Ubuntu 20.04, il a dû être supprimé comme les autres paquets obsolètes.
Fichier /lib/systemd/network/99-default.link
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Match]
OriginalName=*
[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path
MACAddressPolicy=persistent
Fichier /lib/systemd/network/80-container-host0.network
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# This network file matches the container-side of the virtual Ethernet link
# created by systemd-nspawn's --network-veth switch. See systemd-nspawn(1) for
# details.
[Match]
Virtualization=container
Name=host0
[Network]
DHCP=yes
LinkLocalAddressing=yes
LLDP=yes
EmitLLDP=customer-bridge
[DHCP]
UseTimezone=yes
Fichier /lib/systemd/network/80-container-ve.network
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# This network file matches the host-side of the virtual Ethernet link
# created by systemd-nspawn's --network-veth switch. See systemd-nspawn(1) for
# details.
[Match]
Name=ve-*
Driver=veth
[Network]
# Default to using a /28 prefix, giving up to 13 addresses per container.
Address=0.0.0.0/28
LinkLocalAddressing=yes
DHCPServer=yes
IPMasquerade=yes
LLDP=yes
EmitLLDP=customer-bridge
Fichier /lib/systemd/network/80-container-vz.network
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# This network file matches the bridge interface created by systemd-nspawn's
# --network-zone= switch. See systemd-nspawn(1) for details.
[Match]
Name=vz-*
Driver=bridge
[Network]
# Default to using a /24 prefix, giving up to 253 addresses per virtual network.
Address=0.0.0.0/24
LinkLocalAddressing=yes
DHCPServer=yes
IPMasquerade=yes
LLDP=yes
EmitLLDP=customer-bridge
-
Mais peut être que biosdevname était installé au dernier boot (celui qui avait donné p4p1).
En tout cas, avec le 99-default.link, systemd devrait faire le renommage (sauf si quelqu'un d'autre comme biosdevname l'a fait avant, c'est la policy "keep").