Bennenung der NIC nach Kernelupgrade anders

[guennid]

es _MUSS_ irgendwie am Kernel liegen

Glaub' ich nicht. Der numeriert, soweit ich weiß eth* und wlan* durch, wie sie ihm gerade unter die Finger kommen. Den Käse mit e*/weiß nicht was fabriziert erst udev.

[KP97]

...die Koppelung des Schnittstellennamens an die Mac hat früher mal absolut zuverlässig funktioniert.

Das kann man auch mit systemd problemlos einrichten.
Ich hatte das in einem anderen Zusammenhang schon mal beschrieben, aber ich wiederhole es noch mal:
Unter /etc/systemd/network eine Datei anlegen. Bei mir heißt diese 60-kabel.link und hat diesen Inhalt

[Match]
MACAddress=dc:fe:07:e1:77:22

[Link]
Name=eth0

Wichtig ist die Endung .link, der Name ist ansonsten frei wählbar.
Der 99-default.link kann unverändert bleiben, die MAC-Adresse muß natürlich mit der eigenen überschrieben werden.
Damit kann der Name eindeutig der MAC zugeordnet sein.

[novalix]

...die Koppelung des Schnittstellennamens an die Mac hat früher mal absolut zuverlässig funktioniert.

Das kann man auch mit systemd problemlos einrichten.

Wenn man die Störungsszenarien vergleicht, die zu einer Umbenennung der NIC führen, dann müsste man heute vorsichtshalber per se eine Regel für jede Netzwerkkarte erstellen (egal ob udev oder systemd), um der möglichen Umbenennung aus dem Weg zu gehen. Der Austausch einer Netzwerkkarte ist was anderes als ein Upgrade des Kernels (schon allein, was den Einsatz von Schraubendrehern betrifft).

Natürlich finden solche Ereignisse nach wie vor sehr, sehr selten statt.
Wäre das anders, gehörte die Einrichtung fest zugeordneter Namen zur NIC zum kanonischen Pflichtteil bei der Servereinrichtung. Ein Punkt mehr, der abzuarbeiten ist.

Ich vermute mal, dass der absolute Löwenanteil an Serverinstallationen da draußen ohne dezidierte Regeln in Betrieb ist. Gemessen an der Häufigkeit des Auftretens des Störungsfalls ist das vollkommen verständlich.
Auf der anderen Seite ist das Katastrophenpotential eines solchen Ereignisses doch recht erheblich.
Ich kann gut verstehen, dass man der Designentscheidung auch gerne mal mit dem Stinkefinger winkt, wenn man die möglichen Konsequenzen erfährt.

[DeletedUserReAsG]

Das große Geheimnis ist ja, dass man tatsächlich die Zuordnung anhand der MAC zu einem selbst ausgewählten Namen mittels udev-Regeln festschreiben kann. Das hätte das hier vorliegende Problem dann auch vermieden.

Früher™ war die Zuordung nicht fest – war das gleiche Spiel, wie mit den Blockdevices (für die dann ja die UUIDs erfunden wurden): was der Kernel zuerst sieht, bekommt den ersten Namen. In der Regel hat sich nix geändert, solange man nix an der HW geändert hat (und auch kein BIOS-Update fuhr, etc.). Hat man was geändert, konnte es durchaus passieren, dass die Reihenfolgen durcheinander gerieten. Unter Debian gibt’s allerdings bereits sehr lange eine udev-Regel für die Netzwerkinterfaces – viel länger schon, als es systemd und Co. gibt – vielleicht ist’s den Usern hier deswegen nicht aufgefallen, dass es eigentlich™ keine feste Zuordnung gab? Hatte allerdings auch seine Tücken – hat man ein Interface etwa wegen Defekt gewechselt hat, bekam das neue Teil dann eth1, obwohl’s das einzige Interface in der Maschine war. Das Löschen der Regel hat’s dann gefixt, aber einige Threads gab’s durchaus deswegen, wenn ich mich nicht falsch erinnere.

[TomL]

Anscheinend funktioniert das wohl nicht immer so wie gedacht, siehe Threadstart

Nach einem massiven Eingriff in das Betriebssystem durch manuellen Austausch eines Kernels? Und das Hardware dann möglicherweise anders gehandhabt wird, eben auch durch systemd, weil der Kernel möglicherweise andere Infos rausgibt....das wundert Dich? Für mich ist das ein handgemachtes Problem... fast (mal so sarkastisch umschrieben) auf gleicher Ebene wie "wieso sind meine Daten alle weg? ich habe doch nur format c: gemacht". Solcherart tiefen Eingriffe in das Betriebssystem haben eben Auswirkungen... die können zum guten sein, oder eben auch nicht, oder auch einfach nur Paradigmen ändern.... ich betrachte das als völlig normal und bewerte es als Ergebnis von Weiterentwicklung.

Und wenn alles OK wäre , warum gibt es dann die Möglichkeit diesen Mechanismus rückgängig zu machen ?

Ich vermute die gleichen Beweggründe, mit denen auch die net-tools trotz iproute2 überleben. Oder die fstab überlebt mithilfe autogenerierter Mount-Units. Oder sudo überlebt trotz Polkit. Oder init.d-Script wegen autogenerierter Service-Units. Vermutlich deshalb, damit auch die zufriedengestellt werden, die unbedingt an älteren Standards festhalten wollen.

Und was hat an der Kopplung der MAC an den Netzwerkname nicht funktioniert, daß man sich genötigt sah, das ehemals sehr gut und absolut zuverlässige System zu ändern?

Das funktioniert doch immer noch.... kp97 und niemand haben 2 Wege aufgezeigt.... network.link und udev....also gibts auch hier nicht wirklich eine Verschlechterung zum Früher.

[guennid]

nach Upgrade auf den Backportkernel 4.19

Nach einem massiven Eingriff in das Betriebssystem durch manuellen Austausch eines Kernels?

ohne Worte.

Das Debian-Kernel-Image ist nun mal, ich glaube seit squeeze, via initrd abhänigig von udev ergo redhat (ok, das kam dann erst mit jessie - nicht ungeschickt). Da muss man schon ein paar Klimmzüge veranstalten, wenn man das los werden will - es geht aber (immer noch) - ist dann halt kein „zeitgemäßes“ Rundum-sorglos-System mehr.

[MSfree]

Das funktioniert doch immer noch.... kp97 und niemand haben 2 Wege aufgezeigt.... network.link und udev....also gibts auch hier nicht wirklich eine Verschlechterung zum Früher.

Es funktioniert aber nicht mehr vollautomatisch, sondern bedingt manuelles Anlegen dieser Link-Dateien. Das würde ich dann doch als Verschlechterung sehen wollen.

[Colttt]

scheint wohl am Treiber/Kernel zu liegen..

https://bugs.debian.org/cgi-bin/bugrepo ... bug=929622

[guennid]

Ich lese das genau anders rum, bzw so, wie schon eingangs genannt: udev ist dafür verantwortlich (das systemd- können wir uns sparen, alldieweil's mittlerweile kein anderes udev als systemd-udev gibt):

Code: Alles auswählen

These names are generated by systemd-udevd, although they are based on
information from the kernel.

Looking at the system-udevd source code, it appears that the extra
"np0" is derived from a new "phys_port_name" attribute of the network
device, which the bnxt_en driver added support for in Linux 4.14.

It looks like this is required for switchdev functionality, so I don't
think this change is going to be reverted.

Bei mehreren NICs der gleichen Art würde ich niemands Rat folgen und in einer udev-Regel einen selbstgewählten Namen an die jeweilige MAC-Adresse des Gerätes binden.

[RobertS]

Die MAC Adresse ist ja per Software änderbar, um eine Karte in einen anderen Slot zu stecken brauch ich schon physischen Zugriff auf die Maschine. Von daher taugt die MAC, meiner Meinung nach, nicht zur eindeutigen, dauerhaften Kennzeichnug einer Schnittstelle.

[DeletedUserReAsG]

Die MAC Adresse ist ja per Software änderbar

Ja, allerdings erst nach dem Booten. Da die Benennung während des Bootens läuft, halte ich das für nicht relevant. Wenn du allerdings ’ne Möglichkeit kennst, den physischen Port zur Benennung heranzuziehen, wird das auch nicht schlecht sein. Außer bei USB- oder ähnlichen Interfaces.