Posts Tagged ‘udevd’

Samstag, 14. Oktober 2017

Wenn eth0 plötzlich enp1s0 oder ähnlich kryptisch heisst

Link zu diesem Artikel

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

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 16. September 2014

udevd meldet „invalid rule“

Link zu diesem Artikel

In /etc/udev/rules.d/10-local.rules stand bei mir Folgendes:

BUS=="usb", KERNEL=="sd?1", ATTR{manufacturer}=="LaCie*", NAME="%k", SYMLINK+="usbhdd1"

Mit einem der udev-Updates der letzten Jahre scheint sich die Notation solcher Regel etwas geändert zu haben, weshalb beim Boot-Prozess meines Linux-Servers kurzzeitig eine Fehlermeldung aufflackerte:

udevd[xxx]: invalid rule '/lib/udev/rules.d/10-local.rules:1'

Das Debugging solcher Fehlermeldungen und Regeln ist ganz einfach — wenn man weiss wie.

Auf der Kommandozeile führt man folgenden Befehl aus:

# udevadm test /etc/udev/rules.d/10-local.rules
load module index
read rules file: /etc/udev/rules.d/10-local.rules
unknown key 'BUS' in /etc/udev/rules.d/10-local.rules:1
invalid rule '/etc/udev/rules.d/10-local.rules:1'
...

Quelle: Debugging udev rules

Und siehe da, heute scheint das neu folgendermassen zu heissen:

SUBSYSTEM=="usb"

Nach der Änderung prüft man die Syntax erneut:

# udevadm test /etc/udev/rules.d/10-local.rules
load module index
read rules file: /etc/udev/rules.d/10-local.rules
unknown key 'SYSFS{manufacturer}' in /etc/udev/rules.d/10-local.rules:1
invalid rule '/etc/udev/rules.d/10-local.rules:1'
...

Aha, heute heisst das offenbar:

ATTR{manufacturer}

… und ab sofort motzt udevd nicht mehr rum:

# udevadm test /etc/udev/rules.d/10-local.rules
load module index
read rules file: /etc/udev/rules.d/10-local.rules
read rules file: /lib/udev/rules.d/42-usb-hid-pm.rules
...

Der Abend ist gerettet.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen