[gelöst] Netzwerkverlust

[TomL]

Gekürzt wegen Wiederholung ... siehe übernächstes Posting.... sorry...

[mat6937]

Ich meine gar nix und ich weiss auch nix, ich nehme nur einfach das, was da steht.... und da steht, dass eth0 "down" bleibt.

Ich denke Du verwechselst den Zustand des eth0-Interfaces mit dem Zustand der Verbindung (über das eth0-Interface). Denn der Zustand der Verbindung ist down, aber das eth0-Interface ist up. Siehe die blaue Markierung für den Zustand der Verbindung:

# ip link set dev eth0 up
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 10:60:4b:81:76:38 brd ff:ff:ff:ff:ff:ff

und die rote Markierung für den Zustand des eth0-Interfaces (nach einem "ip link set dev eth0 up").

Z. B.:

:~$ ip link set dev eth0 up && ip addr show | grep -i eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000

und jetzt ein down:

:~$ ip link set dev eth0 down && ip addr show | grep -i eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000

"state DOWN" ist der Zustand der Verbindung und dieser kann zu diesem Zeitpunkt, ja auch nur DOWN sein, denn das Interface hat ja noch keine IP-Adresse oder keine Verbindung auf "Data Link Layer" (z. B. mit dem arp-Protokoll).

[TomL]

Ich denke Du verwechselst den Zustand

Deswegen hatte ich ja gesagt "überspringen".... was bedeutet, nicht lustvoll drauf rumzureiten

Ich habe gerade mal was getestet.... nach Kaltstart, ohne Kabel:

Code: Alles auswählen

root@DellNotebook:/home/thomas
# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled)
   Active: inactive (dead)
     Docs: man:systemd-networkd.service(8)

# ip addr show | grep eth0 -A1
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 5c:26:0a:68:d6:06 brd ff:ff:ff:ff:ff:ff

# ip link set dev eth0 up

# ip addr show | grep eth0 -A1
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 5c:26:0a:68:d6:06 brd ff:ff:ff:ff:ff:ff

# ip link set dev eth0 down

Und jetzt einfach das Kabel eingesteckt:

Code: Alles auswählen

# ip addr show | grep eth0 -A1
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 5c:26:0a:68:d6:06 brd ff:ff:ff:ff:ff:ff

root@DellNotebook:/home/thomas
# ip link set dev eth0 up

# ip addr show | grep eth0 -A1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 5c:26:0a:68:d6:06 brd ff:ff:ff:ff:ff:ff

Tja, *hmmmmm*..... ... da sieht man den Unterschied bei den beiden "up's".... also ist die Ursache vielleicht doch "physisch".... Karte nicht richtig drin, Kabel hat nen Wackel oder ne Knickstelle, Dichtungsring im Router-Port ist undicht und die Bits laufen hintern Schrank.....

[mat6937]

Und jetzt einfach das Kabel eingesteckt:

Code: Alles auswählen

# ip addr show | grep eth0 -A1
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 5c:26:0a:68:d6:06 brd ff:ff:ff:ff:ff:ff

root@DellNotebook:/home/thomas
# ip link set dev eth0 up

# ip addr show | grep eth0 -A1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 5c:26:0a:68:d6:06 brd ff:ff:ff:ff:ff:ff

Tja, *hmmmmm*..... ... da sieht man den Unterschied bei den beiden "up's".... also ist die Ursache vielleicht doch "physisch".... Karte nicht richtig drin, Kabel hat nen Wackel oder ne Knickstelle, Router-Port undicht.....

Deshalb habe ich ja weiter oben auch mal geschrieben, dass er das Kabel auch mal raus und rein soll.

EDIT:

BTW: Das hier:

Deswegen hatte ich ja gesagt "überspringen".... was bedeutet, nicht lustvoll drauf rumzureiten

ist eine Ergänzung von dir und war zu dem Zeitpunkt als ich meinen Beitrag begonnen habe, noch nicht in deinem Beitrag zu lesen.

[TomL]

Deshalb habe ich ja weiter oben auch mal geschrieben, dass er das Kabel auch mal raus und rein soll.

Ja, oder vielleicht sogar ganz wechseln.... und wenn es im PC so ein "Slot-Connector" fürs Ethernet ist, der hinten bei den Ausbrech-Blechen (weiss nicht, wie die heissen) montiert ist, einfach mal kontrollieren, ob der noch richtig im Slot sitzt.

[mat6937]

.... also ist die Ursache vielleicht doch "physisch".... Karte nicht richtig drin, Kabel hat nen Wackel oder ne Knickstelle, Dichtungsring im Router-Port ist undicht und die Bits laufen hintern Schrank.....

Evtl. entsteht der Fehler bzw. das Problem erst gar nicht, wenn der TE einen geeigneten DHCP-Client verwendet (... wenn er DHCP will) und diesen so konfiguriert, dass der DHCP-Client vor dem DHCP-Vorgang (DHCPDiscovery), arping an den Router/DHCP-Server macht. Z. B. der dhcpcd kann das. Auszug aus der manpage der dhcpcd.conf:

arping address [address]
dhcpcd will arping each address in order before attempting DHCP. If an address is found, we will select the replying hard-
ware address as the profile, otherwise the ip address. Example:

interface bge0
arping 192.168.0.1

Wenn der Router stromlos gemacht wird bzw. wieder eingeschaltet wird, macht dieser ja auch arpings (d. h. arp-requests) in sein Subnetz, was dann anschließend evtl. zur erfolgreichen IP-Zuweisung per DHCP an das betroffene bzw. besagte Gerät, führt.

[gambit]

Gut, einen Fehler meldet der Treiber nicht. Es fehlt halt nur die Meldung "e1000e: eth0 NIC Link is Up", aber das wissen wir ja schon.

Hast du es mal mit der anderen LAN-Buchse an der Fritzbox ausprobiert?

Und installiere dir bitte mal das Paket "ethtool". Und dann probiere mal folgenden Befehl als root aus:

Code: Alles auswählen

ethtool -r eth0

und schau, ob die Lampe dann grün leuchtet.

Ja, eine andere LAN-Buchse habe ich ausprobiert: keine Veränderung.

ethtool habe ich jetzt installiert, das Kommando

Code: Alles auswählen

ethtool -r eth0

[ heisst das nach Kaltstart (?) und ohne NWM (?) und ohne dass die grüne Lampe zuvor brennt(?) werde ich noch eingeben und berichten

[NAB]

heisst das nach Kaltstart (?) und ohne NWM (?) und ohne dass die grüne Lampe zuvor brennt(?) werde ich noch eingeben und berichten

Der Befehl soll die Lampe grün machen ... also wär's gut, wenn sie vorher nicht grün ist

Und schau mal nach, ob es für deine Fritzbox eine neuere Firmware gibt. Das sollte recht problemlos über die Weboberfläche der Fritzbox gehen.

[gambit]

Also zunächst nochmal vielen Dank für eure Beiträge. Ich muss gestehen, es ist ganz einfach bei den vorgestellten Lösungsstrategien den Überblick zu bewahren.

Vielleicht Folgendes grundsätzlich:
1) Ich habe zurzeit nur den einen Rechner, d. h., wenn ich hier posten will, bleibt mir gar nichts anderes übrig, als den Router wieder in Betrieb zu nehmen (sc. "rumzufummeln")
2) Wenn ich die Testkommandos ausgeführt und geschrieben habe, dass das ohne bestehendes Netzwerk bzw. ohne NWM erfolgte, dann war das auch so.
3) Fehler im LAN-Kabel schließe ich zunächst aus, weil ich ein anderes, neues Kabel ausprobiert habe, mit dem selben Ergebnis. Außerdem funktionierte das Kabel bei einem Laptop, den ich mal hier hatte, ebenso wie die Netzwerkverbindung zum Router, einwandfrei.
4) Deshalb glaube ich erstmal auch nicht, dass es am Router liegt.
5) Ob die Netzhardware der Schuldige ist, weiß ich nicht. Auch davon verstehe ich nichts, ich muss mich einlesen und das prüfen.

Ich sehe bei den Versuchen, mir mir zu helfen, im Grundsatz 3 Ansätze (tw. mit Vermischungen):

1) TomL: Softwareproblem, vorzugsweise NWM
2) mat6937 : Softwareproblem, vielleicht Treiber
3) NAB: Primärer Ansatz = Hardwareproblem

Das ist natürlich sehr vereinfachend zusammengefasst.

Ich werde die Diagnoseansätze abarbeiten und berichten, in der Hoffnung, dass ihr nicht die Geduld verliert.

Jetziger Rechnerzustand: Er macht nur nach dem "Kaltstart" (sc. Einschalten nach stromlosem Zustand) Probleme. Bei normalem Einschalten aus "Zustand aus, aber an Steckdose" (grüne Lampe brennt) keinerlei Problem.

[gambit]

heisst das nach Kaltstart (?) und ohne NWM (?) und ohne dass die grüne Lampe zuvor brennt(?) werde ich noch eingeben und berichten

Der Befehl soll die Lampe grün machen ... also wär's gut, wenn sie vorher nicht grün ist

Ok, geschenkt. ich dachte es könnte sein, dass geprüft werden soll, ob die Lampe "weiterbrennt". Aber ich korrigiere das natürlich und berichte

Und schau mal nach, ob es für deine Fritzbox eine neuere Firmware gibt. Das sollte recht problemlos über die Weboberfläche der Fritzbox gehen.

Ja das mache ich noch detaillierter auf der AVM-Seite. Die Fritzbox Onboard-Testfunktion zeigt bislang, dass es keine neuere Version gibt.

[TomL]

Ich sehe bei den Versuchen, mir mir zu helfen, im Grundsatz 3 Ansätze (tw. mit Vermischungen):

1) TomL: Softwareproblem, vorzugsweise NWM
2) mat6937 : Softwareproblem, vielleicht Treiber
3) NAB: Primärer Ansatz = Hardwareproblem

Ich denke auch, dass da irgendwo die Lösung drinsteckt. Vor mir jetzt noch mal einen Lösungsvorschlag, der wieder darauf abzielt, den NWM erst mal zu deaktivieren... natürlich vor dem Hintergrund, dass man den ja jederzeit wieder reaktivieren kann. Also erst mal den NWM konsequent abmelden, so dass er beim Kaltstart oder Reboot nicht gestartet wird.

Und dann das Netzwerk gemäß dieser hier beschriebenen Schritte einfach unter Systemd einrichten und mal schauen, was damit passiert. Auch das kann jederzeit wieder mit einfachen "disables" abgeschaltet werden, um damit zum vorherigen Zustand zurückzukehren. Ich würde hier nur in der eth0.network die Static-IP mit # kommentieren und DHCP wählen.

[gambit]

Ich sehe bei den Versuchen, mir mir zu helfen, im Grundsatz 3 Ansätze (tw. mit Vermischungen):

1) TomL: Softwareproblem, vorzugsweise NWM
2) mat6937 : Softwareproblem, vielleicht Treiber
3) NAB: Primärer Ansatz = Hardwareproblem

Ich denke auch, dass da irgendwo die Lösung drinsteckt. Vor mir jetzt noch mal einen Lösungsvorschlag, der wieder darauf abzielt, den NWM erst mal zu deaktivieren... natürlich vor dem Hintergrund, dass man den ja jederzeit wieder reaktivieren kann. Also erst mal den NWM konsequent abmelden, so dass er beim Kaltstart oder Reboot nicht gestartet wird.

Und dann das Netzwerk gemäß dieser hier beschriebenen Schritte einfach unter Systemd einrichten und mal schauen, was damit passiert. Auch das kann jederzeit wieder mit einfachen "disables" abgeschaltet werden, um damit zum vorherigen Zustand zurückzukehren. Ich würde hier nur in der eth0.network die Static-IP mit # kommentieren und DHCP wählen.

Das werde ich probieren.

Wenn ich mich nicht so umgehend melden kann, bitte ich das nicht als Desinteresse zu verstehen. Nur, das Ganze frisst unheimlich Zeit, die ich im Moment nicht habe und wenn man jeden minimalen Schritt ablesen muss, dauert es eben umso länger.
Und ich muss natürlich aufpassen, dass ich mein System nicht insgesamt hinrichte. Wie gesagt: nur 1 Rechner steht zur Verfügung.

Ich muss jetzt erstmal lesen und werde in den nächsten Tagen kontinuierlich berichten. Ich will's jedenfalls richtig lernen!

Und ich weiß sehr zu schätzen, dass ihr eure Zeit hier investiert!

[gambit]

... Vor mir jetzt noch mal einen Lösungsvorschlag, der wieder darauf abzielt, den NWM erst mal zu deaktivieren... natürlich vor dem Hintergrund, dass man den ja jederzeit wieder reaktivieren kann. Also erst mal den NWM konsequent abmelden, so dass er beim Kaltstart oder Reboot nicht gestartet wird.

Und dann das Netzwerk gemäß dieser hier beschriebenen Schritte einfach unter Systemd einrichten und mal schauen, was damit passiert. Auch das kann jederzeit wieder mit einfachen "disables" abgeschaltet werden, um damit zum vorherigen Zustand zurückzukehren. Ich würde hier nur in der eth0.network die Static-IP mit # kommentieren und DHCP wählen.

Ich habe Folgendes probiert:

Code: Alles auswählen

ip addr show

Code: Alles auswählen

nano /etc/systemd/network/eth0.network

...mit diesem Inhalt die Static-IP im Netz gesetzt (die IP-Adresse "dieses" Rechners und das Gateway musst Du natürlich auf Deine Gegebenheiten ändern):
..

Code: Alles auswählen

[Match]
Name=eth0

[Network]
DHCP=v4
#Address= ...
# Gateway= ...

Code: Alles auswählen

chmod 644 /etc/systemd/network/eth0.network
chown root:root /etc/systemd/network/eth0.network

Code: Alles auswählen

nano /etc/systemd/resolved.conf 

Code: Alles auswählen

    [Resolve]
    DNS=192.168.178.1

Code: Alles auswählen

systemctl start systemd-resolved.service; systemctl status systemd-resolved.service

Code: Alles auswählen

[ -f /etc/resolv.conf ] && rm /etc/resolv.conf
ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved.service

Jetzt kam das Problem in Bezug auf Deine Beschreibung

Code: Alles auswählen

ls /etc/resolv.conf
     [color=#FF0000]lrwxrwxrwx 1 root root 32 Mai  9 15:26 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf[/color] 

Es kam an dieser Stelle nur zurück:

Code: Alles auswählen

ls /etc/resolv.conf

Code: Alles auswählen

cat /etc/resolv.conf

zeigte korrekt den eingetragenen Nameserver

[TomL]

Es kam an dieser Stelle nur zurück:

Code: Alles auswählen

ls /etc/resolv.conf

Code: Alles auswählen

cat /etc/resolv.conf

zeigte korrekt den eingetragenen Nameserver

Merkwürdig.... möglicherweise hat das mit dem Löschen ...

Code: Alles auswählen

[ -f /etc/resolv.conf ] && rm /etc/resolv.conf

...dieser Datei nicht geklappt. Nach dem Löschen wird die ja auf das systemd-Verzeichnis verlinkt.... aber egal... wenn der Eintrag korrekt ist, sollte das eigentlich trotzdem funktionieren. Aber die viel wichtigere Frage ist, was ist jetzt mit dem Kaltstart? Wird verbunden oder nicht? Klappt das jetzt oder braucht es immer noch den Router-Neustart?

[gambit]

Es kam an dieser Stelle nur zurück:

Code: Alles auswählen

ls /etc/resolv.conf

Code: Alles auswählen

cat /etc/resolv.conf

zeigte korrekt den eingetragenen Nameserver

Merkwürdig.... möglicherweise hat das mit dem Löschen ...

Code: Alles auswählen

[ -f /etc/resolv.conf ] && rm /etc/resolv.conf

...dieser Datei nicht geklappt. Nach dem Löschen wird die ja auf das systemd-Verzeichnis verlinkt.... aber egal... wenn der Eintrag korrekt ist, sollte das eigentlich trotzdem funktionieren. Aber die viel wichtigere Frage ist, was ist jetzt mit dem Kaltstart? Wird verbunden oder nicht? Klappt das jetzt oder braucht es immer noch den Router-Neustart?

Es hakt an folgender Stelle.

Code: Alles auswählen

# systemctl start systemd-networkd-wait-online.service

Dort passiert nach Eingabe des Startbefehls minutenlang nichts. Er akzeptiert den Befehl, aber der Cursor springt nur in eine neue Zeile und nicht passiert weiter.

Code: Alles auswählen

ip addr show

zeigt

Code: Alles auswählen

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 10:60:4b:81:76:38 brd ff:ff:ff:ff:ff:ff

Sodann:

Code: Alles auswählen

# systemctl status systemd-networkd systemd-resolved systemd-networkd-wait-online
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled)
   Active: active (running) since Mi 2016-05-11 21:21:11 CEST; 5min ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 1351 (systemd-network)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-networkd.service
           └─1351 /lib/systemd/systemd-networkd

Mai 11 21:21:11 seneca systemd-networkd[1351]: lo              : gained carrier
Mai 11 21:21:11 seneca systemd-networkd[1351]: eth0            : link configured

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled)
   Active: active (running) since Mi 2016-05-11 21:18:55 CEST; 7min ago
     Docs: man:systemd-resolved.service(8)
 Main PID: 1345 (systemd-resolve)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-resolved.service
           └─1345 /lib/systemd/systemd-resolved

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; disabled)
   Active: activating (start) since Mi 2016-05-11 21:22:00 CEST; 4min 46s ago
     Docs: man:systemd-networkd-wait-online.service(8)
 Main PID: 1354 (systemd-network)
   CGroup: /system.slice/systemd-networkd-wait-online.service
           └─1354 /lib/systemd/systemd-networkd-wait-online

Im Hinblick auf

Wenn keine Fehler berichtet werden, für den nächsten Boot aktivieren, ansonsten zuerst die Fehler beheben:
CODE: ALLES AUSWÄHLEN
systemctl enable systemd-networkd.service
systemctl enable systemd-networkd-wait-online.service
systemctl enable systemd-resolved.service

habe ich dann abgebrochen und die letztzitierten "enable" nicht eingegeben

[gambit]

heisst das nach Kaltstart (?) und ohne NWM (?) und ohne dass die grüne Lampe zuvor brennt(?) werde ich noch eingeben und berichten

Der Befehl soll die Lampe grün machen ... also wär's gut, wenn sie vorher nicht grün ist

Und schau mal nach, ob es für deine Fritzbox eine neuere Firmware gibt. Das sollte recht problemlos über die Weboberfläche der Fritzbox gehen.

Nein, gibt es nicht. Hab ich auch nochmal auf der Seite von AVM geprüft.

Hinsichtlich des Motherboards stelle ich die Firmwarefrage zurück, bis ich den Ansatz von TomL abgearbeitet habe. Und wenn das keine Lösung bringt, versuche ich den Ansatz von mat6937. Sonst springe ich zu sehr zwischen den unterschiedlichen Ansätzen. Ich blicke so schon kaum durch. Erst dann überlege ich die Firmwarefrage nochmal, da habe ich ohnehin Manschetten.

[NAB]

Joa, sehe ich genau so. Mich würd erst mal interessieren, ob mit "ethtool" die grüne Lampe angeht.

[TomL]

Es hakt an folgender Stelle.

Code: Alles auswählen

# systemctl start systemd-networkd-wait-online.service

Dort passiert nach Eingabe des Startbefehls minutenlang nichts. Er akzeptiert den Befehl, aber der Cursor springt nur in eine neue Zeile und nicht passiert weiter.

Nee, es hakt gar nicht, es sieht doch alles gut aus. Schade, das Du abgebrochen hast, denn ich habe erst mal keinen Fehler gesehen. Und ich hätte gerne gewusst, ob nach den Dienste-Starts das Netzwerk verfügbar ist.

Also, mit diesem Befehl startest Du nur einen bestimmten Service, dessen Verwendung für Dich an dieser Stelle erst mal noch nicht so richtig wichtig ist. Wichtig ist nur, wenn beim Start keine Fehlermeldung kommt, war das schon mal gut.

Code: Alles auswählen

systemctl start systemd-networkd-wait-online.service

Und nun kannst Du den Status dieses Dienstes überprüfen:

Code: Alles auswählen

systemctl status systemd-networkd-wait-online.service

Wenn da in grün "active" steht und keine Fehler gemeldet werden, dann war das perfekt.... und dieser Dienst ist "gebrauchsfertig" für den späteren "enable" für den Bootvorgang

Das gleiche gilt für

Code: Alles auswählen

systemctl start systemd-networkd

Es wird damit nur ein bestimmter Dienst gestartet (hier das Netzwerk), dessen Status du auch nach dem Start sofort mit

Code: Alles auswählen

systemctl status systemd-networkd

überprüfen kannst. Und wenns auch hier ein grünes "acitve" und keine Fehlermeldungen gibt, und du auch noch eine Netzverbindung hast, dann ist Dein Problem gelöst. Und du kannst auch diesen Dienst "enablen", damit er beim nächsten Kaltstart automatisch gestartet wird.

Aber wie gesagt, nur der Start des Dienstes gibt keine Meldung, allenfalls die, dass es vielleicht wegen Fehlen der Service-Unit gar nicht gestartet werden konnte. Das wäre jetzt spannend gewesen zu erfahren, ob das Netzwerk direkt von Systemd gestartet Deinen Fehler behoben hätte.

Das sieht alles gut aus und das Netzwerk müsste verfügbar sein. Und wenn davor ein Kaltstart war, ist das Problem gelöst.

Code: Alles auswählen

# systemctl status systemd-networkd systemd-resolved systemd-networkd-wait-online
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled)
   Active: active (running) since Mi 2016-05-11 21:21:11 CEST; 5min ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 1351 (systemd-network)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-networkd.service
           └─1351 /lib/systemd/systemd-networkd

Mai 11 21:21:11 seneca systemd-networkd[1351]: lo              : gained carrier
Mai 11 21:21:11 seneca systemd-networkd[1351]: eth0            : link configured

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled)
   Active: active (running) since Mi 2016-05-11 21:18:55 CEST; 7min ago
     Docs: man:systemd-resolved.service(8)
 Main PID: 1345 (systemd-resolve)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-resolved.service
           └─1345 /lib/systemd/systemd-resolved

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; disabled)
   Active: activating (start) since Mi 2016-05-11 21:22:00 CEST; 4min 46s ago
     Docs: man:systemd-networkd-wait-online.service(8)
 Main PID: 1354 (systemd-network)
   CGroup: /system.slice/systemd-networkd-wait-online.service
           └─1354 /lib/systemd/systemd-networkd-wait-online

[gambit]

Joa, sehe ich genau so. Mich würd erst mal interessieren, ob mit "ethtool" die grüne Lampe angeht.

Nein,

Code: Alles auswählen

ethtool -r eth0

habe ich soeben mehrfach probiert

[NAB]

Na gut ... wär ja auch zu einfach gewesen.

Dann schau dich mal in der Weboberfläche deiner Fritzbox um, ob du da was findest, um die LAN-Anschlüsse von "automatisch" auf "immer aktiv" umzustellen.

[gambit]

Es hakt an folgender Stelle.

Code: Alles auswählen

# systemctl start systemd-networkd-wait-online.service

Dort passiert nach Eingabe des Startbefehls minutenlang nichts. Er akzeptiert den Befehl, aber der Cursor springt nur in eine neue Zeile und nicht passiert weiter.

Nee, es hakt gar nicht, es sieht doch alles gut aus. Schade, das Du abgebrochen hast, denn ich habe erst mal keinen Fehler gesehen. Und ich hätte gerne gewusst, ob nach den Dienste-Starts das Netzwerk verfügbar ist.

Also, mit diesem Befehl startest Du nur einen bestimmten Service, dessen Verwendung für Dich an dieser Stelle erst mal noch nicht so richtig wichtig ist. Wichtig ist nur, wenn beim Start keine Fehlermeldung kommt, war das schon mal gut.

Code: Alles auswählen

systemctl start systemd-networkd-wait-online.service

Und nun kannst Du den Status dieses Dienstes überprüfen:

Code: Alles auswählen

systemctl status systemd-networkd-wait-online.service

Wenn da in grün "active" steht und keine Fehler gemeldet werden, dann war das perfekt.... und dieser Dienst ist "gebrauchsfertig" für den späteren "enable" für den Bootvorgang

Ja, aber der Dienst stand doch nicht auf "active", sondern auf "activating":

● systemd-networkd-wait-online.service - Wait for Network to be Configured
Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; disabled)
Active: activating (start) since Mi 2016-05-11 21:22:00 CEST; 4min 46s ago
Docs: man:systemd-networkd-wait-online.service(8)
Main PID: 1354 (systemd-network)
CGroup: /system.slice/systemd-networkd-wait-online.service
└─1354 /lib/systemd/systemd-networkd-wait-online

Und da tat sich dann minutenlang nichts. Ich habe

Code: Alles auswählen

systemctl start systemd-networkd-wait-online.service[

dann mit Strg+C abgebrochen und den Status-befehl eingegeben.

[TomL]

Ja, aber der Dienst stand doch nicht auf "active", sondern auf "activating":

Himmel.... ich bin oberflächlich.... das hätte ich sehen müssen... aber ich hatte mich gefreut, dass das so gut aussah. Tja, an dem Punkt bin ich mit meinem Latein am Ende. Ich hatte gehofft, dass das ebenso einfach funktioniert, wie ich das gewohnt bin, weil ich mit Debian und systemd egal bei welcher Hardware noch nie auf Probleme gestossen bin. Aber vielleicht ist in Bunsenlabs doch noch irgendwie etwas anders.... oder es ist wirklich was mit der Hardware.

Ich sag dann mal... viel Glück bei der Lösungssuche.... und vielleicht beteiligt sich noch jemand mit mehr Kenntnissen, als ich sie habe....

[mat6937]

Und da tat sich dann minutenlang nichts. Ich habe

Code: Alles auswählen

systemctl start systemd-networkd-wait-online.service[

dann mit Strg+C abgebrochen und den Status-befehl eingegeben.

Dann versuch mal erneut als Test, nur mit folgender geänderter eth0.network-Datei:

Code: Alles auswählen

[Match]
Name=eth0

[Network]
DHCP=none
IPv4LL=false
Address=192.168.178.9/24
Gateway=192.168.178.1
DNS=192.168.178.1
NTP=192.168.178.1

D. h., ohne DHCP und mit statischer IP-Adresse.

[gambit]

Ich sag dann mal... viel Glück bei der Lösungssuche....

Thomas, vielen Dank nochmal für die ganze Mühe!
Vielleicht bekommst Du ja mit, was im Ergebnis rauskommt.

gambit

[gambit]

Und da tat sich dann minutenlang nichts. Ich habe

Code: Alles auswählen

systemctl start systemd-networkd-wait-online.service[

dann mit Strg+C abgebrochen und den Status-befehl eingegeben.

Dann versuch mal erneut als Test, nur mit folgender geänderter eth0.network-Datei:

Code: Alles auswählen

[Match]
Name=eth0

[Network]
DHCP=none
IPv4LL=false
Address=192.168.178.9/24
Gateway=192.168.178.1
DNS=192.168.178.1
NTP=192.168.178.1

D. h., ohne DHCP und mit statischer IP-Adresse.

Das werde ich ebenso probieren, wie einige andere Lösungsaspekte von Dir, die ich zurückgestellt hatte, um wenigstens ein bisschen systematisch vorzugehen und dann berichten. Vielen Dank.