Kein Adapter vorhanden konnte ich auch schon mit nicht erreichbarem mount provozieren. Also die Box bootet, wartet auf das timeout des mounts und danach geht es weiter. Das Netzwerk war dann ziemlich zuverlässig nicht da
DreamOS - DM900: Manchmal kein Netzwerk nach einem reboot
-
-
so, ich muss jetzt wohl den "Canossagang" antreten - zumindest mein "connection failed" war hausgemacht, obwohl ich das ausschliesen wollte
Es wurde durch mein von @obi zitiertes onreboot.service aus Post #18 verursacht. Es war im derzeitigen Image noch aktiv und nach dem disablen bootete die box gut 120-150x ohne Netzwerkfehler durch.
Ich hatte Anfang des Jahres mit systemd rumgespielt und das von mir erstellte onreboot.service wohl vergeigt. Ich hab' dann im März oder April die Box ohne settings restore neu geflasht und komplett neu aufgebaut. Das onreboot.service war eine Spielerei und habe ich danach auch nicht wieder (absichtlich) eingebaut. Ging ne Weile gut und im Juni oder Juli fingen die Probleme wieder an.
Wenn ich ein anderes Image teste oder wechsle, flashe ich immer neu oder spiele ein backup ein. Ich vermute jetzt mal, dass ich beim restore ein backup erwischt habe, dass das aktive onreboot.service noch enthielt. Da ich immer den selben Skin verwende und die installierten plugins, settings, scripte, networkshares etc. ident sind ist mir das nicht aufgefallen. Der Inhalt von /root, /usr/script, /usr/local sind bei mir in jedem Image ident bzw. aktuell, weil die Ordner auf der SD-Card liegen und ich die per bind mount über die fstab ins Image einbinde.
Kurze Rede langer Sinn: wirklich dumm gelaufen und durch etwas verursacht, wass ich eigentlich ausschliesen wollte und ich habe die ganze Zeit mit einem korrupten image getestet. Zu meiner Verdeitigung muss ich sagen, dass das mit einem "nackten" experimental image auch einmal beim Gegentest passiert ist, aber das könnte auch durch den von @dre erwähnten nicht erreichbaren mount verursacht worden sein.
obi: danke für den hint der, wenn auch indirekt, das Problem wohl gelöst hat. Mir war das bei dem Journalgestöbere nicht (mehr) aufgefallen
@all: sorry für den Wirbel
-
Hi,
also bei mir gibt es weder das onreboot.service noch irgendwelche mounts.
-
Jeder zusätzlich zum originalen Image installierte service kann das Problem verursachen, wenn da was nicht stimmt. Daher müsstest du solche auch mal disablen. Ebenso können scripts, die aus der vor systemd-Zeit stammen und übernommen wurden, Probleme machen
-
so, ich muss jetzt wohl den "Canossagang" antreten - zumindest mein "connection failed" war hausgemacht, obwohl ich das ausschliesen wollte
Es wurde durch mein von @obi zitiertes onreboot.service aus Post #18 verursacht. Es war im derzeitigen Image noch aktiv und nach dem disablen bootete die box gut 120-150x ohne Netzwerkfehler durch.
Schön, dass wir helfen konnten.
Dass man manchmal den Wald vor lauter Bäumen nicht sieht, ist normal und passiert uns Allen.
Von daher viel Spass mit der "netzwerkenden Dreambox" -
It was caused by my @obi cited onreboot.service from Post # 18. It is still active in the current image and after the box is booted 120-150x without network error.
Nice that we could help.
opposite Reichi i can't see what exact problem is here,
maximum, when it can be repeatedhave never used `onreboot.service`
-
Jeder zusätzlich zum originalen Image installierte service kann das Problem verursachen, wenn da was nicht stimmt. Daher müsstest du solche auch mal disablen. Ebenso können scripts, die aus der vor systemd-Zeit stammen und übernommen wurden, Probleme machen
Hi,
wissentlich habe ich nur einen „service“ installiert für das über was hier aber nicht weiter diskutiert wird. Und Scripte gibt es in meinem /usr/script Verzeichnis keine. Wie gesagt es trat bei mir auch auf einem frisch installierten Image auf, ist zwar jetzt schon eine Weile her.
Es ist ja auch nicht so das es jeden Tag Auftritt aber wenn es passiert ist es immer ein schlechter Zeitpunkt. -
Hi,
also bei mir gibt es weder das onreboot.service noch irgendwelche mounts.
opposite Reichi i can't see what exact problem is here,maximum, when it can be repeated
have never used `onreboot.service`
The onreboot.service does not exist in any official image. This service was created by myself and had a mistake in it, which causes the inactive network services on bootup - some times, but not every time.Maybe you also added an own defined sytemd unit or outdated init.d startscript which causes your problem.
This is what @dre or @Reichi meant.
I created this fu***ing onreboot service, because the string "@reboot" in a crontab does not work when using busybox-cron (init.d startscript !!! - another bug in DreamOS ). Adding the command into the rc.local started my wished "service" to late. Also the init.d startscript did not work as designed.
So I created the (buggy) onreboot.service - the result is documented in this threat ..
-
what i have wrote, i have had inactive network also without onreboot.service
but during last year i just avoiding deep standby cause this lottery
and also cause one of ten times box freezes with blinking red after deep standby or reboot -
solved?
came after reboot not deep standby
network ok after second rebootBash
Alles anzeigenroot@dm900:~$ ping 10.0.10.1 PING 10.0.10.1 (10.0.10.1): 56 data bytes 64 bytes from 10.0.10.1: seq=0 ttl=128 time=0.412 ms 64 bytes from 10.0.10.1: seq=1 ttl=128 time=0.566 ms 64 bytes from 10.0.10.1: seq=2 ttl=128 time=0.405 ms ... ... ... 64 bytes from 10.0.10.1: seq=59 ttl=128 time=0.469 ms 64 bytes from 10.0.10.1: seq=60 ttl=128 time=0.474 ms ^C --- 10.0.10.1 ping statistics --- 61 packets transmitted, 61 packets received, 0% packet loss round-trip min/avg/max = 0.328/0.997/8.700 ms root@dm900:~$
-
My network watchdog is still running as a backup for the worst case. No automatic reconnect after "connection failed" until yet.
The watchdag creates a journal dump for further information on a non-volatile memory to be available after a needed reboot (if configured). That was the second idea of this script beside the automatic try to reconnect
"Not connected" could be to litte information to solve any bug ...
-
Bash
Oct 23 21:42:28 dm900 - network watchdog: network connection not ok! ping failed Oct 23 21:42:28 dm900 - network watchdog: dump journal to /media/hdd/network_journal.log Oct 23 21:42:28 dm900 - network watchdog: restart socket.target and connman.service Oct 23 21:42:29 dm900 - network watchdog: network connection not ok! ping failed Oct 23 21:42:29 dm900 - network watchdog: dump journal to /media/hdd/network_journal.log Oct 23 21:42:29 dm900 - network watchdog: restart socket.target and connman.service Oct 23 21:42:30 dm900 - network watchdog: network connection not ok! ping failed Oct 23 21:42:30 dm900 - network watchdog: dump journal to /media/hdd/network_journal.log Oct 23 21:42:30 dm900 - network watchdog: restart socket.target and connman.service Oct 23 21:42:31 dm900 - network watchdog: network connection ok
-
Code
Oct 23 21:42:28 dm900 rc.local[266]: Failed to restart socket.target: Unit socket.target not found. Oct 23 21:42:29 dm900 rc.local[266]: Failed to restart conmann.service: Unit conmann.service not found.
there were to typing mismatches in the old script - you have to correct line 20 an and 22 of the script from post #18 to restart the network sucessfullyplease try to restart the connman.serverice only first (without sockets.target)
-
Hi,
dieser kleine Fehler (Zeile 20 und 22) im Script waren bei mir auch noch vorhanden. Deshalb war wahrscheinlich ab und zu mal kein Netzwerk vorhanden trotz der Überwachung.
-
-
Hi,
dieser kleine Fehler (Zeile 20 und 22) im Script waren bei mir auch noch vorhanden. Deshalb war wahrscheinlich ab und zu mal kein Netzwerk vorhanden trotz der Überwachung.
ja, sorry dafür - dumm gelaufen
vermutlich hatte ich eine ätere File Version im Filezilla Client offen, aus dem ich den Code kopierte. Mir war gleich beim Testen gleich aufgefallen, das der code buggy war. Solche "kleine" Änderungen mache ich aber immer mit vi direkt auf der Box - aber dann sollte man auch den Inhalt im FTP Editor refreshen ..
-
Hi,
heute habe ich nochmals das Script testen wollen aber leider bootet die 7080hd jetzt in Dauerschleife. Es wird kein crashlog gespeichert. Selbst nach dem löschen vom Script und der rc.local bootet die Box munter weiter in Dauerschleife. Es hilft dann nur der Netztschalter.
-
an alle und speziell an @latte0815 (von dem weiß ich, dass das Problem weiterhin noch besteht)
Es ist zwar nur eine Vermutung aber ein Versuch wäre es wert:
Falls es nach wie vor manchmal passiert, dass die box nach einem reboot kein Netzwerk hat, disabled mal testweise Ahavi auf euren Boxen
Es könnte sein, dass mit diesem workaround das Problem nicht mehr auftritt.
Wie ich darauf komme?
Ich konnte keine WiFi Verbindung auf meiner Box herstellen, verantwortlich dafür war zumindest hier in meiner Netzwerkumgebung der Ahavi Daemon -> [DreamOS] WiFi Konfiguration kaputtNach dem disablen von Avahi war alles wieder gut. Bei meinen Anstrengungen das Problem zu lokalisieren, fiel mir auch auf, das mein LAN Adapter auch mal eine link local DHCP IP bezogen hat, obwohl ich manuell eine feste IP vergeben habe.
/var/lib/connman/ethernet_000934xxxxx_cable/settings
CodeIPv4.method=manual IPv4.DHCP.LastAddress=169.254.40.210 IPv4.local_address=192.168.100.78 IPv6.method=off
Es ist wie gesagt nur eine vage Vermutung, dass der Avahi Deamon unter bestimmten Umständen dafür verantwortlich ist. Wenn nicht, kann man ja wieder alles rückgängig mac hen
-
sorry if its maybe oftoppic
maybe its also related to my bug its in Network.py it can crash the complete network manager to greenscreen and its only if ipv6 is enabled in the network dhcp server
i can fix this with commenting out a specific else tree
than all is fine ipv6 also -
During my tests to configure the WiFi the Networkmanager never crashed to a greenscreen.
To disable the avahi daemon is a possible workaround to fix the problem, that some boxes have no working network after a reboot sometimes.
But you can disable the avahi daemon if it's not needed in your network environment - and it's easy to enable it again as posted