Arch Linux

UDEV-Problem

303acid

Hi,
Seit einiger Zeit funktioniert eine udev-Regel zur Namensvergabe der Netzwerkkarten nicht mehr richtig.
Eine meiner Netzwerkkarten ist ein USB-Gerät. Und genau bei dieser greift die udev-Regel zum Systemstart nicht. Was zur folge hat das ein anderer systemd-Job beim booten für 1:30min hängt bevor es weitergeht.

Führe ich nach dem booten ein
'udevadm trigger --verbose --subsystem-match=net --action=add'
aus, wird die fehlende Netzwerkkarte umbenannt und und ich kann die problemlos benutzen.

Scheinbar ist hier irgend eine Reihenfolge vertauscht worden. (usb module ladfen, udev device trigger....?)

Was könnte ich dagegen tun?

tuxnix

303acid Was zur folge hat das ein anderer systemd-Job beim booten für 1:30min hängt bevor es weitergeht.
Was könnte ich dagegen tun?

Mit diesem Befehl kann man die Abhängigkeiten der Dienste analysieren
systemctl list-dependencies --all <xxxx>.service
Auch die Optionen --reverse --before --after sind hier möglich.

303acid Scheinbar ist hier irgend eine Reihenfolge vertauscht worden.

Man könnte mit After=, Before=, Requires= die Reihenfolge der units ändern.

frostschutz

Standard udev Regeln oder etwas eigenes?

Steht was in den Logs (dmesg, journalctl, ...)?

Als Workaround könntest du in /etc/mkinitcpio.conf MODULES FILES dafür sorgen, daß die nötigen Module (und eigene Regel-Dateien) schon so früh wie möglich geladen werden. Vielleicht hilft es ja was.

303acid

Nicht unbedingt was eigenes.
'cat /etc/udev/rules.d/10-persistent-net.rules'
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="4c:38:d5:15:d2:3e", ATTR{type}=="1", KERNEL=="eth", NAME="LAN"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="4c:38:d5:15:d2:3f", ATTR{type}=="1", KERNEL=="eth", NAME="WLAN"

#USB-adapters
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:23:56:2c:37:19", ATTR{type}=="1", KERNEL=="eth*", NAME="WAN"

Hatte ja auch Jahrelang funktioniert.
Im Journal finde ich nichts
Ich habe jetzt mal das UDEV-Hook in mkinitcpio noch einmal am Schluss angehangen, ich prüfe...

303acid

....hat nicht geholfen.

303acid

so wie's aussieht, passiert das udev-trigger weit eher als das Kernelmodul für die USB-Netzwerkkarte geladen ist/wird. Deswegen klappt das renaming auch bei den on-board-devices. Mir ist dieser ganze systemd-Zauber zu wild. Ich beuge mich der höheren Macht und ändere einfach in meinen 3 Scripten den device Namen

brikler

303acid udev-trigger weit eher als das Kernelmodul für die USB-Netzwerkkarte geladen ist

ich würde dieses modul ins module array der /etc/mkintcpo.conf eintragen, und mal schauen was passiert

303acid

@"brikler"
Hatte ich schon gemacht. Es passiert nichts. Außer einer Fehlermeldung am Bootanfang die zu kurz war um sie zu lesen...

brikler

303acid Warum nicht mit systemd beim booten?

ich tippe mal drauf, daß systemd die netzwerk bezeichnung ändert. systemd nutzt nicht mehr eth0, bzw wlan0, sondern enp0s<1>, bzw wlp0s<1>.

303acid einer Fehlermeldung am Bootanfang die zu kurz war um sie zu lesen...

dann wird sie im journal stehen, da findest sie wahrschenlich mit journalctl -p err

303acid

Es ist die Hölle!!!
Vor ca. 4std. und 50 Neustarts dachte ich mir "Was soll's, ändere einfach den device-Namen und gut ist's"
Pustekuchen!
Keine Ahnung was hier wirklich los ist aber dhcpcd will zur Bootzeit nicht funktionieren.
Bzw. wird irgendwelcher Blödsinn gemacht.
Ich habe den systemd service dhcpcd@WAN auf dhcpcd@eth0 geändert um das doofe device renaming zu umgehen. Aber beim Systemstart funktioniert dhcpcd trozdem nicht.
Sobald aber das System hochgefahren ist, kann ich problemlos in der Konsole systemctl start dhcpcd@eth0 aufrufen und die NIC holt sich eine IP beim ISP.
Aber beim Startvorgang funktioniert das ums verrecken nicht. Keine Ahnung was systemd hier veranstaltet.

Ich bin fertig und gefrustet - und kurz davor ein jahrelang funktionierendes System zu plätten und neu aufzusetzen!

Ein listening von dhcpcd während des starts und direkt nach dem start:
`
systemd[1]: Created slice Slice /system/dhcpcd.
dhcpcd[715]: dhcpcd-10.0.6 starting
dhcpcd[723]: DUID 00:01:00:01:2d:83:67:7f:6a:7b:bf:16:b1:f1
dhcpcd[723]: eth0: waiting for carrier
dhcpcd[723]: eth0: carrier acquired
dhcpcd[723]: eth0: IAID 7a:76:ea:06
dhcpcd[723]: eth0: soliciting a DHCP lease
dhcpcd[723]: eth0: probing for an IPv4LL address
dhcpcd[723]: eth0: using IPv4LL address 169.254.52.17
dcpcd[723]: eth0: adding route to 169.254.0.0/16
dhcpcd[723]: eth0: adding default route
dhcpcd[723]: eth0: 00:23:56:2c:37:19(00:23:56:2c:37:19) claims 169.254.52.17
dhcpcd[723]: eth0: 00:23:56:2c:37:19(00:23:56:2c:37:19) claims 169.254.52.17
dhcpcd[723]: eth0: 10 second defence failed for 169.254.52.17
dhcpcd[723]: eth0: deleting route to 169.254.0.0/16
dhcpcd[723]: eth0: deleting default route
dhcpcd[1392]: sending signal TERM to pid 722
dhcpcd[1392]: waiting for pid 722 to exit
dhcpcd[1392]: sending signal TERM to pid 722
dhcpcd[1392]: waiting for pid 722 to exit
dhcpcd[723]: received SIGTERM, stopping
dhcpcd[723]: eth0: removing interface
dhcpcd[723]: main: control_stop: No such file or directory
dhcpcd[723]: dhcpcd exited
systemd[1]: dhcpcd@eth0.service: Deactivated successfully.
dhcpcd[1400]: dhcpcd-10.0.6 starting
dhcpcd[1403]: DUID 00:01:00:01:2d:83:67:7f:6a:7b:bf:16:b1:f1
dhcpcd[1403]: eth0: IAID 56:2c:37:19
dhcpcd[1403]: eth0: soliciting a DHCP lease
dhcpcd[1403]: eth0: offered 193.159.198.74 from 172.20.0.1
dhcpcd[1403]: eth0: probing address 93.159.98.74/24
dhcpcd[1403]: eth0: leased 193.159.198.74 for 86400 seconds
dhcpcd[1403]: eth0: adding route to 193.159.198.0/24
dhcpcd[1403]: eth0: adding default route via 193.159.198.254

303acid

Ich habe dhcpcd aus dem Systemstart entfernt. Ist der Startvorgang beendet und ich bin eingeloggt funktioniert dhcpcd ohne Probleme.
Warum nicht mit systemd beim booten?

segfault

Wenn ich das ganze Elend hier lese frage ich mich, warum Du nicht auf systemd-networkd umstellst. Die ganzen Namen sind da egal, da Du dort die Möglichkeit hast anhand der MAC Adresse zu matchen.