Autor Thema: Welches Image für Cubietruck? - Abstuerze / Freeze mit aktuellen Armbian Image  (Gelesen 5991 mal)

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2057
  • On the Highway to Shell
meine beiden Curies laufen noch ....

8 + 9 Tage ...

noch ein paar Tage und ich kann 2 von den Dingern wieder in die Produktivumgebung installieren ;-)
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Offline Klaus.A

  • Full Member
  • ***
  • Beiträge: 116
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
2 x CubieTruck mit 1) FHEM 5.9 und 2) IOBroker-mit Echo-Dot/Alexa und Homekit-/Siri-Integration. 1 x HMLAN, 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge, IRTrans IR-Konverter, AutoMower via API

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2057
  • On the Highway to Shell
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
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Offline Norberto

  • Full Member
  • ***
  • Beiträge: 136
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

Offline doesel

  • Full Member
  • ***
  • Beiträge: 129
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
(FHEM auf Cubietruck mit Igor-Image, 64GB SSD), seit März 19 FHEM auf NUC im Proxmox-Container, 240GB SSD, div. Homematic, Max Fensterkontakte, Onewire über Firmata und FHEM2FHEM auf Raspberrys, MySensors, Jeelink-Clone mit GSD-Modul, CUL, SDM220Modbus, Logo!8, WS980WiFi

Offline Norberto

  • Full Member
  • ***
  • Beiträge: 136

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

Offline doesel

  • Full Member
  • ***
  • Beiträge: 129
Tut mir leid, die Installation ist schon lange her, das Image habe ich nicht mehr.
Gruß Doesel
(FHEM auf Cubietruck mit Igor-Image, 64GB SSD), seit März 19 FHEM auf NUC im Proxmox-Container, 240GB SSD, div. Homematic, Max Fensterkontakte, Onewire über Firmata und FHEM2FHEM auf Raspberrys, MySensors, Jeelink-Clone mit GSD-Modul, CUL, SDM220Modbus, Logo!8, WS980WiFi

Offline tpm88

  • Full Member
  • ***
  • Beiträge: 403
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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

Offline Dittel

  • Sr. Member
  • ****
  • Beiträge: 536
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
« Letzte Änderung: 11 Mai 2019, 08:35:14 von Dittel »
Cubietruck,HMUSB,RFX,CUL,HUE,EchoDot,LMS,Squeezebox

Offline Clyde

  • Full Member
  • ***
  • Beiträge: 126
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.
2x Cubietruck, CUL868, HM-USB-CFG2
FS20, FHT, KS300, HM, MAX, Tradfri

Offline Klaus.A

  • Full Member
  • ***
  • Beiträge: 116
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

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


2 x CubieTruck mit 1) FHEM 5.9 und 2) IOBroker-mit Echo-Dot/Alexa und Homekit-/Siri-Integration. 1 x HMLAN, 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge, IRTrans IR-Konverter, AutoMower via API

Offline Clyde

  • Full Member
  • ***
  • Beiträge: 126
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.

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ap-scan 1
wpa-scan-ssid 1
dns-nameservers 192.168.2.1
2x Cubietruck, CUL868, HM-USB-CFG2
FS20, FHT, KS300, HM, MAX, Tradfri

Offline Klaus.A

  • Full Member
  • ***
  • Beiträge: 116
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":

/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

2 x CubieTruck mit 1) FHEM 5.9 und 2) IOBroker-mit Echo-Dot/Alexa und Homekit-/Siri-Integration. 1 x HMLAN, 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge, IRTrans IR-Konverter, AutoMower via API

 

decade-submarginal