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.es _MUSS_ irgendwie am Kernel liegen
Bennenung der NIC nach Kernelupgrade anders
Re: Bennenung der NIC nach Kernelupgrade anders
Re: Bennenung der NIC nach Kernelupgrade anders
Das kann man auch mit systemd problemlos einrichten.MSfree hat geschrieben:27.05.2019 11:23:38...die Koppelung des Schnittstellennamens an die Mac hat früher mal absolut zuverlässig funktioniert.
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
Wichtig ist die Endung .link, der Name ist ansonsten frei wählbar.[Match]
MACAddress=dc:fe:07:e1:77:22
[Link]
Name=eth0
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
- Beiträge: 1909
- Registriert: 05.10.2005 12:32:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: elberfeld
Re: Bennenung der NIC nach Kernelupgrade anders
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.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.
Darum ist das Richtige selten, lobenswert und schön.
Re: Bennenung der NIC nach Kernelupgrade anders
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.
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.
Re: Bennenung der NIC nach Kernelupgrade anders
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.KBDCALLS hat geschrieben:27.05.2019 13:13:54Anscheinend funktioniert das wohl nicht immer so wie gedacht, siehe Threadstart
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.KBDCALLS hat geschrieben:27.05.2019 13:13:54Und wenn alles OK wäre , warum gibt es dann die Möglichkeit diesen Mechanismus rückgängig zu machen ?
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.MSfree hat geschrieben:27.05.2019 13:14:59Und 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?
Re: Bennenung der NIC nach Kernelupgrade anders
Colttt hat geschrieben:nach Upgrade auf den Backportkernel 4.19
ohne Worte.TomL hat geschrieben:Nach einem massiven Eingriff in das Betriebssystem durch manuellen Austausch eines Kernels?
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.
Zuletzt geändert von guennid am 28.05.2019 20:37:48, insgesamt 1-mal geändert.
Re: Bennenung der NIC nach Kernelupgrade anders
Es funktioniert aber nicht mehr vollautomatisch, sondern bedingt manuelles Anlegen dieser Link-Dateien. Das würde ich dann doch als Verschlechterung sehen wollen.TomL hat geschrieben:27.05.2019 20:41:13Das 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.
Re: Bennenung der NIC nach Kernelupgrade anders
Debian-Nutzer
ZABBIX Certified Specialist
ZABBIX Certified Specialist
Re: Bennenung der NIC nach Kernelupgrade anders
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):
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.
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.
- RobertS
- Beiträge: 512
- Registriert: 15.04.2012 13:50:53
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Rastatt BaWü
Re: Bennenung der NIC nach Kernelupgrade anders
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.
Re: Bennenung der NIC nach Kernelupgrade anders
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.