Am 11.05.2015 um 21:08 schrieb Johannes Kapune:
was sagt den ein: systemctl restart network.service
bzw. systemctl status network.service
?
Johannes
Am 11.05.2015 um 20:47 schrieb Michael:
Am 11.05.2015 um 20:29 schrieb Manfred Kreisl:
Hallo Michael,
Am 11.05.2015 um 20:07 schrieb Michael:
Hallo Liste,
ich habe Opensuse 13.2 64 Bit, aktuelle Patches sind installiert. Rechner hÀngt am LAN (kein WLAN vorhanden). Seit 3 Tagen habe ich folgenden Fehler:
Nach jedem Ausschalten ist nach dem nÀchsten Start das Netzwerk Interface "enp3s0" weg (also was frÃŒher eth0 hieÃ). Mit ifconfig wird nur noch "lo" angezeigt. Auch ein mehrmaliges Reboot bringt es nicht zurÃŒck.
Es hilft jedoch folgendes:
- ein Àlteres OS booten (das ich auf einer anderen Partition habe) oder
- booten von Life-CD (z. B. OS 13.2)
Danach wieder mit reboot mein OS 13.2/64 starten ... und schon ist "enp3s0" wieder vorhanden.
Das Verhalten tritt auf, egal ob ich NetworkManager oder wicked service verwende. Ich verwende kein DHCP sondern eine feste IP aus meinem Heimnetz (192.168.x.x)
Ich habe gehofft, googlen wÌrde einen bekannten Bug anzeigen. Habe aber nichts gefunden. Was könnte der Grund sein? Und wie behebe ich den Fehler, so dass ich diesen nervigen Workaround nicht mehr brauche? Ich freue mich Ìber jeden Hinweis.
Hoffentlich gebe ich jetzt keine security relevanten Infos preis... hwinfo zeigt folgendes an: Hast Du schon mal fÃŒr kurze Zeit den Rechner komplett vom Stromnetz getrennt? Klingt fÃŒr mich nach einem undefinierten Zustand des Netzwerkcontrollers, den der Kernel nicht beheben kann
Gruà Manfred Ja, ich schalte ihn beim Ausschalten immer stromlos (Steckerleiste mit Schalter).. Aber warum kann dann ein anderes OS den Zustand des Netzwerkcontrollers beheben??? VG, Michael
Hallo zusammen, ich hatte die beiden letzten Abende leider keine Zeit in meine mails zu schauen, und war jetzt über die rege Diskussion erstaunt. Vielen Dank an alle, die sich beteiligt haben. Ich antworte jetzt mal gemeinsam auf alles, was ich bisher so an Fragen gefunden habe und füge noch ein paar weitere Infos dazu: - ich habe den Rechner seit knapp 2 Jahren, immer mit OpenSuse. Keine Probleme mit dem Netzwerk. - OS 13.2 habe ich seit einigen Monaten, ebenfalls bisher keine Probleme mit dem Netzwerk. Außer dass der NetzworkManager kein Netz bekam, wenn beim Booten der Switch nicht eingeschaltet war (dieser hängt an einer anderen Steckerleiste, die ich manchmal vergesse einzuschalten) - Ich weiß nicht ob das Motherboard WLAN kann, ich vermute aber nicht, weil mir auch yast nichts anbietet. Es ist ein Stand-PC, der immer am Netzwerkkabel hängt, so dass WLAN nicht gebraucht würde, selbst wenn es vorhanden wäre. - Umschalten zwischen wicked und NetworkManager mache ich mit yast. Da sollten doch anschließend keine weiteren Konsolen-Befehle nötig sein!? - Ich verwende schon immer eine feste IP (kein DHCP). - Das Kabel ist (permanent) fest eingerastet und wackelt nicht. - Ausgabe zu der Frage weiter oben: systemctl status network.service wicked.service - wicked managed network interfaces Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled) Active: active (exited) since Wed 2015-05-13 19:38:44 CEST; 36min ago Main PID: 1119 (code=exited, status=0/SUCCESS) CGroup: /system.slice/wicked.service May 13 19:38:44 linux-lzm4 wicked[1119]: lo up May 13 19:38:44 linux-lzm4 wicked[1119]: enp3s0 up - Was mich am meisten irritiert, ist dass es (bisher) nach Booten der Life-CD immer wieder geht. Wenn das nicht der Fall wäre, würde ich sofort einen Hardware Fehler auf dem Motherboard annehmen, auf dem die RJ45 Buchse montiert ist. Noch 2 neue Fragen als Anregung für die Lösungsfindung: a) Welchen alternativen Treiber könnte ich eurer Meinung mal ausprobieren? Der r8168 wird vermutlich älter sein ... b) Ich kann mich nicht erinnern, dass der Fehler nach direkt einem Update aufgetreten ist? Aber möglich wäre es schon.. Ich habe die Dateien ./lib/modules/3.16.7-21-desktop/kernel/drivers/net/ethernet/realtek/r8169.ko ./lib/modules/3.16.7-7-desktop/kernel/drivers/net/ethernet/realtek/r8169.ko Kann man irgendwie einfach feststellen, ob die sourcen wirklich verändert wurden, oder nur für den neuen Kernel neu kompiliert wurden? Wenn es die gleichen Sourcen sind, ist die Wahrscheinlichkeit etwas höher, dass es kein Bug im Treiber ist, denn bisher ging ja immer alles. Es sei denn, er tritt erst in Verbindung mit einem neuen feature im neuen Kernel auf. Danke euch! Michael -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org