Machen alte Netzwerknamen Probleme?

[AlexDausF]

Hallo Forum,

ich möchte meinen PC von Stretch nach Buster updaten. Dabei ist mir dieser Hinweis aufgefallen:
https://www.debian.org/releases/stable/ ... face-names
Wie kann ich die Netzwerknamen umbiegen? Diese Anleitung kann ich leider nicht ganz nachvollziehen. Wo genau muss ich die Netzwerkarte neu benennen? Würde mich freuen wenn jemand die Vorgehensweise nochmal erläutert.
Wenn es für ein gelungenes Update gar nicht nötig ist die Namen zu ändern, bitte auch Bescheid geben.
Besten Dank!
Alex

[MSfree]

Wie kann ich die Netzwerknamen umbiegen?

Der neuere Kernel sorgt für die neuen Netzwerkbezeichnungen.

Es kommt letztlich darauf an, wie dein Netzwerk konfiguriert ist. Wenn das Netzwerk unter Stretch mittel /etc/network/interfaces konfiguriert hast, dann mach einfach das Update, log dich danach an der Konsole ein und passe /etc/network/interfaces an. Dazu muß du rausfinden, wie die Netzwerkkarte(n) unter Buster heißen (ip a) und dann in /etc/network/interfaces eth0 und/oder wlan0 durch das ersetzen, das ip a geliefert hat.

Wenn das Netzwerk mit dem networkmanager konfiguriert wurde, brauchst du vermutlich nchts zu tun, ausser das WLAN neu anmelden.

Alternativ kannst du den Kernel zwingen, keine neuen Nwetzwerknamen zu vergeben, dann bleibt alle beim alten.

[wanne]

Systemd hat den udev verkrüppelt um die Leute zum Nutzen von systemd zu zwingen. Debian hat sich relativ lange geweigert auf die systemd Variante mit weniger Umfang upzudaten wollte aber auch nicht auf die externen forks von gentoo und Co. umsteigen.
Jetzt haben sie das update wohl doch durchgeführt. Damit wird udev die Datei nicht mehr lesen können in der steht wie welches Interface heißt:
/etc/udev/rules.d/70-persistent-net.rules
=> Die interfaces heißen jetzt anders wie dort konfiguriert.
Du kannst sie mal kurzzeitig entfernen und neu starten und gucken was kaputt geht, weil du in irgend welche configs die alten Namen geschrieben hast. – Und eventuell mit den neuen einrichten. Oder einfach das Update durchziehen und dich dann um eventuelle Probleme kümmern. IMHO die einfachere Variante.
Nutzt du systemd-networkd kannst du auch von Hand konfigurieren, wie gewisse Interfaces heißen sollen:

Code: Alles auswählen

cat /etc/systemd/network/eth0.link
 [Match]
 MACAddress=01:de:ad:be:ef:13

 [Link]
 Name=eth0

Damit kannst du dann die passenden Namen wieder exakt gleich vergeben wie zuvor. Wie gesagt: Dafür muss aber systemd-networkd laufen.

[AlexDausF]

Hallo!
Vielen Dank für Eure Hinweise! Ich finde keine Einträge in

/etc/udev/rules.d
/etc/network/interfaces

Nur in /etc/network/interfaces.d/setup steht:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

Vielleicht würde das bei dem Upgrade einfach umgestellt werden. Ich will nur nicht das Netz verlieren im Verlauf des Upgrades!

Besten Dank!
Alex

[wanne]

Wenn geht es eh erst nach dem reboot kaputt. Dann musst du halt das eth0 in der /etc/network/interfaces durch den neuen namen austauschen. Debian hat aber wohl auch noch ein paar Wrapper gebaut, die dafür sorgen, dass in den meisten Fällen gar nichts passiert.
Ansonsten kannst du wie in der Anleitung empfohlen Die Datei /etc/udev/rules.d/70-persistent-net.rules löschen und rebooten. Dann bekommst du direkt den neuen Namen und kannst die /etc/network/interfaces vor dem update anpassen.
Als letzte Alternative kannst du die genannte Datei für den networkd anlegen.

[willy4711]

Ich habe auf meinem Laptop ein ca. 5 Jahre alte Installation (Testing Xfce) . War ursprünglich SparkyLinux, die Repos und alle Pakete sind seit langer Zeit gepurgt.
Dort existieren von Anfang an eth0 wlan0 wlan1 ohne dass es jemals Probleme gab.
Hab mich nie weiter darum gekümmert, da es einfach läuft.

[fischig]

Dort existieren von Anfang an eth0 wlan0 wlan1 ohne dass es jemals Probleme gab.
Hab mich nie weiter darum gekümmert, da es einfach läuft.

Hier genauso, man muss allerdings udev verbieten, die Namen umzubenennen. Was den Systemdlern jetzt Neues eingefallen ist(?), weiß ich nicht. Bis Buster habe ich - auch mit systemd - nichts bemerkt und auf der bullseye-Testmaschine ist systemd nicht installiert.

[wanne]

Also ich weiß nicht weiß nicht, was ihr mit umbenennen meint. Der kernel übergibt seit grauer Vorzeit (mindestens lenny) seine Interfaces an udev, dass sich dann einen Namen dafür ausdenkt. Von real umbenennen kann nicht die rede sein, weil udev den Namen erst aus den Eigenschaften die ihm der Kernel erstellt.
Ursprünglich mal per default in dem es schlicht den subsystemtyp genommen und dann durchnummeriert hat.
Hat das Problem, dass die Nummerierung dann von der Reihenfolge in der die Geräte angeschlossen wurden abhängt. (Insbesondere beim Boot wo alle Gelichzeitig da sind bei gleichem Typ nicht vorhersehbar ist, welches als erstes erkannt wird.) Deswegen hat Debian ebenfalls schon seit Ewigkeiten udev per udev-Rule angewiesen ein device dass es ein mal gesehen hat in Zukunft gleich zu benennen.
Mit jessie glaube ich hat udev dann angefangen seine Devices per default in (bei vernünftig geschriebenen Treibern und gebauter Hardware...) vorhersehbare Namen zu verwenden. Defakto kodieren die in den Namen, wo das Ding angeschlossen ist. Bleibt es an der gleichen Stelle behält es den selben Namen. Debianuser hat das wenig gejuckt, weil Debian ja schon ewig einen Fix hatte. Seit stretch läuft debian den doppelweg: Neue Interfaces werden nach der nativen udev-default-Benamsung für alte blieben die Debian-Spezifischen udev-Regeln.
Gleichzeitig hat Systemd und hat udev geschluckt und brachte mit networkd ein eigens Tooling zum Umbennennen von Devices mit. Systemd hatte dann plötzlich zwei arten der Benennung von network-Interfaces udev und networkd. Und die Systemdler mögen es gar nicht, wenn es 2 unterschiedliche Wege für irgend was gibt. Schon gar nicht wenn die dann auch noch kompatibel zu anderen init-Systemen (OpenRC/SystemV) wären.
Da hat man schon lange angekündigt, die udev Variante zu killen womit die Debian-Regeln nicht mehr funktionieren. Das scheint seit einer Weile für die ersten paar subsysteme der Fall zu sein. Ich meine aber irgend wo gelesen zu haben, dass Debian da in buster wohl nach gepatched hat um die Funktionalität zu erhalten. Damit ist jetzt wohl Schluss. Wenn systemd den support für die Regeln die Debian vor stretch angefertigt hat fallen lässt, wird auch Debian das nicht mehr patchen.
Für die üblichen GBit-Karten (eth*) dürfte das noch nicht der Fall sein. Es ist aber natürlich fraglich, wie das mit dem nächsten Release aussieht.

[fischig]

Also ich weiß nicht weiß nicht, was ihr mit umbenennen meint.

Und wie ist dann die Meldung beim Einstecken einer USB-Karte zu verstehen:

Code: Alles auswählen

enx[*] renamed from eth1

? Da kein systemd läuft, muss udev das veranstaltet haben - denke ich mal.

[willy4711]

Ich hab dann wohl was "ganz spezielles". Grad mal wieder mein USB-LAN angesteckt:
Da wird nix umbenant.
Zur Aufklärung: eth0 ist der eingebaute NIC, der aber ab und zu spinnt. --> deshalb eth1 via USB.

Code: Alles auswählen

 udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[37.141471] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4 (usb)
KERNEL[37.147839] change   /devices/pci0000:00/0000:00:14.0/usb1/1-4 (usb)
KERNEL[37.148892] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0 (usb)
KERNEL[37.149108] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-4 (usb)
UDEV  [39.010386] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4 (usb)
UDEV  [39.013010] change   /devices/pci0000:00/0000:00:14.0/usb1/1-4 (usb)
KERNEL[39.021500] add      /module/mii (module)
UDEV  [39.024499] add      /module/mii (module)
KERNEL[39.027702] add      /module/usbnet (module)
UDEV  [39.028575] add      /module/usbnet (module)
KERNEL[39.370904] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/net/eth1 (net)
KERNEL[39.371032] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/net/eth1/queues/rx-0 (queues)
KERNEL[39.371101] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/net/eth1/queues/tx-0 (queues)
KERNEL[39.371657] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0 (usb)
KERNEL[39.376747] add      /bus/usb/drivers/ax88179_178a (drivers)
UDEV  [39.376881] add      /bus/usb/drivers/ax88179_178a (drivers)
KERNEL[39.376941] add      /module/ax88179_178a (module)
UDEV  [39.380765] add      /module/ax88179_178a (module)
UDEV  [39.758745] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0 (usb)
UDEV  [39.774046] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-4 (usb)
UDEV  [39.793819] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/net/eth1 (net)
UDEV  [39.799486] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/net/eth1/queues/tx-0 (queues)
UDEV  [39.799526] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/net/eth1/queues/rx-0 (queues)
UDEV  [39.800821] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0 (usb)

Code: Alles auswählen

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 54:ab:3a:f6:76:81 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 94:e9:79:ab:0a:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.18/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 863777sec preferred_lft 863777sec
    inet6 2a01:c22:a864:1f00:9141:9f47:88fe:9223/64 scope global dynamic noprefixroute 
       valid_lft 7011sec preferred_lft 3411sec
    inet6 fe80::8aec:ba7f:4a30:f0b7/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 74:da:38:a0:06:d6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.19/24 brd 192.168.0.255 scope global dynamic noprefixroute eth1
       valid_lft 863806sec preferred_lft 863806sec
    inet6 2a01:c22:a864:1f00:469d:b9b1:9810:34be/64 scope global dynamic noprefixroute 
       valid_lft 7011sec preferred_lft 3411sec
    inet6 fe80::4e1c:f95a:a9b3:6100/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Keine Ahnung, warum sich mein System so standhaft gegen alle Theorien wehrt

[wanne]

Da kein systemd läuft, muss udev das veranstaltet haben - denke ich mal.

Wie gesgt: udev ist jetzt Teil von systemd.
In gentoo gibt es eine unabhänigen Fork des alten udev namens eudev. In Debian hast du immer zumindest den Teil von systemd.

enx[*] renamed from eth1

Da kommt vorne dran, wer da schuld ist, dass da zuerst mal der "falsche" Name genutzt wird.

Keine Ahnung, warum sich mein System so standhaft gegen alle Theorien wehrt

Nicht alles was udev macht ist auch ein event, dass per udevadm abgefangen werden kann.
Die Magic verbirgt sich irgend wo hinter dem Schritt:

Code: Alles auswählen

UDEV  [39.028575] add      /module/usbnet (module)
KERNEL[39.370904] add      /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/net/eth1 (net)

Da merkt udev, dass es ein neues Interface gibt und gibt ihm entpsrechend einen Namen (eth1). Warum das so ist musst du sonst wo suchen. Danach freut sich der Kernel, dass es eth1 gibt und erstellt die passenden Sachen dazu.

[willy4711]

Hab jetzt mal weiter gesucht, woher das kommen mag:
Fundstelle:

Code: Alles auswählen

# MiniSSDPd default configuration

# Set this to 1 if you want to start the daemon
# START_DAEMON deprecated, use service minissdpd enable/disable
#START_DAEMON=1

# Set this to the IP/interface you want the demon to run on
# Notes:
#  1. It is mandatory to use the network interface name in order to enable IPv6
#     HTTP is available on all interfaces.
#  2. Specifying IP when built with IPv6 support is disabled by original
#     author, so this option may not be available outside Debian.
MiniSSDPd_INTERFACE_ADDRESS="eth0 eth1 wlan0"

# This defines other options which you might want to use when
# starting MiniSSDPd.
MiniSSDPd_OTHER_OPTIONS="-6"

Und das Journal:

Code: Alles auswählen

journalctl -b|grep minissdpd
Apr 28 13:27:53 aspire minissdpd[5334]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Apr 28 13:27:53 aspire minissdpd-systemd-wrapper[5334]: Error parsing address/mask (or interface name) : eth0
Apr 28 13:27:53 aspire minissdpd-systemd-wrapper[5334]: can't parse "eth0" as a valid address or interface name
Apr 28 13:27:53 aspire minissdpd[5344]: 43 new devices added
Apr 28 13:27:54 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:27:54 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:27:55 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, eth1): Address already in use
Apr 28 13:27:55 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, eth1): Address already in use
Apr 28 13:27:55 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:27:55 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:27:55 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:27:56 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:27:57 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, eth1): Address already in use
Apr 28 13:27:57 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, eth1): Address already in use
Apr 28 13:27:57 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:27:57 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:33:33 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, eth1): Address already in use
Apr 28 13:33:33 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, eth1): Address already in use
Apr 28 13:33:33 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use
Apr 28 13:33:33 aspire minissdpd[5344]: setsockopt(udp, IPV6_JOIN_GROUP)(FF02::C, wlan0): Address already in use

Woher das Paket kommt ? Wahrscheinlich von der (ursprünglichen) Sparky -Installation
Aber ruhe und arbeite in Frieden. Klappt ja gut
Andere Ideen hab ich nicht.

Meine /etc/network/interfaces is so leer wie sie nur sein kann:

Code: Alles auswählen

auto lo
iface lo inet loopback

und /etc/udev/rules.d gibt es auch nichts ausser Einträge von meinem DVB T2 Stick

[MSfree]

Also ich weiß nicht weiß nicht, was ihr mit umbenennen meint. Der kernel übergibt seit grauer Vorzeit (mindestens lenny) seine Interfaces an udev, dass sich dann einen Namen dafür ausdenkt.

https://www.freedesktop.org/wiki/Softwa ... faceNames/

Wer das nicht mag, der kann unter dem Abschnitt "I don't like this, how do I disable this?" nachsehen, wie man die alten Nnamenskonventionen beibehalten kann. Die einfachste Methode ist, dem Kernel den Bootparameter net.ifnames=0 mitzugeben. Dann bleibt alles bei eth0, eth1...

Und da das ein Kernelparameter ist, gehe ich davon aus, daß in diesem Fall udev eben nicht benachrichtigt wird. Auch das Umbenennen wird meine Interprätation nach durch den Kernel durchgeführt, die dazu passende Ausgabe von dmesg lautet bei einem meiner Rechner:

Code: Alles auswählen

[    4.824409] r8169 0000:04:00.0 enp4s0: renamed from eth0

Das Kernelmodul r8169 hat also die ursprüngliche Bezeichnung eth0 in enp4s0 durchgeführt.Ob das mithilfe von udev passiert, weiß ich natürlich, ohne in die Kernelquellen zu schauen, nicht.

[willy4711]

Die einfachste Methode ist, dem Kernel den Bootparameter net.ifnames=0 mitzugeben. Dann bleibt alles bei eth0, eth1...

Hab solchen Parameter nicht in der Command Line. "renamed" gibt es im Journal naturgemäß auch nicht.

[wanne]

r8169

Da hat sich noch nichts geändert.

Ob das mithilfe von udev passiert, weiß ich natürlich, ohne in die Kernelquellen zu schauen, nicht.

Ich würde mal tippen, dass das am Ende da passiert:
https://github.com/systemd/systemd/blob ... n-net_id.c
Die frage ist, wer das wo anstößt.

[Blackbox]

Ich habe auf meinem Laptop ein ca. 5 Jahre alte Installation (Testing Xfce) .
Dort existieren von Anfang an eth0 wlan0 wlan1 ohne dass es jemals Probleme gab.
Hab mich nie weiter darum gekümmert, da es einfach läuft.

Bei bestehenden Installationen wird das alte Schema erhalten, allerdings bei Neuinstalltionen - seit Debian 9 - eben nicht (mehr).

Siehe hier und solltest du zukünftig die alten NIC Namensschema verwenden wollen, siehe hier.
Diese müssen zukünftig über einem systemd-link realisiert werden.

[schorsch_76]

Also sollte "net.ifnames=0" immer noch das alter Schema erzwingen..... Hoffe ich doch ....

[wanne]

Also sollte "net.ifnames=0" immer noch das alter Schema erzwingen..... Hoffe ich doch ....

Die Frage ist, was du mit alt meinst: Die Debian Variante?: Die wird wohl nach und nach sterben. Die originale udev Variante, wo sich bei mehreren Interfaces die nummern jeden boot unterschiedliche nummern haben können, wenn es mehr als ein Interface vom gleichen Typ gibt? Ja. Die muss aber btw. auch nicht unbedingt mit eth anfangen und gab es so in Debian schon sehr lange nicht mehr.
Hier nochmal im Detail der Unterschied:
In dem Spezialfall, dass ein Rechner nie 2 unterschiedliche Karten sieht sind klassische udev-Namen und die von debian gleich. Aber wenn du eine Karte austauschst hat debian die neue eth1 genannt während udev wieder mit eth0 angefangen hat zu zählen, weil die alte ja nicht mehr vorhanden war und die neue einen neuen Namen bekommt. Genau so wenn 2 Karten im gleichen Rechner stecken. Debian wird immer die gleiche eth1 nennen udev wird mit unabsehbarer Wahrscheinlichkeitsverteilung mal das eine und mal das andere eth0 nennen.

[fischig]

Also sollte "net.ifnames=0" immer noch das alter Schema erzwingen..... Hoffe ich doch ....

Die Frage ist, was du mit alt meinst: Die Debian Variante?: Die wird wohl nach und nach sterben.

Wir reden nicht von Debian, systemd und udev, sondern vom Kernel. Also was ist: Respektiert Debian den Kernel-Parameter im bootloader noch oder nicht mehr, mit systemd oder ohne systemd mit udev oder ohne?
Bisher konnte man Debian ohne systemd (und ohne udev nur mit Eigenbaukern ohne initrd) betreiben.

[wanne]

Wir reden nicht von Debian, systemd und udev, sondern vom Kernel.

Nein. Der Kernel hat mit Interface Namen nichts am Hut. PUNKT. Der Kernel übergibt ein struct mit Eigenschaften an udev. Der kümmert sich dann um weiteres. (Und interagiert dann wieder mehrfach mit dem Kernel.) Der Kernel übergibt die passenden Parameter auch an systemd und macht sie für udev lesbar, der die dann wiederum interpretiert.

Also was ist: Respektiert Debian den Kernel-Parameter im bootloader noch oder nicht mehr, mit systemd oder ohne systemd mit udev oder ohne?

Debian hat udev früher angewisen ein anderes Namensschema zu nutzen, dass ähnlich wie das Orginale ausgesehen hat. In Zukunft wird es das nicht mehr geben, weil udev (das jetzt Teil von Systemd ist) die API dafür killt.

[fischig]

Der Kernel hat mit Interface Namen nichts am Hut. PUNKT.

Mag ich nicht glauben. Ich sitze gerade vor einem Buster ohne systemd, mit Eigenbau-Vanilla-Kern 4.19 und mit equvis-udev-dummy. Ich habe eth0 und ich habe wlan0.

[wanne]

Ich sitze gerade vor einem Buster ohne systemd, mit Eigenbau-Vanilla-Kern 4.19 und mit equvis-udev-dummy. Ich habe eth0 und ich habe wlan0.

Und dann sitzt du entweder in ner chroot o.ä. mit udev im parent oder du hast eine udev kompatible Variante alla eudev/nldev/vdev die sich um die Devices (und deren Benamung) kümmert. Vermutlich in gleiche Art und weise, wie udev das gemacht hat. Sonst gibt es keine Schnittstellen.

[fischig]

Und dann sitzt du entweder in ner chroot o.ä. mit udev im parent

Ich verstehe nur Bahnhof.

oder du hast eine udev kompatible Variante alla eudev/nldev/vdev die sich um die Devices (und deren Benamung) kümmert.

Mit einiger Sicherheit nicht. eudev gibt's in Debian nicht und ich habe keine Fremdpakete außer palemoon auf der Maschine.
Wie könnte ich überprüfen, dass mein Rechner da was Derartiges macht, von dem ich nichts weiß?

[wanne]

Ich verstehe nur Bahnhof.

In ner chroot/container kann sich der Host um die devices kümmern.

Wie könnte ich überprüfen, dass mein Rechner da was Derartiges macht, von dem ich nichts weiß?

Äh mit udevadm, dass du nicht hast?... Eventuell mal gucken was file /run/udev/control sagt. Aber im Prinzip braucht es das ja auch nur für udevadm, was man nicht unbedingt braucht.

[schorsch_76]

Ich würde mal tippen, dass das am Ende da passiert:
https://github.com/systemd/systemd/blob ... n-net_id.c
Die frage ist, wer das wo anstößt.

Das hab ich auch mal probiert das in systemd nachzuvollziehen. Es geht hier alles über Event über/in dbus das dann in systemd??? ausgeführt wird. Ich fand das sehr unübersichtlich dem Controlflow zu folgen. Es gibt ja (mit Absicht) keine Dokumentation..... nichtmal Kommentare im Code.