Hallo,
Mein Cubietruck lief seit 2014 stabil ohne einen einzigen Absturz/Freeze immer noch auf der Basis Cubiiez (Debian 7.5 mit Kernel 3.4.xx) auf SSD.
Inzwischen kann ich dieses alte System leider nicht mehr über apt-get updaten, es gibt diverse Probleme mit der Paketverwaltung welche ich als Nicht-Linux-Experte nicht gelöst bekomme.
Alle Versuche mit den diversen aktuellen Armbian Images führen zu Abstürzen / Freeze von direkt beim Booten bis max nach 5 Tagen auf zwei unterschiedlichen Cubietrucks. Anpassungen in /etc/default/cpufrequtils helfen nichts. Diverse Netzteile ändern auch nichts. Das alte Image von 2014 läuft weiter absturzfrei.
Ich finde ähnlichte Berichte hier im Forum über das alte Igor Image und auch im Netz im Armbian-Forum.
Hat jemand eine Empfehlung für ein aktuelles 'absturzfreies' Image ?
Grüße,
Norberto
Da hänge ich mit dran. Habe inzwischen zwei Cubietruck in der Schublade liegen, weil sie nicht mehr ordentlich laufen. Bin beim Ausfall des ersten schon auf einen NUC umgestiegen. Suche auch nach einem aktuellen Image.
Die letzten Experimente habe ich mit Cubieez gemacht. (http://cubieboard.org/2013/12/21/a-debian-image-for-cubieboard2-cubieez/) ist aber auch nicht mehr ganz aktuell.
Gruss
Enno
I
Hallo zusammen,
zu dem Problem habe ich folgenden Stand:
Auf einem Cubietruck lief FHEM mehr als 5 Jahre problemlos mit Cubieez, Wheezy, Jessie (SSD am Cubietruck).
Seit einem FHEM-Update im Dezember 2018 gab es Freezes und Abstürze. Ich dachte zuerst die SSD sei defekt, dem war aber nicht so.
Ich habe einen 2. Cubietruck aufgesetzt um irgendwelchen Hardware-Defekte auszuschließen. Aufgesetzt mit aktuellem Armbian Image - wieder Freezes und Abstürze im Abstand von 3 bis 9 Tagen.
Aktuelle Konfiguration:
Cubietruck 1 mit Armbian und IOBroker (Anbindung von Alexa und Siri, Homekit)
Cubietruck 2 mit Armbian und FHEM (sonst nichts, System auf das Notwendigste reduziert)
Beide Systeme kommunizieren miteinander (IOBroker mit FHEM).
System 1 läuft ohne Probleme.
System 2 hat wieder Freezes.
Der (Hardware-) Watchdog des Cubietruck ist aktiviert und startet das System neu wenn es einen Freeze gibt. Das funktioniert als Notlösung, ist aber auf Dauer nicht ok.
Wenn FHEM neu startet, dann synchronisiert sich IOBroker wieder korrekt mit FHEM. Das System 1 hat also keinerlei Probleme.
Für mich sieht es so aus, das die Freezes durch Funktionen ausgelöst werden, die FHEM in Armbian (bzw. in der Perl-Lib) nutzt. Dazu gibt es bereits andere Diskussionen, bisher mit Raspi, noch nicht mit Cubietruck. In den Logs ist nichts zu finden was auf die Ursache hinweisen könnte.
Fakt ist auch das vor Auftreten eines Freeze andere Dinge falsch laufen - wie wenn das Memory-Management fehlerhaft wäre und (Daten-) Bereiche überschrieben werden. Das ist allerdings mehr spekulativ, bisher nicht genauer zu erkennen.
Gruß, Klaus
Das kann ich bestätigen. Mein Cubietruck mit Armbian (Stretch) läuft neuerdings höchstens einen Tag durch, danach ist er einfach aus. Bin seit vor paar Tagen auf einen NUC umgestiegen. Hier läuft FHEM in einem Proxmox Container bisher absolut problemlos und sehr schnell.
Gruß Doesel
Hallo,
bis jetzt kann ich einen Freeze vom Cubietruck nur mit den neueren Armbian Images korrelieren, nicht mit jüngeren Änderungen in FHEM.
Ich hatte auch einige Cubietruck Systemabstürze incl. diversen Memory Fehlermeldungen auch ohne das FHEM läuft.
Mit meinem Uralt Cubiiez/Wheezy Image läuft der Cubietruck stabil (nochmaliger Test nach 2 Wochen abgebrochen, in der Vergangenheit über Jahre ohne Probleme).
Mit diversen neueren Armbian Images habe ich Hänger manchmal schon beim Booten bis spätestens nach 7 Tagen (auf zwei verschiedenen Cubietrucks).
Auch die wenigen neueren Infos im Armbian Forum führen zu nichts Brauchbarem. CPU speed Anpassung hatte bei mir nicht geholfen. Netzteile auch nicht (sind auch immer noch dieselben).
https://forum.armbian.com/topic/8448-cubietruck-w-armbian-jessie-is-hanging-after-4-6-days/ (https://forum.armbian.com/topic/8448-cubietruck-w-armbian-jessie-is-hanging-after-4-6-days/)
https://forum.armbian.com/topic/2866-cubietruck-freeze-after-1-3-days-with-523-xenial-uboot-problem/?page=4 (https://forum.armbian.com/topic/2866-cubietruck-freeze-after-1-3-days-with-523-xenial-uboot-problem/?page=4)
Es gab im Forum schon einige Threads dazu, aber ich habe keinen mit irgendeinem Ergebnis für mich gefunden.
https://forum.fhem.de/index.php/topic,39880.50.html (https://forum.fhem.de/index.php/topic,39880.50.html)
https://forum.fhem.de/index.php/topic,26992.50.html (https://forum.fhem.de/index.php/topic,26992.50.html)
https://forum.fhem.de/index.php/topic,72321.0.html (https://forum.fhem.de/index.php/topic,72321.0.html)
https://forum.fhem.de/index.php/topic,54570.0.html (https://forum.fhem.de/index.php/topic,54570.0.html)
https://forum.fhem.de/index.php/topic,65955.0.html (https://forum.fhem.de/index.php/topic,65955.0.html)
Hat keiner (mehr) einen stabil laufenden Cubietruck?
Grüße,
Norberto
Meine Hauptinstallation läuft auf einem Cubie. Dieser hat allerdings noch ein 14.04er drauf :D
Aber das läuft absolut stabil mit Boot von SSD-Platte.
Hallo zusammen,
also ich habe hier einen Cubietruck mit Armbian 5.60 stretch 4.19.17 (auf SSD) - und das Ding läuft absolut stabil mit FHEM, mosquitto und einer Nodered-Installation. Neustarts eigentlich nur aus Wartungsgründen.
Freezes kann ich nicht beobachten.
Grüße,
a-p-s
Habe aus meinen Cubietruck neu gemacht :-(
die Probleme mit dem Ethernetinterface habe ich ziemlich fix behoben bekommen (Feste IP und Network Manager komplett disabled)
Meiner hatte auch nach ca. 9 Tagen neu gebootet :-(
Meine Log Files brachten auch nichts was den Reboot auf die Spur gekommen wäre.
Dort läuft auch nur esc-dhcpd und bind9
Also wirklich nichts was auch nur im fernsten experimentell wäre
Hat schon jemand ein Vanilla Debian dort installiert bekommen? Oder sonst noch irgendwelche Lösungsideen?
Habe meinen "alten" FHEM Cubietruck zweckentfremdet - der lief über 300 Tage ohne Neustart ;-)
der läuft noch mit Jessie und Kernel 3.4.113-sun7i
Wenn der jetzt auch nach nem Update und Neustart durchläuft mache ich mich auf die Suche nach dem alten Installationsimage bzw, wie ich das mit der alten Kernel auf die Kette bekommen.
Liebe Grüße
Ralf
für die Freezes habe ich noch folgendes gefunden ...
https://forum.armbian.com/topic/8448-cubietruck-w-armbian-jessie-is-hanging-after-4-6-days/
bin gerade am Testen - kann aber dauern ;-)
Status von 2 Cubietricks:
a) Aktuelles Image auf SD Karte - Einstellungen in /etc/default/cpu.... geändert; ohne Last; Power via USB3 Hub ohne Akku
root@cubietest:/var/log# uptime
22:49:21 up 1 day, 3 min, 2 users, load average: 0.22, 0.18, 0.11
root@cubietest:/var/log# uname -a
Linux cubietest 4.19.25-sunxi #5.76.190310 SMP Sun Mar 10 14:50:24 CET 2019 armv7l GNU/Linux
b) "Alter" Cubietruck Bootloader auf NAND und System auf SSD mit ein wenig Last (Unifi Controller; isc-dhcp; bind9; rsyslog); Power via POE Splitter und Akku
ralf@core-1:/var/log$ uptime
22:51:06 up 2 days, 33 min, 3 users, load average: 0.08, 0.15, 0.15
ralf@core-1:/var/log$ uname -a
Linux core-1 3.4.113-sun7i #8 SMP PREEMPT Fri Feb 8 08:49:27 CET 2019 armv7l GNU/Linux
ich werde weiter berichten - spätestens nach 2 Wochen breche ich den Test ab ;-)
Hallo,
Ich habe ebenfalls seit meinem letzten Post zwei Cubietrucks mit Armbian 5.75 und Kernel 4.19.20 laufen.
Unterschied zu vorher: dem Hinweis aus dem Armbian Forum folgend habe ich die CPU frequenzumaschaltung abgeschaltet in dem ich in /etc/default/cpufrequtils min und max auf jeweils 912000 gesetzt habe.
Bei vorherigen Versuchen hatte ich nur den max Wert reduziert.
Mal sehen .. läuft erst seit 4 Tagen.
Grüße,
Norberto
Zitat von: Wuppi68 am 16 März 2019, 22:56:02
Status von 2 Cubietricks:
a) Aktuelles Image auf SD Karte - Einstellungen in /etc/default/cpu.... geändert; ohne Last; Power via USB3 Hub ohne Akku
root@cubietest:/var/log# uptime
22:49:21 up 1 day, 3 min, 2 users, load average: 0.22, 0.18, 0.11
root@cubietest:/var/log# uname -a
Linux cubietest 4.19.25-sunxi #5.76.190310 SMP Sun Mar 10 14:50:24 CET 2019 armv7l GNU/Linux
b) "Alter" Cubietruck Bootloader auf NAND und System auf SSD mit ein wenig Last (Unifi Controller; isc-dhcp; bind9; rsyslog); Power via POE Splitter und Akku
ralf@core-1:/var/log$ uptime
22:51:06 up 2 days, 33 min, 3 users, load average: 0.08, 0.15, 0.15
ralf@core-1:/var/log$ uname -a
Linux core-1 3.4.113-sun7i #8 SMP PREEMPT Fri Feb 8 08:49:27 CET 2019 armv7l GNU/Linux
ich werde weiter berichten - spätestens nach 2 Wochen breche ich den Test ab ;-)
a und b still alive ;-)
Hallo,
Cubietruck #2 nach 4 Tagen 'abgestürzt' - ich habe aber keine Details da ich unterwegs bin und einen watchdog eingerichtet habe, der CT hat dann einen Neustart hingelegt. Der CT lief ohne Last und auch ohne FHEM installation.
Ich warte jetzt mal auf den ersten Cubietruck. Der läuft seit den cpufrequtils Anpassungen vor 7 Tagen ohne Hänger. Eventuell hat der 2. CT ja inzwischen ein HW-Problem (obwohl er mit einem 3.x Kernel jahrelang durchlief).
Grüße,
Norberto
Hallo,
aktueller Stand mit meinen Systemen (aktuelles Armbian):
Cubietruck #1 mit IoBroker läuft seit 50 Tagen ohne Probleme
Cubietruck #2 mit FHEM bootet (mit Watchdog) seit neuestem jeden Freitag am Morgen neu, irgendwann zwischen 7 und 9 Uhr - ohne das da ein Cron job oder andere spezielle Aktion laufen würde. Sonderbar. Im Log ist nichts zu sehen (der relevante Teil im Log ist wegen des Reboots weg). Keine Memory-Fehlermeldungen, zumindest nicht sichtbar.
Sobald es mir die Zeit erlaubt setze ich System #2 nochmals neu auf und installiere nur was absolut notwendig ist, ändere dann auch die CPU-Frequenz auf einen festen Wert. Evtl. taktet das System mit der variablen Frequenz bei kritischer Belastung zu niedrig. Oder es laufen da noch Anwendungen die Ärger machen. Es ist z.B. "Samba" aktiv - sollte kein Problem sein, aber wer weiß.... Stromversorgung ist OK, bei System #2 sogar mehr Power als für System #1. Beide übrigens mit SSD, HW also durchaus vergleichbar.
Wenn ich die Konfig für System #2 habe und Ergebnisse habe dann poste ich wieder.
Gruß, Klaus
meine beiden Curies laufen noch ....
8 + 9 Tage ...
noch ein paar Tage und ich kann 2 von den Dingern wieder in die Produktivumgebung installieren ;-)
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
Zitat von: Klaus.A am 28 März 2019, 00:10:30
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
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
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
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
Tut mir leid, die Installation ist schon lange her, das Image habe ich nicht mehr.
Gruß Doesel
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
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
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.
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
Zitat von: Klaus.A am 02 Juni 2019, 12:32:59
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
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
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
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.
habe Monate nichts mit Linux gemacht
ohen exakte Anleitung wirds schwierig,
Linux nicht mein Ding