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 hat auf diesen Beitrag geantwortet.

    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.

    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 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.

    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 hat auf diesen Beitrag geantwortet.

      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

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

      • brikler hat auf diesen Beitrag geantwortet.

        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

        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?

        • brikler hat auf diesen Beitrag geantwortet.

          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.

          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