Warum ich udev nicht will

[Colttt]

Außer, die Hardware ändert sich. Dann vergibt udev einen zufälligen Namen. Mit ifrename [...]

Das stimmt so nicht ganz wenn du vorher eth0 und eth1 hattest jetzt die hardware tauschst, also sagen wir eth0 dann wird das nächste device eth2 heissen und jeder der was anderes behauptet möchte ich ein beweis sehen und zwar mit oldstable und nicht angefasster udev-config


@cosamac so richtig erkennen konnte ich bis jetzt aber nich nicht was dich an udev wirklich stört mit handfesten beweisen/Beispielen.

[cosmac]

Außer, die Hardware ändert sich. Dann vergibt udev einen zufälligen Namen. Mit ifrename [...]

Das stimmt so nicht ganz wenn du vorher eth0 und eth1 hattest jetzt die hardware tauschst, also sagen wir eth0 dann wird das nächste device eth2 heissen

Außer, man erlebt das zum ersten Mal und steckt eine weitere neue Interface-Karte rein (die erste war ja offensichtlich auch defekt). Also, für jemanden, der den Trick nicht kennt, ist das praktisch zufällig.

@cosamac so richtig erkennen konnte ich bis jetzt aber nich nicht was dich an udev wirklich stört mit handfesten beweisen/Beispielen.

* diese eth-Umbenennung war der Auslöser und reicht mir völlig. Sowas darf nicht per Default eingeschaltet sein.
* einzelne Funktionen sind fest einprogrammiert und lassen sich nicht per udev-Regel ändern.
* "Synthesizing the initial hotplug events" dauert sehr lange.
* es ist auch eine Kosten/Nutzen-Frage. Ich brauche udev ganz einfach nicht. Alles, was ich benutze, funktioniert auch ohne. Die einzige Funktion, die ich mal genutzt habe, ist Hot Plug für die Tastatur. Aber auch dafür habe ich inzwischen zwei andere Lösungen. Steckt eigentlich noch irgendwer seine Tastatur im Betrieb ein- und aus?

Vielleicht ist manches davon heute nicht mehr so schlimm, seit ein paar Debian-Versionen läuft udev hier nur beim allerersten Start nach der Installation.

[detix]

und du bist dir ganz sicher das so eine Benennung der Netzwerkinterfaces an udev und nicht vielleicht an der automatisch erstellten /boot/initrd.img... liegt?

[scientific]

Außer, die Hardware ändert sich. Dann vergibt udev einen zufälligen Namen. Mit ifrename [...]

Das stimmt so nicht ganz wenn du vorher eth0 und eth1 hattest jetzt die hardware tauschst, also sagen wir eth0 dann wird das nächste device eth2 heissen

Außer, man erlebt das zum ersten Mal und steckt eine weitere neue Interface-Karte rein (die erste war ja offensichtlich auch defekt). Also, für jemanden, der den Trick nicht kennt, ist das praktisch zufällig.

@cosamac so richtig erkennen konnte ich bis jetzt aber nich nicht was dich an udev wirklich stört mit handfesten beweisen/Beispielen.

* diese eth-Umbenennung war der Auslöser und reicht mir völlig. Sowas darf nicht per Default eingeschaltet sein.

Also es ist eine Änderung, die du nicht mitbekommen hast, und die dich am falschen Fuß erwischte. Jetzt bist du auf udev böse.

* einzelne Funktionen sind fest einprogrammiert und lassen sich nicht per udev-Regel ändern.

Welche? Und warum stören die?

* "Synthesizing the initial hotplug events" dauert sehr lange.

Bist du diesem Problem schon einmal nachgegangen?
Wie lange ist "sehr lange"?

* es ist auch eine Kosten/Nutzen-Frage. Ich brauche udev ganz einfach nicht. Alles, was ich benutze, funktioniert auch ohne. Die einzige Funktion, die ich mal genutzt habe, ist Hot Plug für die Tastatur. Aber auch dafür habe ich inzwischen zwei andere Lösungen. Steckt eigentlich noch irgendwer seine Tastatur im Betrieb ein- und aus?

Es ist nicht nur die Tastatur. Es sind Drucker, mobile Internet-Sticks, USB-Speichersticks, externe Festplatten, USB-Mäuse, Funkmäuse, Lautsprecher, Dockingstations usw. usf. und ja, auch ab und zu mal eine Tastatur zum Testen, ob die noch funktioniert...
Udev auf Tastatur und Netzwerkgeräte zu reduzieren ist ein wenig gar einfach.

Vielleicht ist manches davon heute nicht mehr so schlimm, seit ein paar Debian-Versionen läuft udev hier nur beim allerersten Start nach der Installation.

Schön für dich, dass du eine für dich funktionierende Lösung gefunden hast. Ich für meinen Teil finde udev gut funktional. Es tut genau, was ich will. Mittels udev-Regeln starte ich für verschiedene externe Platten verschiedene Backup-Aufrufe. Ansonsten ist es unauffällig. Mir persönlich sind Animositäten von Softwareentwicklern wie Pöttering, Sievers oder Torvalds ziemlich schnuppe. Und Neues... ja, manchmal find ichs blöd, manchmal nicht. Wenn ich muss, teste ich es und lerne damit umzugehen, wenn ich nicht muss, mach ich's auch manchmal so.

lg scientific

[cosmac]

und du bist dir ganz sicher das so eine Benennung der Netzwerkinterfaces an udev und nicht vielleicht an der automatisch erstellten /boot/initrd.img... liegt?

ziemlich sicher, weil die initrd garnicht benutzt wird. Und wenn ich dann udev laufen lasse:

Code: Alles auswählen

$ uname -a
Linux kuemmel 4.12.0-dt4 #2 SMP Wed Jul 19 12:23:07 CEST 2017 i686 GNU/Linux
$ zgrep INITRD /proc/config.gz
# CONFIG_BLK_DEV_INITRD is not set
$ ps -f -C systemd-udevd
UID        PID  PPID  C STIME TTY          TIME CMD
root       239     1  0 13:16 ?        00:00:00 /lib/systemd/systemd-udevd --daemon
$ grep eth0 /var/log/syslog
Sep 11 13:16:49 kuemmel kernel: [    4.663876] r8169 0000:01:00.0 eth0: RTL8168g/8111g at 0xf815a000, 90:1b:0e:8c:d5:c7, XID 0c000800 IRQ 30
Sep 11 13:16:49 kuemmel kernel: [    4.664129] r8169 0000:01:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
Sep 11 13:16:49 kuemmel kernel: [    7.226800] r8169 0000:01:00.0 enp1s0: renamed from eth0
$

Also es ist eine Änderung, die du nicht mitbekommen hast, und die dich am falschen Fuß erwischte. Jetzt bist du auf udev böse.

Genau so ist es.

* einzelne Funktionen sind fest einprogrammiert und lassen sich nicht per udev-Regel ändern.

Welche? Und warum stören die?

Das war ganz zu Anfang, da wollte ich udev tatsächlich benutzen und eigene Regeln schreiben. Und ich wollte die meisten mitgelieferten Regeln außer Betrieb nehmen, mangels Bedarf. Das ging nicht vollständig, ich glaube, es war was mit CD-Laufwerken, zu lange her für Einzelheiten

* "Synthesizing the initial hotplug events" dauert sehr lange.

Bist du diesem Problem schon einmal nachgegangen?

Im Prinzip ja: mit devtmpfs ist der ganze Mechanismus überflüssig. Deshalb ist es mir total egal, ob man udev-seitig etwas optimieren könnte.

* es ist auch eine Kosten/Nutzen-Frage. Ich brauche udev ganz einfach nicht. Alles, was ich benutze, funktioniert auch ohne. Die einzige Funktion, die ich mal genutzt habe, ist Hot Plug für die Tastatur. Aber auch dafür habe ich inzwischen zwei andere Lösungen. Steckt eigentlich noch irgendwer seine Tastatur im Betrieb ein- und aus?

Es ist nicht nur die Tastatur. Es sind Drucker, mobile Internet-Sticks, USB-Speichersticks, externe Festplatten, USB-Mäuse, Funkmäuse, Lautsprecher, Dockingstations usw. usf. und ja, auch ab und zu mal eine Tastatur zum Testen, ob die noch funktioniert...

Mäuse sind quasi Tastaturen, s.o., Drucker werden per Netzwerk angeschlossen (für Parallelport-Drucker funktioniert udev sowieso nicht), Dockingstations habe ich keine und der Rest funktioniert auch ohne udev.

Ich für meinen Teil finde udev gut funktional. Es tut genau, was ich will.

Ich will es dir auch nicht ausreden.

Und Neues... ja, manchmal find ichs blöd, manchmal nicht.

Da sind wir direkt einer Meinung

[scientific]

Also doch nur ein Sturm im Wasserglas der Befindluchkeiten, und nichts wirklich technisch begründ- und belegbares...

Na gut.

[BenutzerGa4gooPh]

Betrachtet doch mal den Fall mit/ohne udev: https://www.amazon.de/Celeron-Firewall- ... 3741P&th=1
Ich hatte mal PFSense/BSD darauf. Wären die Interface-Bezeichnungen bereits mit Jessie immer konstant und der Reihe nach?
Vielleicht lässt sich cosmac so überzeugen?

[cosmac]

Wären die Interface-Bezeichnungen bereits mit Jessie immer konstant und der Reihe nach?

Ein 2.6er Kernel würde konstante eth0 bis eth3 liefern, aber seitdem läuft im Kernel immer mehr parallel. Trotzdem könnte es speziell mit dieser Hardware (wahrscheinlich 4 Interfaces im gleichen Chip) auch noch so funktionieren. Dann braucht man kein udev und keine Tricks.

Wenn das nicht so ist, nimmt man ifrename statt udev.

Mit udev und eigenen udev-Regeln hat es gefälligst en0 bis en3 zu heißen (oder rot, gelb, gruen, blau), und zwar konstant und mit jeder Debian-Version seit es udev gibt. Aber dazu müsste man erstmal die mitgelieferten Regeln abschalten können.

Vielleicht lässt sich cosmac so überzeugen?

Will man das? Sollte man nicht lieber scientific überzeugen?
Obwohl, letzten Samstag hat man mich mit einer Schwarzwälder Kirschtorte "überzeugt"

[detix]

du macht es einem auch nicht gerade einfach:

CONFIG_BLK_DEV_INITRD is not set
root 239 1 0 13:16 ? 00:00:00 /lib/systemd/systemd-udevd --daemon

systemds udev läuft offensichtlich, aber dies spielt auch gern mit der initrd rum,
dazu mal in die /usr/share/doc/udev/README.Debian.gz hineinschauen,
das Ein oder Andere wird durch systemds udev also schon in die initrd gebrannt...

hier zB definitiv die selbsterstellten *.link -Dateien (Benennung der Interfaces) in /etc/systemd/network/
selbst kleinste Änderungen dort erfordern ein „update-initramfs -u”

[BenutzerGa4gooPh]

Obwohl, letzten Samstag hat man mich mit einer Schwarzwälder Kirschtorte "überzeugt"

Fällt das unter "ueberzeugen" oder bestechen?
Aber danke für die Antwort. Auf udev bin ich erst durch deinen Thread aufmerksam geworden, die neue "Benamserung" der IFs ab Stretch und deren Gründe war mir bekannt. Und nun lese ich still weiter mit.

[cosmac]

CONFIG_BLK_DEV_INITRD is not set
root 239 1 0 13:16 ? 00:00:00 /lib/systemd/systemd-udevd --daemon

systemds udev läuft offensichtlich, aber dies spielt auch gern mit der initrd rum,

Das darf ruhig spielen, die initrd kann garnicht benutzt werden, mein Kernel kennt sowas nicht (CONFIG_BLK_DEV_INITRD is not set).

selbst kleinste Änderungen dort erfordern ein „update-initramfs -u”

Da wird nichts geändert, darum geht es doch garnicht. Es gibt keine initrd, der Kernel findet ein eth0 und irgendwer (naja, wer wohl) nennt es enp1s0. Und wenn ich udev nicht starte bleibt es bei eth0. Aus dem syslog:

Code: Alles auswählen

enp1s0: renamed from eth0

Auf einem anderen Rechner mit identischer Hardware gibt es garkeine initrd und keine initramfs-tools und es passiert das gleiche.

[DeletedUserReAsG]

Die Sache ist halt: wenn du mehrere Interfaces drin hast, oder welche austauschst, kann’s passieren, dass dein ursprüngliches eth0 eben mal nach dem Boot nicht mehr eth0 ist – und je nach restlichem Setup zerhaut’s dir damit dein ganzes Netzwerk. Die Umbenennung via udev soll dem vorbeugen, indem jedes Interface einen eindeutigen Namen bekommt, der sich auch beim Einbauen anderer NICs, oder beim Wechsel der Steckplätze, oder was auch immer man so rumschraubt, nicht ändert. Das hat dann zur Folge, dass etwa beim Ausfall eines Interfaces nur genau der Teil des Netzes betroffen ist, den dieses bedient hatte – und nicht die ganze restliche Config durch eine Art Dominoeffekt durcheinanderkommt.

Gut, für den Hausgebrauch mit einmal Ethernet und vielleicht noch ’nem WLAN-Stick fällt das eher weniger ins Gewicht. Bei komplexeren Setups mag’s aber unter Umständen schon ganz erheblich für bessere Laune beim Admin sorgen ….

[rendegast]

Habe gerade mal

Code: Alles auswählen

ls -1 /lib/udev/rules.d  |  while read dumm;  do touch /etc/udev/rules.d/$dumm ;  done

das udev scheinbar deaktiviert.

Bei einem 'udevadm test /block/sda' kommt

Code: Alles auswählen

...
Skipping overridden file: /lib/udev/rules.d/....rules
...
Skipping empty file: /etc/udev/rules.d/....rules
...

Nach einem 'update-initramfs -u -kall' sind nur noch zwei *md*.rules mit Inhalt in der initrd.
(Ein expliziter Kopiervorgang)

Die rebootete VM landet in einer "busybox (initramfs)".
Beim Ausprobieren also den '-snapshot'-Schalter nicht vergessen.