udev benennt mein Netzwerkinterface um

[hupfdule]

Hallo,

habe hier ein Debian Wheezy, das als Gast in einer VMWare-VM läuft.
Bisher hatte ich da 2 Netzwerkinterface drin, eines als eth0, das andere als eth1. Nun habe ich ein weiteres hinzugefügt, das jedoch ständig von udev umbenannt wird:

udevd[3535]: renamed network interface eth2 to rename5

Penetranterweise kriegt das Ding auch noch jedes mal eine andere Bezeichnung (mal rename5, mal rename6, mal rename7, …).


Wie kann ich diesen Unfug vermeiden? Die Bezeichnung eth2 ist doch bereits eindeutig im System. Was ist der Grund für das Umbenennen?

[smutbert]

udev merkt sich (anhand der MAC) den erstmals vergebenen Namen eines Interfaces und benennt die Interfaces wieder danach um. (Der Kernel vergibt die Namen nicht unbedingt bei jedem Start in der gleichen Reihenfolge)

Damit sich beim Umbenennen die Namen nicht ins Gehege kommen vergibt udev eventuell vor den richtigen Namen temporäre Namen — zumindest wäre das meine Vermutung, aber ich habe keine Idee, wieso udev es dann bei den temporären Namen belässt.

Den Umbenennungsspuk kann man zB mit einem symbolische Link von /etc/udev/rules.d/70-persistent-net.rules → /dev/null (Datei vorher löschen oder umbenennen) deaktivieren, aber dann ist man auch die vorhersagbaren Namen für die Interfaces los.
Steht in der /etc/udev/rules.d/70-persistent-net.rules jetzt vielleicht irgendetwas unsinniges drin?

[guennid]

Also, dass udev das Suffix "x" von ethx verändert, ist wohl gängige Praxis bei udev, aber dass auch der Stamm "eth" geändert wird, habe ich noch nicht gesehen.

Grüße, Günther

[KBDCALLS]

Hier hats geholfen die Datei /etc/udev/rules.d/70-persistent-net.rules zu löschen.

Eine andere Lösung indem die Macadressen ändert. Ist zwar für Centos sollte aber auch bei Debian funktionieren.

[smutbert]

@guennid
Naja irgendsoetwas muss udev ja machen. Nehmen wir an es gäbe nur zwei Interfaces A und B. A soll eth0 heißen und B eth1. Wenn der Kernel jetzt B zuerst erkennt, erhält B den Namen eth0 und A den Namen eth1.
Nun kann udev B nicht direkt in eth1 umbenennen, weil der Name bereits von A belegt wird und genausowenig kann es A in eth0 umbenennen. Also muss er etwas in der Art machen:

- benenne eth0 in rename1 um
- benenne eth1 in eth0 um
- benenne rename1 in eth1 um

und wie es der Zufall will, findet man genauso etwas in der Art zB hier

Code: Alles auswählen

# dmesg
...
udev: renamed network interface eth1 to rename3
udev: renamed network interface eth0 to eth1
udev: renamed network interface rename3 to eth0
...

Quelle

Bleibt nur noch die Frage warum udev bei hupfdule bei diesem renameX-Namen „hängen“ bleibt. Deshalb habe ich ja auch nach dem Inhalt der /etc/udev/rules.d/70-persistent-net.rules gefragt…

Löschen funktioniert natürlich auch, wenn der Fehler dort liegt, sie wird dann einfach neu angelegt — allerdings kann ich in KBDCALLS (erstem) Link nicht dasselbe Problem erkennen, dort bekommen die Interfaces einfach nur andere Namen, weil sich die Hardware und damit die MAC-Adressen (egal ob real oder virtuell) geändert haben.

[hupfdule]

Steht in der /etc/udev/rules.d/70-persistent-net.rules jetzt vielleicht irgendetwas unsinniges drin?

Code: Alles auswählen

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:6b:66:3c:c8", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Ob das unsinnig ist, kann ich nicht beurteilen. Die dor zu findende MAC-Adresse ist die, die das Interface nun hat. Allerdings ist es nicht die, die ich in VMWare dafür angegeben habe.
Ich werde es mal mit Löschen der Datei versuchen und schauen, was dabei rauskommt.

[guennid]

Nun kann udev B nicht direkt in eth1 umbenennen, weil der Name bereits von A belegt wird und genausowenig kann es A in eth0 umbenennen.

Soweit klar und sinnvoll, nur ist das, wenn ich nicht irre, nicht das, worum es hier geht: hupfdule hat dem System zu den zwei vorhandenen ein neues Ethernet-Device hinzugefügt. Ich hätte erwartet, dass unser geheimnisvolleses udev jetzt irgendwie mit eth0 bis eth2 operierte - jedenfalls habe ich ich das bisher so erlebt im Falle eines neuen Devices.

Grüße, Günther

[hupfdule]

hupfdule hat dem System zu den zwei vorhandenen ein neues Ethernet-Device hinzugefügt. Ich hätte erwartet, dass unser geheimnisvolleses udev jetzt irgendwie mit eth0 bis eth2 operierte -

Das hat es offenbar auch getan. Denn im Logfile sieht man, dass das Device von eth2 nach rename5 umbenannt wurde. eth2 ist ein weiterhin freier Name. Warum anschließend noch ein rename erfolgt, ist mir nicht klar.

[guennid]

Schuss in's Blaue: Vielleicht spielt die Virtualität des wheezy eine Rolle?

Grüße, Günther

[hupfdule]

Schuss in's Blaue: Vielleicht spielt die Virtualität des wheezy eine Rolle?

Davon gehe ich aus. Einen Grund dafür weiß ich dennoch nicht.

Nichtsdestotrotz: Das Löschen der /etc/udev/rules.d/70-persistent-net.rules hat es offenbar gebracht.