Welches Image für Cubietruck? - Abstuerze / Freeze mit aktuellen Armbian Image

[Wuppi68]

meine beiden Curies laufen noch ....

8 + 9 Tage ...

noch ein paar Tage und ich kann 2 von den Dingern wieder in die Produktivumgebung installieren

[Klaus.A]

Heute doch wieder ein Freeze -> WatchDog -> Reboot. Nach 12 Tagen, keine Systematik erkennbar, keine erkennbaren Probleme vor dem Freeze.

Aktueller Stand beider Systeme:

Cubietruck #1 mit IoBroker: 61 Tage ohne Probleme.
Cubietruck #2 mit FHEM: Problem diesmal nach 12 Tagen.

System 2 war noch nicht neu aufgesetzt. Das kommt demnächst dran, dann sehen wir mal weiter.

Gruß, Klaus

[Wuppi68]

Heute doch wieder ein Freeze -> WatchDog -> Reboot. Nach 12 Tagen, keine Systematik erkennbar, keine erkennbaren Probleme vor dem Freeze.

Aktueller Stand beider Systeme:

Cubietruck #1 mit IoBroker: 61 Tage ohne Probleme.
Cubietruck #2 mit FHEM: Problem diesmal nach 12 Tagen.

System 2 war noch nicht neu aufgesetzt. Das kommt demnächst dran, dann sehen wir mal weiter.

Gruß, Klaus

Hallo Klaus,

meine beiden Cubies laufen auch noch Nächste Woche werden die wieder Produktiv eingesetzt

kannst Du mal bitte die Konfig vom Watchdog hier posten? Bei mir will der nicht

Gruß und Dank

Ralf

[Norberto]

Status meiner Test-Systeme:

Anzahl Test-Systeme: 2

Debian: Ambian 5.75 / 4.19.20-sunxi

Einstellungen in /etc/default/cpufrequtils:
  MIN_SPEED=912000
  MAX_SPEED=912000
  GOVERNOR=conservative

Medium: SD (nur temporär während Test, produktiv auf SSD)

Start des Tests:  12. März

** Ergebnis:

Cubietruck #1: 0 Reboot in 16 Tagen
  FHEM Installation, CPU temp = 37°C

Cubietruck #2: 5 Reboots in 16 Tagen
  keine Last, CPU temp = 33°C

Cubietruck #1 lief vorher mit einem 3.x Kernel 4 Jahre ohne Probleme.
Cubeitruck #2 ist vor den speed Anpassungen mit dem neuen Kernel ebenfalls alle 2-3 Tage abgestürzt.
Ich nehme am WE einen 3. Cubietruck in Betrieb.

grüße,
Norberto

[doesel]

Mein Cubietruck läuft mit ARMBIAN 5.31 stable Debian GNU/Linux 9 (stretch) 4.11.5-sunxi seit ca. einem Jahr ohne Probleme. Allerdings mache ich auch in gewissen Abständen z.B nach einem apt upgrade ein Reboot (ca. alle zwei Monate). Das aktuelle Armbian auf einem weiteren Cubie hat regelmässig Abstürze gehabt und wurde nun in Rente geschickt.
Doesel

[Norberto]

Hallo Doesel,

ich kann keine Quelle für Armbian 5.31 mehr finden. Hast Du einen Link oder ein Image welches Du teilen kannst?

Grüße,
Norberto

[doesel]

Tut mir leid, die Installation ist schon lange her, das Image habe ich nicht mehr.
Gruß Doesel

[tpm88]

Mir geht es ganz ähnlich. Ich habe einen Cubietruck, der unter Armbian 5.60, Debian Jessie und Kernel 3.4.113 absolut stabil läuft (eben bei 144 Tagen Uptime).

Ein zweiter CubieTruck, den ich als Backup angeschafft hatte, ist leider äußerst instabil. Mit neueren Armbian Images funktioniert meist nicht einmal ein kompletter Boot Vorgang, obwohl Stromversorgung und SD-Karte von guter Qualität sind.

Ich habe noch zwei alte Armbian Images aufgehoben - leider kein "frühes" mit Debian Stretch. Bereitstellen könnte ich:
- Armbian 5.20 Debian Jessie mit Kernel 4.7.3
- Armbian 5.25 Debian Jessie mit Kernel 3.4.113

Gruß
Tobias

[Navigator]

Ich bin jetzt auch dabei zu testen. Ich muss endlich von Wheezy 3.4.103-sun7i+ weg. Dort kann ich weder Upates fahren noch ein neueres Nodejs kompilieren. Die beiden Cubies waren nach Anpassungen der CPU Governor absoloute "Fire and Forget" Server und laufen seit 2014 im Nand ohne Probleme. Aber jetzt muss ich mal dran obwohl ich mich dem immer verweigert habe.
Der Nand ist ja eh Geschichte und ich fand den Backup Prozess vom diesem auch zu aufwändig und langwierig zugleich.
Ich hab mir jetzt das aktuellste "Armbian_5.75_Cubietruck_Debian_stretch_next_4.19.20" hergenommen und verwende gleich die alten Governor Einstellungen. Scheinbar gab es auch bei den Cubies unterschiedliche Versionen in Bezug auf den Speicherhersteller und damit Probleme mit den Timings.
Ich starte den Langzeit -Stabilitätstest mit SD in Kombi mit SSD ...... jetzt. 

Update: läuft bisher stabil ( 30 Tage) , keine Abstürze oder ähnliches.
Rootfs auf SSD
CPU Governor:
  MIN_SPEED=480000
  MAX_SPEED=960000

[Clyde]

Bin gerade über diesen Fred gestolpert und habe deshalb mal in die Ordner geschaut. Habe noch ein

Armbian_5.31_Cubietruck_Debian_jessie_next_4.11.5
Armbian_5.24_Cubietruck_Debian_jessie_next_4.9.5

gefunden, falls es wer brauchen kann.

[Klaus.A]

Aktueller Stand: Cubietruck mit Armbian und FHEM läuft wieder problemlos, jetzt seit 14 Tagen ohne Freezes.

Die Lösung dieser Freeze-Probleme ist sicher für jede Installation/Konfiguration unterschiedlich. Bei mir war es die DNS-Auflösung - gefunden mehr durch eine mehr intuitive Änderung. Alle verfügbaren Tools und Prozeduren hatten nicht zu einer Erkenntnis geführt wer für die Freezes verantwortlich sein könnte. In einer anderen Diskussion kam das Thema "DNS" zur Sprache.

Ich habe im lokalen Netz einen DNS-Server laufen. Die Einstellung

Code Auswählen Erweitern

attr global dnsServer xxx.xxx.xxx.xxx

verweist auf die IPv4-Adresse meines DNS-Servers. Das war's - keine Disconnects der IOs mehr (1 x HMLAN, 3 x HM-LGW-O-TW-W-EU), keine Freezes (die per WatchDog einen Reboot ausgelöst hatten). Alles OK.

Ohne das globale dnsServer Attribut verwendet FHEM die Funktionen des Betriebssystems - und die sind blockierende Calls. Mit dem dnsServer-Attribut werden nicht-blockierende Aufrufe an den DNS Server verwendet (Aus einer anderen Diskussion gelernt).

Wo nun genau das Problem war muss ich noch erforschen. Der DNS-Server ist den Clients per DHCP bekannt gegeben, aber der Weg FHEM -> Armbian -> DNSServer funktioniert offensichtlich bei meiner Installation nicht korrekt. Das dnsServer Attribut in FHEM hat das Problem erst mal komplett gelöst.

Gruß, Klaus

[Clyde]

Der DNS-Server ist den Clients per DHCP bekannt gegeben,

Wo hast du das gemacht? Ich habe es bei mir in /etc/network/interfaces stehen.

Code Auswählen Erweitern


auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ap-scan 1
wpa-scan-ssid 1
dns-nameservers 192.168.2.1


[Klaus.A]

Gute Frage, guter Hinweis.

In meinem lokalen Netz werden normalerweise alle globalen Einstellungen im DHCP Server festgelegt, z.B. Default Gateway, DNS-Server und ggf. statische IP (mit Referenz auf die MAC-Adresse des Client). Wenn ein Client DHCP versteht dann holt er sich alle diese Einstellungen ab und ich kann das Netz zentral konfigurieren. Hat soweit auch immer funktioniert, mit allen bisherigen Clients.

In der Armbian-Config Einstellung unter Netzwerk kann man angeben ob die IP per DHCP oder statisch zugewiesen werden soll. Ich bin davon ausgegangen, das dann auch der DNS-Server entsprechend referenziert wird. Das ist aber scheinbar nicht der Fall, wie ich jetzt feststellen muss: Als DNS ist "8.8.8.8" und der Router eingetragen, aber nicht mein zentraler DNS Server. Möglicherweise war das der Grund für die Probleme. Der Router ist hier eine Fritz!Box, definitiv weniger performant als der dedizierte DNS Server. Wenn der Router mit Übertragungen beschäftigt war dann hatte DNS eine niedrigere Priorität, und dann gab es diese "Keep Alive zu spät gesendet" Meldungen bei den IOs oder "Freezes" bei anderen DNS-Auflösungen.

Die Netzwerkkonfiguration ist im Armbian per Netzwerkmanager geregelt, aktuelle Konfiguration in meinem Fall in "Wired connection1":

Code Auswählen Erweitern

/etc/NetworkManager/system-connections/Wired connection 1

"Wired connection1" ist die aktuelle verdrahtete Schnittstelle (eth0). Unter [ipv4] sehe ich dort die DNS-Einstellungen ... Das kann natürlich aus einem der früheren Armbian-Images gewesen sein. Ich müsste das System einmal komplett neu aufsetzen um zu sehen ob da einiges bereinigt wurde.

Wie auch immer, wenn es in FHEM Probleme mit DNS-Auflösungen gibt dann ist die FHEM dnsServer Einstellung eine Lösung. Verzögerungen im DNS haben zu Problemen geführt da mehrere FHEM Module häufig eine Namensauflösung benötigen, z.B. um Status-Infos abzurufen.

Die Konfiguration kann natürlich ein Einzelfall sein. Interessant und evtl. hilfreich ist aber die Wirkung der globalen FHEM dnsServer Einstellung.

Gruß, Klaus

[Franz Tenbrock]

Hallo
mein cubie läuft seit Jahrne ohne Probleme
da nur iim lokalen Netz nie updates gemacht
lief einfach
was  nun
gibts eine Schritt für schritt Anleitung irgendwo, oder besser alles so lassen
hab heute versucht ein update auf jessy zu machen, aber noch kein reboot

[Navigator]

Ein Update in dem man nur Paketlisten auf Jessy ändert geht beim Cubie so einfach nicht. Bei den neuern Armbian´s kommen die Kernel jetzt immer beim Update mit, bei den alten musste man da immer selbst Hand anlegen. Ich habe auch noch einen auf Whezzy laufen und einen anderen letztens auf Stretch gehoben. Also alles neu gemacht und am Ende ist das vielleicht auch die beste Lösung. Der Nand wird aber nicht mehr unterstützt, daß musst du bedenken. Also am besten in Zukunft von SD Booten und das RootFS auf ne SSD.