Heute habe ich einen meiner Lenovo-„Server“ ausgetauscht: T400 raus, T420 rein. Dabei habe ich die SSD vom alten Server in den neuen Server eingebaut — bei Windows ein Ding der Unmöglichkeit, bei Linux: Läuft bei mir (fast).

Leider gab es ein gravierendes Problem, was die Downtime etwas verlängert und an meinem Ehrgeiz gekratzt hat: Die Netzwerk-Interfaces kamen nicht hoch, weshalb das Gerät ohne Intra- und Internet-Verbindung dastand.

Dank Laptop-Tastatur und -Bildschirm fiel immerhin das Debugging leicht.

Die Ausgabe von ifconfig zeigte, dass nur das Loopback-Interface vorhanden war. Was zum Teufel? Den Ethernet-Netzwerkanschluss sah ich mit meinen eigenen Augen vor mir, ein Kabel war eingesteckt und er blinkte auch fröhlich vor sich hin.

# ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 184819  bytes 33744666 (32.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 184819  bytes 33744666 (32.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Mit dem Befehl ip a dann die Gewissheit, dass die erwarteten Schnittstellen auch tatsächlich da waren:

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.10/24 brd 10.10.10.255 scope global enp1s0
       valid_lft forever preferred_lft forever
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Wie sich herausstellte, hiess auf dem T420 die Netzwerkschnittstelle nicht wie erwartet und üblich eth0, sondern enp1s0.

Der Grund (bitte nicht lachen): Predictable Network Interface Names. Verursacht durch die Datei /etc/udev/rules.d/70-persistent-net.rules, welche bei der Installation auf dem T400 erstellt worden war. Linux fand die darin definierten Interfaces auf dem T420 nicht mehr.

Die Lösung des Problems fand sich in einem Benutzerforum zum Thema How to rename network interface in 15.10?.

An der Originaldatei …

...
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="11:11:11:11:11:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
...

… nahm ich folgende Anpassung vor:

...
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:00:00:00:00:00", NAME="eth0"
...

Wichtig: 11:11:11:11:11:11 ist die MAC-Adresse des Ethernet-Interfaces auf dem T400, 00:00:00:00:00:00 ist die MAC-Adresse des Ethernet-Interfaces auf dem T420. Als ich zuerst nur die MAC-Adresse geändert habe, kam die Netzwerkschnittstelle nicht hoch. Erst die Verschlankung des Eintrags auf die obige Form funktionierte: Nach dem nächsten Reboot war eth0 wieder vorhanden und alle Netzwerkdienste kamen hoch.

Nachtrag

Die Herleitung des kryptischen Namens ist hier erläutert: Why is my ethernet interface called enp0s10 instead of eth0?.

enp1s0 bedeutet also:

• en Ethernet
• p1 Bus (hier: 1)
• s0 Slot (hier: 1)

Nachtrag 2

Auf einem jungfräulichen Debian 11 Bullseye System musste ich gestern /etc/udev/rules.d von Hand erstellen.

Dementsprechend fehlte auch /etc/udev/rules.d/70-persistent-net.rules. Obwohl im Internet stand, dass man mit dem Befehl

# /lib/udev/write_net_rules

die benötigte Datei erstellen könne, fehlt auf meinem System dieser Befehl (ich konnte das Script auch in keinem Debian-Paket finden — komisch). Ich erstellte deshalb /etc/udev/rules.d/70-persistent-net.rules kurzerhand von Hand, startete das System neu, und es funktionierte.

Übrigens: Die Verwendung deterministischer Interface-Namen könnte man auch mit einem Kernelbefehl in /etc/sysctl.conf verhindern: net.ifnames=0