Paritionsgröße nach Umzug von microSD auf eMMC

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Antworten
Benutzeravatar
Sanweb
Beiträge: 57
Registriert: 11.08.2020, 09:50
System: CCU
Hat sich bedankt: 16 Mal
Danksagung erhalten: 5 Mal

Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von Sanweb » 19.12.2022, 11:40

Hallo,

da ich die nächsten Tage eine größere eMMC (16GB) bekomme und Raspberrymatic aktuell auf eine 8GB microSD läuft, stellt sich mir aktuell folgende Frage:

Bei der Erstinstallation, also der erste Start von Raspberrymatic nach dem flashen des Images auf dem Speichermedium passt Raspberrymatic ja die Partitionsgröße an dem vorhandenem Speichermedium automatisch an. Wenn man nun einen Umzug auf ein größeres Medium vollzieht, in dem man vom vorhandenen Medium ein Image anfertigt und dieses auf das neue Medium flasht, würde Raspberrymatic ebenfalls die Partition auf die maximal vorhandene Speichergröße anpassen? Oder muss man ein Backup von der Raspberrymatic machen, ein frisches Image auf das neue Speichermedium flashen und das vorhandene Backup erneut einspielen?
Mein bescheidenes Homematic IP System:
270 Kanäle in 42 Geräten:
1x HM-ES-TX-WM, 5x HmIP-HEATING, 1x HM-PB-2-WM, 1x HmIP-CCU3, 1x HmIP-DSD-PCB, 5x HmIP-eTRV-2, 1x HmIP-FSI16, 1x HmIP-HAP, 1x HmIP-PCBS, 1x HmIP-PS-2, 1x HmIP-RCV-50, 4x HmIP-SCI, 1x HmIP-SLO, 2x HmIP-SPI, 5x HmIP-STHD, 1x HmIP-STHO-A, 2x HmIP-SWDO-I, 7x HmIP-SWDO-PL, 1x HmIP-WKP

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von jmaus » 19.12.2022, 11:42

Sanweb hat geschrieben:
19.12.2022, 11:40
Oder muss man ein Backup von der Raspberrymatic machen, ein frisches Image auf das neue Speichermedium flashen und das vorhandene Backup erneut einspielen?
Genau das ist der präferierte und am schnellsten durchführbare Weg. Einfach ein frisches Backup (*.sbk) machen und runterladen, dann runterfahren, Datenträger wechseln/tauschen, etc. Und dann frisches RaspberryMatic Image auf das neue Medium flashen und dann am Schluss das Backup zurückspielen. Fertig!

D.h. also nicht einfach die microSD Karte auf die eMMC umkopieren bzw. umflashen. Da wird sonst RaspberryMatic auch nichts dynamisch vergrößern.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
Sanweb
Beiträge: 57
Registriert: 11.08.2020, 09:50
System: CCU
Hat sich bedankt: 16 Mal
Danksagung erhalten: 5 Mal

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von Sanweb » 22.12.2022, 18:22

@jmaus,
die eMMC sind heute gekommen und wie von Dir angesprochen, habe ich ein neues und frisches Raspberrymatic Image auf jenem geflasht. Funktioniert alles so, wie vorher gesagt von Dir.

Jetzt kommt aber das große ABER, weil beim Rückspielen des Backup's etwas Interessantes auftrat, was bei mir anfänglich für große Augen sorgte, denn ... es wurde ein System-Sicherheitsschlüssel abgefragt, welchen ich aber NIE gesetzt hatte.

Vor dem Umzug hatte ich ein Backup von der Version direkt von der WebUI Oberfläche von Raspberrymatic angefertigt und war mir ziemlich sicher, das der Zähler für vorgenommenen Änderungen des Sicherheitsschlüssels auf "0" stand. Zur Sicherheit habe ich noch mal die microSD Karte eingesetzt und die CCU3 davon starten lassen und dort ebenfalls noch einmal nachgeschaut und siehe da, auch dort steht der Zähler auf "0".

Nun habe ich als führendes System der vorhandenen Smarthome Komponenten aber den ioBroker am laufen, der über das AddOn "BackitUp" verfügt und mir jede Nacht u.a. ein Backup der CCU3 macht und dieses auf das NAS-Laufwerk schiebt. Nehme ich das letzte Backup der CCU3 von letzter Nacht (angefertigt vom ioBroker AddOn) und spiele es ebenfalls auf eine frische jungfräuliche mit Raspberrymatic geflashte eMMC, wird erstaunlicherweise nach keinem System-Sicherheitsschlüssel gefragt.

Also alle Backup's, welche über die WebUI - 3.65.11.20221218 (zumindest bei mir) angefertigt werden, sind automatisch mit einem mir unbekanntem System-Sicherheitsschlüssel versehen, obwohl - wie angemerkt, niemals einer von mir gesetzt wurde. Wie kommt so was zustande? Ein Bug?
Mein bescheidenes Homematic IP System:
270 Kanäle in 42 Geräten:
1x HM-ES-TX-WM, 5x HmIP-HEATING, 1x HM-PB-2-WM, 1x HmIP-CCU3, 1x HmIP-DSD-PCB, 5x HmIP-eTRV-2, 1x HmIP-FSI16, 1x HmIP-HAP, 1x HmIP-PCBS, 1x HmIP-PS-2, 1x HmIP-RCV-50, 4x HmIP-SCI, 1x HmIP-SLO, 2x HmIP-SPI, 5x HmIP-STHD, 1x HmIP-STHO-A, 2x HmIP-SWDO-I, 7x HmIP-SWDO-PL, 1x HmIP-WKP

Benutzeravatar
Baxxy
Beiträge: 10648
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 597 Mal
Danksagung erhalten: 2180 Mal

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von Baxxy » 22.12.2022, 19:03

Sanweb hat geschrieben:
22.12.2022, 18:22
Ein Bug?
Kann ich so erstmal nicht bestätigen.
Backup eines "3.65.11.20221218 - Testsystems" über die WebUI mit anschließendem Werksreset und Backup restore verläuft ohne Auffälligkeiten.

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von jmaus » 22.12.2022, 19:28

Sanweb hat geschrieben:
22.12.2022, 18:22
Also alle Backup's, welche über die WebUI - 3.65.11.20221218 (zumindest bei mir) angefertigt werden, sind automatisch mit einem mir unbekanntem System-Sicherheitsschlüssel versehen, obwohl - wie angemerkt, niemals einer von mir gesetzt wurde. Wie kommt so was zustande? Ein Bug?
Kannst mir gerne mal auf privatem Weg beide Backups zukommen lassen (1x von WebUI und 1x von ioBroker) und ich schau mir das gerne mal in einer ruhigen Minute genauer an warum er in deinem Fall der Meinung ist ein Systemschlüssel abzufragen…
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
Sanweb
Beiträge: 57
Registriert: 11.08.2020, 09:50
System: CCU
Hat sich bedankt: 16 Mal
Danksagung erhalten: 5 Mal

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von Sanweb » 22.12.2022, 20:03

@jmaus,

habe sie dir per PM gesendet ...
Mein bescheidenes Homematic IP System:
270 Kanäle in 42 Geräten:
1x HM-ES-TX-WM, 5x HmIP-HEATING, 1x HM-PB-2-WM, 1x HmIP-CCU3, 1x HmIP-DSD-PCB, 5x HmIP-eTRV-2, 1x HmIP-FSI16, 1x HmIP-HAP, 1x HmIP-PCBS, 1x HmIP-PS-2, 1x HmIP-RCV-50, 4x HmIP-SCI, 1x HmIP-SLO, 2x HmIP-SPI, 5x HmIP-STHD, 1x HmIP-STHO-A, 2x HmIP-SWDO-I, 7x HmIP-SWDO-PL, 1x HmIP-WKP

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von jmaus » 22.12.2022, 21:07

Sanweb hat geschrieben:
22.12.2022, 20:03
@jmaus,
habe sie dir per PM gesendet ...
Danke dir. Hab ich mir gerade mal angeschaut und kann dein Problem hier nachvollziehen. Nach etwas Analyse zeigt sich aber das wohl das *.sbk das du da von deiner Zentrale direkt erstellen lassen hast (nicht via ioBroker) wohl aus irgendwelchen Gründen kaputt ist. Da gibt es eine "signature.sha256" Datei mit den Checksummen aller Dateien drin die im *.sbk drinliegen und wenn man die Checksumme der "usr_local.tar.gz" Datei anschaut sieht die so aus:

Code: Alles auswählen

78015dc81220edaebd6e52163fb1580c3018b6a7a65b6e1e92aa3125a864e39d  ./usr_local.tar.gz
Wenn man die Checksumme dann aber mal für die Datei berechnen lässt sieht die wiederrum so aus:

Code: Alles auswählen

# sha256sum usr_local.tar.gz
208b2b00b5c882a05dd395d7e1e61cb89af108d8242383dca077ea1d872b5a19  usr_local.tar.gz
Das gleiche Bild zeigt sich wenn man die Checksummen direkt überprüfen lässt:

Code: Alles auswählen

# sha256sum -c signature.sha256 
./firmware_version: OK
./key_index: OK
./signature: OK
./usr_local.tar.gz: FAILED
sha256sum: WARNING: 1 of 4 computed checksums did NOT match
Konkret bedeutet das, das aus irgendwelchen Gründen in dem *.sbk das du direkt von der Zentrale runtergeladen hast nicht das selbe oder ein nicht mit der Checksumme konsistente usr_local.tar.gz drinliegt. Das erklärt auch warum die Restore Routinen meinen das es hier einen Sicherheitsschlüssel geben muss.

Stellt sich nur am Schluss noch die Frage wie es genau dazu gekommen ist?!? Schon komisch das da ein vermeintlich nicht konsistentes usr_local.tar.gz drin gelandet ist. Kannst du das mal bitte versuchen zu reproduzieren? D.h. nochmal versuchen ein erneutes sbk generieren und runterladen zu lassen und dieses dann versuchen für einen Restore hochzuladen um zu schauen ob die Sicherheitsschlüsselabfrage unmittelbar wieder kommt.

Für mich bedeutet das allerdings das ich wohl die Restoreroutinen nochmal anpassen muss um bei diesem Fall eine bessere/andere Warnung bzw. Fehlermeldung auszugeben statt einfach nur nach einem vermeintlichen Sicherheitsschlüssel zu fragen.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
Sanweb
Beiträge: 57
Registriert: 11.08.2020, 09:50
System: CCU
Hat sich bedankt: 16 Mal
Danksagung erhalten: 5 Mal

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von Sanweb » 22.12.2022, 23:55

Hallo Jens,
jmaus hat geschrieben:
22.12.2022, 21:07
Stellt sich nur am Schluss noch die Frage wie es genau dazu gekommen ist?!? Schon komisch das da ein vermeintlich nicht konsistentes usr_local.tar.gz drin gelandet ist. Kannst du das mal bitte versuchen zu reproduzieren? D.h. nochmal versuchen ein erneutes sbk generieren und runter laden zu lassen und dieses dann versuchen für einen Restore hochzuladen um zu schauen ob die Sicherheitsschlüsselabfrage unmittelbar wieder kommt.
Da der Vorgang ja noch recht frisch ist, fasse ich hier einmal zusammen, was ich im einzelnen gemacht habe:
  • Backup vom laufendem Raspberrymatic System auf der benutzen microSD in der CCU3 erstellt.
  • Zum flashen der neuen eMMC habe ich nicht ein frisches Images von der Github Seite heruntergeladen und auch nicht mit dem allgemein gängigem "balenaEtcher" auf die eMMC geflasht. Da ich doch einige Raspberry's hier herum fliegen habe und auch für diverse Sachen stets immer wieder auf jene zurück greife, habe ich zum flashen der eMMC das Programm "Raspberry PI Imager v1.7.3" (... und ja, es gibt eine aktuellere Version ... :roll: ) für Ubuntu 18.04 (... und ja, es gibt auch da eine aktuellere Version .... :roll: ... benötige ich aber für ein häufig genutztes AppImage was aktuell nur unter dieser Version läuft für den Zugriff auf einen Streaming-PC in einem Rechenzentrum, ist aber eine andere Geschichte) und dort das aktuelle Raspberrymatic Image ausgewählt.
  • Die eMMC dann in die CCU3 gesteckt, das System hochgefahren und das Backup (... welches mit dem System von der microSD erstellt wurde) zurück spielen wollen und dort dann das dumme Gesicht gezogen, als nach dem Sicherheitsschlüssel gefragt wurde.
  • Da ich keinen Sicherheitsschlüssel gesetzt hatte, wusste ich nicht was ich eingeben sollte und brach den Vorgang ab. Griff dann auf das letzte vom ioBroker erstellte Backup zurück und staunte erst einmal, das dort keine Nachfrage nach einem Sicherheitsschlüssel kam.
Jetzt kommt was interessantes aus meiner Sichtweise:
Danach habe ich (obwohl eine aktuelle Raspberrymatic Version auf der CCU3 schon vorhanden war) trotzdem das automatische Update angestoßen und durch laufen lassen, welches ohne Fehlermeldung erfolgreich war. Aufgefallen war mir lediglich der Lese-/Schreibtest während des Updatevorganges, der mir erst einmal verriet, das die eMMC Karte der Datendurchsatz im lesen und schreiben 4,5 x höher war als bei der original verbauten SanDisk von ELV.
Danach habe ich wie von Dir, lieber Jens, empfohlen ein neues Backup erstellt und dieses auch erneut OHNE Abfrage eines System-Sicherheitsschlüssels eingespielt bekommen. Der Fehler ist seit dem ausgeführtem Update nicht mehr vorhanden.

Die einzige Möglichkeit, die mir einfiele wäre, das ich vor ein paar Tagen einen kompletten Umzug von der CCU2 auf die CCU3 vollzogen habe, aber das einspielen des CCU2-Backup's verlief fehlerfrei, jedoch habe ich danach die Backup Funktion der Raspberrymatic nicht ausprobiert, da bei mir eh alles über den ioBroker läuft ... Hätte ich nicht mit dem Gedanken gespielt, von einer microSD auf eine eMMC oder gar USB bootfähige SSD zu wechseln, wäre es mir vermutlich gar nicht aufgefallen ...
Mein bescheidenes Homematic IP System:
270 Kanäle in 42 Geräten:
1x HM-ES-TX-WM, 5x HmIP-HEATING, 1x HM-PB-2-WM, 1x HmIP-CCU3, 1x HmIP-DSD-PCB, 5x HmIP-eTRV-2, 1x HmIP-FSI16, 1x HmIP-HAP, 1x HmIP-PCBS, 1x HmIP-PS-2, 1x HmIP-RCV-50, 4x HmIP-SCI, 1x HmIP-SLO, 2x HmIP-SPI, 5x HmIP-STHD, 1x HmIP-STHO-A, 2x HmIP-SWDO-I, 7x HmIP-SWDO-PL, 1x HmIP-WKP

mademyday
Beiträge: 268
Registriert: 03.10.2014, 12:46
System: CCU
Wohnort: Enzkreis
Hat sich bedankt: 3 Mal
Danksagung erhalten: 43 Mal

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von mademyday » 23.12.2022, 09:32

Frage am Rande: diese "signature.sha256" Datei, mit den Checksummen aller Dateien die im *.sbk liegen, die gibt es nur beim Backup einer RM, nicht beim Backup mit einer originalen CCU2/3? - zumindest finde ich da nichts
Gibt es hier auch eine Möglichkeit das Backup automatisch/geskriptet auf Konsistenz zu prüfen (ohne gleich einen Restore-Test durchzuführen)?

Benutzeravatar
jmaus
Beiträge: 9819
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 459 Mal
Danksagung erhalten: 1856 Mal
Kontaktdaten:

Re: Paritionsgröße nach Umzug von microSD auf eMMC

Beitrag von jmaus » 23.12.2022, 09:59

mademyday hat geschrieben:
23.12.2022, 09:32
Frage am Rande: diese "signature.sha256" Datei, mit den Checksummen aller Dateien die im *.sbk liegen, die gibt es nur beim Backup einer RM, nicht beim Backup mit einer originalen CCU2/3? - zumindest finde ich da nichts
Ist es nicht erneut eines dieser kleinen, aber tollen Features von RaspberryMatic? :mrgreen:

Und inzwischen habe ich die WebUI Restore Routinen in RaspberryMatic auch so erweitert das er diese SHA256 Checksumüberprüfung nach dem Hochladen und auspacken direkt ausführt und es dann meldet wenn die Backupdatei inkonsistent ist (siehe https://github.com/jens-maus/RaspberryM ... 6e45410542). Und zu meiner Überraschung hatte ich diese Konsistenzüberprüfung sogar schon lange im Kommandozeilenprogramm "restoreBackup.sh" sowie im Recovery System eingebaut, nur in der WebUI selbst fehlte das noch. In der nächsten Version ist das dann also auch erledigt :)
mademyday hat geschrieben:
23.12.2022, 09:32
Gibt es hier auch eine Möglichkeit das Backup automatisch/geskriptet auf Konsistenz zu prüfen (ohne gleich einen Restore-Test durchzuführen)?
In der Tat macht das die CCU3 bzw. die WebUI bereits jetzt, nur eben nicht voll konsistent. Es nutzt dazu das eQ3 eigene "crypttool" auf der Kommandozeile welches auch für die Verschlüsselung der usr_local.tar.gz Datei in den sbk-Dateien verwendet wird wenn ein Sicherheitsschlüssel gesetzt wurde. Deshalb gibt es diese "signature" Datei (ohne sha256 extension) die auch so etwas wie eine Checksumme beinhaltet. Wenn man nun das crypttool via "crypttool -s -t 0 <usr_local.tar.gz" aufruft sollte dieses die gleiche Checksumme ausspucken wie in dieser Datei steht. Wenn das nicht der Fall ist, ist entweder der Sicherheitsschlüssel falsch oder die Datei defekt/inkonsistent.
RaspberryMatic 3.75.6.20240316 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Antworten

Zurück zu „RaspberryMatic“