RaspberryMatic – Firmware Upgrade Probleme - Analyse

[GEVJan]

Alles klar, dann drück ich mal die Daumen das euch was einfällt!
Wird ein Update auf eine neue Version, mit gepatchter Updateroutine, denn funktionieren wenn mit der aktuellen Version kein Update möglich ist?
Oder sollte ich mal das Update im Recovery-Modus versuchen einzuspielen?

[Baxxy]

Oder sollte ich mal das Update im Recovery-Modus versuchen einzuspielen?

Das wäre die erste Option. Die zweite wäre das von mir erwähnte rmupdate-AddOn. Das hat bisher noch bei keinem versagt (soweit ich weiß).
Du könntest aber mal paar Details zu deinem System sagen...
Hardware?
Umstieg von CCU3?
wenn ja...
mit Werksreset
ohne Werksreset
SD-Karte (Größe, Class) <-- steht normalerweise drauf

[GEVJan]

Ich bin mit der letzen RM-Version von der Standard CCU3 FW rübergewechselt. Werksreset habe ich gemacht. Welche SD drin steckt weiß ich jetzt grade leider nicht. Ist aber die original Karte (ungefähr 2 Jahre alt). An und für sich läuft die Kiste auch schnell und ohne Abstürze. Ich werde die beiden Updatevarianten morgen mal ausprobieren.
Danke für die Tipps!

[Baxxy]

Ich bin mit der letzen RM-Version von der Standard CCU3 FW rübergewechselt.

Ok, also vermutlich von CCU3 (ccu3-3.57.5) auf RM (3.57.5.20210525) mit der originalen CCU3 SD-Karte.
Dann versuche ich das mal nachzustellen.

Grüße
Baxxy

[jmaus]

, also vermutlich von CCU3 (ccu3-3.57.5) auf RM (3.57.5.20210525) mit der originalen CCU3 SD-Karte.
Dann versuche ich das mal nachzustellen.

Mach mal lieber mit den anderen tests weiter die dubja schon begonnen hattest. Weil ich hab ein paar fundamentale Änderungen am fw update prozess in der pipeline die ich heute abend noch comitten werde und dann gehören die Probleme hoffentlich der Vergangenheit an und du hast noch mehr zu testen

[GEVJan]

[/quote]

Ich bin mit der letzen RM-Version von der Standard CCU3 FW rübergewechselt.

Ok, also vermutlich von CCU3 (ccu3-3.57.5) auf RM (3.57.5.20210525) mit der originalen CCU3 SD-Karte.
Dann versuche ich das mal nachzustellen.

Grüße
Baxxy

Ja genau!
Aber halte dich lieber an das, was Jens gesagt hat. Ich krieg das im Zweifel, mit deinen Tipps, schon irgendwie hin

Mach mal lieber mit den anderen tests weiter die dubja schon begonnen hattest. Weil ich hab ein paar fundamentale Änderungen am fw update prozess in der pipeline die ich heute abend noch comitten werde und dann gehören die Probleme hoffentlich der Vergangenheit an und du hast noch mehr zu testen

Trotzdem vielen Dank!

Gruß, Jan

[Baxxy]

Mach mal lieber mit den anderen tests weiter

Mache ich, aber das Kontingent an Pi-Hardware und SD-Karten ist begrenzt.
Bin aber der Meinung das gerade die CCU3 Umsteiger (mit original Hardware und original SD-Karte) den Großteil der Problemfälle ausmachen.
Und da ich die Hardware + original SD habe teste ich das mal durch, mit und ohne Werksreset.
Aber ich merke schon jetzt... die originale SD ist ne echt lahme Socke. Da kann man nur empfehlen was schnelleres einzusetzen, "Industrial" hin oder her...

Ergebnisse dann... demnächst.

Grüße
Baxxy

[jmaus]

, also vermutlich von CCU3 (ccu3-3.57.5) auf RM (3.57.5.20210525) mit der originalen CCU3 SD-Karte.
Dann versuche ich das mal nachzustellen.

Mach mal lieber mit den anderen tests weiter die dubja schon begonnen hattest. Weil ich hab ein paar fundamentale Änderungen am fw update prozess in der pipeline die ich heute abend noch comitten werde und dann gehören die Probleme hoffentlich der Vergangenheit an und du hast noch mehr zu testen

So, habe gerade mal meine Anpassungen diesbzgl. ins Repository gepusht. D.h. der nächste nightly snapshot sollte die von mir angedeuteten Verbesserungen mit sich bringen und hoffentlich dazu führen das die Firmware-Update Probleme dann hoffentlich geschichte sind. Zusammenfassend habe ich das ganze jetzt so umgestellt das in der Standard-WebUI im Grunde nur noch der Dateiupload passiert. Sämtliches Auspacken, Checksum verify, usw. passiert nun ausschließlich im Recovery System, d.h. also nach dem ersten Reboot wenn er dann das Update anwendet. In der WebUI passiert daher nur noch das absolut minimal mit ein paar plausibilitätschecks, aber nichts was ausgedehnte Zeit in Anspruch nehmen sollte.

Getestet habe ich das ganze recht ausführlich auf einem RaspberryPi1 der entsprechend langsam ist und daher problemlos in das hier genannte Problem gerannt war. Mit den nun vorgenommenen Änderungen ließ sich ein Firmware-Update problemlos ohne Fehler und reproduzierbar anwenden. Ich würde daher vorschlagen das du @Baxxy nun mit dem nächste nightly snapshot bitte nochmal deine Tests fährst und sämtliche Prozedere durchtestest. Dadurch das ich den gesamten Firmware-Update Prozess hier/da anders umsetzen lassen musste müsstest du hier wirklich versuchen sämtliche Szenarien noch einmal abzutesten. D.h. Upload der zip, Upload nur der img, upload der tgz für ccu3 usw. usw. Werde zwar selber auch hier/da nochmal ausführlich testen, aber es wäre wirklich hilfreich wenn soviele wie möglich ab dem nächsten nightly build die Firmware-Update Routinen auf Herz+Nieren testen könnten. Dabei aber beachten, das man natürlich erst einmal das Update auf das nightly snapshot machen muss und dann quasi nochmal wenn man das unterschiedliche Verhalten sehen/wahrnehmen will

[Baxxy]

Na mal schauen wie sich das dann verhält.
Viel zum testen werde ich leider nicht mehr kommen, der Urlaub steht bevor.
Und wenn ich dann was teste sind es vermutlich Fischsuppen.
Ergo müssen mal andere ran.

Die Maßnahmen werden das Prozedere sicherlich beschleunigen, aber ich muss nochmal betonen das das eigentliche Problem bisher zwar identifiziert, aber nicht weiter analysiert wurde. Die extrem lahme Schreibgeschwindigkeit der SD-Karten vor allem bei nicht werksresetteten CCU3 "Umsteige-Systemen"

Das ist auch der Grund warum es heute keine "Benchmarks" gab.
Ich habe eine komplett originale CCU3 auf den letzten Stand gebracht (3.59.6) und dann mit dem "Umsteige-Image" (RaspberryMatic-3.59.6.20210703-ccu3.tgz) zur RaspberryMatic gemacht.
Das hat gefühlt 2h gedauert und den Werksreset habe ich absichtlich ausgelassen.
Dann die cp_maintenance.cgi und fileupload.ccc gepatched und begonnen die RaspberryMatic-3.59.6.20210703-rpi3.zip "drüberzubügeln".
Natürlich vergessen die /etc/lighttpd/lighttpd.conf zu optimieren und das erst nach ner Stunde gemerkt.

Tja das Ende vom Lied sehen wir dann morgen, denn aktuell rödelt das Upgrade vor sich hin.

Code: Alles auswählen

Tue Jul 13 22:57:49 CEST 2021
23:41:19 - Step_1: Upload beendet

(Immerhin wurde der Upload nach ca. 43Min beendet)

Grüße
Baxxy

[Baxxy]

So, ich habe die Ergebnisse weiter oben aktualisiert...

Weitere Erkenntnisse...
Die Umsteige-CCU3 (ohne Werksreset) konnte ich nicht upgraden, trotz 6000er Limits in /etc/lighttpd/lighttpd.conf. Das Image war erst ca. 150min nach Beginn des Uploads entpackt... Hatte das dann nach 2 Versuchen abgebrochen.

Fazit zur neuen FW-Upgrade-Methode (ab Nightly RaspberryMatic-3.59.6.20210714-4474eb)
Pro:

• minimaler Zeitgewinn (ca. 0,5min bei meinen Test's)
• egal wie lahm die Zentrale (oder dessen SD-Karte) ist, das Upgrade läuft durch

Contra:

• die "Downtime" der Zentrale wird drastisch erhöht, grob gesagt verdoppelt

Ich persönlich finde die zusätzliche halbe Minute "Upgrade-Dauer" (alte Methode) akzeptabler als die teils doppelt so lange "Downtime" der Zentrale.
Zumal sich die halbe Minute ja sparen ließe wenn der Checksummen-Check nicht doppelt ausgeführt würde (alte Methode).

Die "alte Methode", (upload, entpacken, (prüfen) während die Zentrale "online" ist) sagte mir mehr zu.

Noch ein interessantes Detail:
Wenn man die original CCU3 - SD frisch mit RaspberryMatic bespielt ist sie wesentlich flotter als in einem werksresetteten Umsteige-System... warum auch immer.