[GELÖST] Raspberrymatic 3.53 (November) - Backup-Datei hat über 200 MB

[twoxx]

Verstehe. Nun, es muss ja irgendeinen Grund geben warum bei dir er meint er müsste dein mmcblk3 zweimal mounten (1x korrekt als /usr/local und 1x als /media/usb1). Das ist wirklich sehr komisch.

Zeig mal bitte noch folgende Ausgaben:

Code: Alles auswählen

ls -la /var/run/usbmount/

Code: Alles auswählen

blkid

Code: Alles auswählen

lsblk -r -n -o pkname,partuuid,label,mountpoint

Code: Alles auswählen

udevadm info /dev/mmcblk0p3

Ich vermute, dass dieses fehlerhafte "mounten" ja bereits VOR Einspielen des Backups passiert sein muß.
Also muß wohl das Update per "CCU3->Raspymatic.tgz-Datei " irgendwie fehlerhaft abgelaufen sein.
Könnte es sein, dass der Fehler auch in der ZIP-Datei irgendwie abläuft und deshalb das normale Update nicht funktioniert?

Hier die Ausgaben:

Code: Alles auswählen

root@ccu3-webui:~# ls -la /var/run/usbmount/
total 0
drwxr-xr-x    2 root     root            40 Nov 21 18:52 .
drwxr-xr-x    5 root     root           560 Nov 22 14:56 ..
root@ccu3-webui:~#

Code: Alles auswählen

root@ccu3-webui:~# blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="4AEE-733D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="71898ae0-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="76baf9a2-7920-4faf-bd14-f8129e5a3eb1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="71898ae0-02"
/dev/mmcblk0p3: LABEL="userfs" UUID="eb087d6c-cf27-4173-ad0f-bef7437ee140" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="71898ae0-03"
/dev/zram0: UUID="a5967dde-4ea7-499a-9043-74ad11abbbda" TYPE="swap"

Code: Alles auswählen

root@ccu3-webui:~# lsblk -r -n -o pkname,partuuid,label,mountpoint

mmcblk0 71898ae0-03 userfs /media/usb1
mmcblk0 71898ae0-01 bootfs /boot
mmcblk0 71898ae0-02 rootfs /
   [SWAP]

Code: Alles auswählen

root@ccu3-webui:~# udevadm info /dev/mmcblk0p3
P: /devices/platform/soc/3f202000.mmc/mmc_host/mmc0/mmc0:e624/block/mmcblk0/mmcblk0p3
N: mmcblk0p3
S: disk/by-id/mmc-SU64G_0x191c6666-part3
S: disk/by-label/userfs
S: disk/by-partuuid/71898ae0-03
S: disk/by-path/platform-3f202000.mmc-part3
S: disk/by-uuid/eb087d6c-cf27-4173-ad0f-bef7437ee140
E: DEVLINKS=/dev/disk/by-id/mmc-SU64G_0x191c6666-part3 /dev/disk/by-label/userfs /dev/disk/by-partuuid/71898ae0-03 /dev/disk/by-path/platform-3f202000.mmc-part3 /dev/disk/by-uuid/eb087d6c-cf27-4173-ad0f-bef7437ee140
E: DEVNAME=/dev/mmcblk0p3
E: DEVPATH=/devices/platform/soc/3f202000.mmc/mmc_host/mmc0/mmc0:e624/block/mmcblk0/mmcblk0p3
E: DEVTYPE=partition
E: ID_FS_LABEL=userfs
E: ID_FS_LABEL_ENC=userfs
E: ID_FS_TYPE=ext4
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=eb087d6c-cf27-4173-ad0f-bef7437ee140
E: ID_FS_UUID_ENC=eb087d6c-cf27-4173-ad0f-bef7437ee140
E: ID_FS_VERSION=1.0
E: ID_NAME=SU64G
E: ID_PART_ENTRY_DISK=179:0
E: ID_PART_ENTRY_NUMBER=3
E: ID_PART_ENTRY_OFFSET=2634660
E: ID_PART_ENTRY_SCHEME=dos
E: ID_PART_ENTRY_SIZE=4194304
E: ID_PART_ENTRY_TYPE=0x83
E: ID_PART_ENTRY_UUID=71898ae0-03
E: ID_PART_TABLE_TYPE=dos
E: ID_PART_TABLE_UUID=71898ae0
E: ID_PATH=platform-3f202000.mmc
E: ID_PATH_TAG=platform-3f202000_mmc
E: ID_SERIAL=0x191c6666
E: MAJOR=179
E: MINOR=3
E: PARTN=3
E: SUBSYSTEM=block
E: USEC_INITIALIZED=10257810

[jmaus]

Ok, ich denke nun habe ich den Grund gefunden warum mmcblk3 bei dir falsch 2x gemountet wird. Fälschlicherweise wird die SD Karte bei dir nämlich als zusätzlicher USB Stick erkannt da die PARTUUID der RaspberryMatic Partitionen nicht auf "deedbeef-XX" steht sondern eine ganz andere ID hat und das scheint dann den USB-Mount Mechanismus zu verwirren.

Doch bevor ich dir morgen dann eine mögliche Lösung/Workaround für das Problem präsentieren kann nochmal die genau frage nach dem genauen Ablauf:

Also das ist eine originale eQ3 CCU3 Hardware auf der du dann irgendwann RaspberryMatic einfach via WebUI installieren lassen hast, richtig? D.h. du hast die CCU3 nicht demontiert und die SD Karte komplett neu geflasht oder ähnliches, richtig? D.h. du hast die ab Werk bekommen, dann ne weile als normale CCU3 genutzt, dann via WebUI aber das RaspberryMatic image installieren lassen und dann seit dem genutzt als RaspberryMatic zentrale, ja? Und seit der aktuellen Version hast du bemerkt das das Backup anschwillt, richtig?

Und dann bitte noch final das folgende kommando nochmal ausführen uns die Ausgaben zeigen:

Code: Alles auswählen

fdisk -l /dev/mmcblk0

Das sollte mir dann helfen für dich morgen dann einen möglichen Fix/Workaround zu erarbeiten.

[twoxx]

Ok, ich denke nun habe ich den Grund gefunden warum mmcblk3 bei dir falsch 2x gemountet wird. Fälschlicherweise wird die SD Karte bei dir nämlich als zusätzlicher USB Stick erkannt da die PARTUUID der RaspberryMatic Partitionen nicht auf "deedbeef-XX" steht sondern eine ganz andere ID hat und das scheint dann den USB-Mount Mechanismus zu verwirren.

Doch bevor ich dir morgen dann eine mögliche Lösung/Workaround für das Problem präsentieren kann nochmal die genau frage nach dem genauen Ablauf:

Also das ist eine originale eQ3 CCU3 Hardware auf der du dann irgendwann RaspberryMatic einfach via WebUI installieren lassen hast, richtig? D.h. du hast die CCU3 nicht demontiert und die SD Karte komplett neu geflasht oder ähnliches, richtig? D.h. du hast die ab Werk bekommen, dann ne weile als normale CCU3 genutzt, dann via WebUI aber das RaspberryMatic image installieren lassen und dann seit dem genutzt als RaspberryMatic zentrale, ja? Und seit der aktuellen Version hast du bemerkt das das Backup anschwillt, richtig?

Und dann bitte noch final das folgende kommando nochmal ausführen uns die Ausgaben zeigen:

Code: Alles auswählen

fdisk -l /dev/mmcblk0

Das sollte mir dann helfen für dich morgen dann einen möglichen Fix/Workaround zu erarbeiten.

Hier muß ich differenzieren:

Historie des Backups (SBK-Datei) der letzten funktionsfähigen Installation unter Raspberrymatic 3.51:

Installation der Geräte, Programme etc. hat mit einer CCU2 begonnen.

Das letzte Backup der CCU2 hab ich dann nach ein paar Jahren in eine Originale CCU3 eingespielt, nachdem ich die CCU3 mittels CCU3-TGZ-Datei entsprechend per WEBUI der "CCU3-START-SOFTWARE" geupdatet hatte.

Die CCU3 habe ich dann wieder um ein oder 2 Jahre später in eine Raspberrymatic umgewandelt, indem ich die SD-Karte entnommen hatte und ein Raspberrymatic-Image geflasht hatte.
Darauf hab ich dann das letzte CCU3-Backup eingespielt. Alle weiteren Raspberrymatic-Versionen habe ich immer per "flashen" der SD-Karte
geupdatet und anschliessend immer das letzte Raspymatic-Backup wieder eingespielt.

Dies ging so bis Du irgendwann mal das Einspielen der ZIP-Datei auch in der WEBUI möglich gemacht hattest.
Danach habe ich manchmal das Update per Webui gemacht und manchmal frisch geflasht und das letzte Backup eingespielt.

So ist das Backup der Version 3.51 entstanden.

Ein Update per ZIP in der Webui ging ab Raspberrymatic 3.53.XX nicht mehr. Es endete insgesamt immer mit einer rot leuchtenden LED, nachdem
die Webui extram zäh und langsam lief und ich dann die Geräte oder Programme aufrufen wollte.

Ein flashen der Version 3.53.XX und einspielen des Backups 3.51 brachte gleiches Ergebnis. Zäh laufende Webui, Aufruf eines Programms
oder Geräts führte zu "Eine Komponente ist ausgefallen" und dann rote Lampe am Funkmodul.

Also hab ich mich auf die Suche nach einer Lösung gemacht und folgende gefunden:

Original-Start-Firmware für meine CCU3 "rausgekramt" und auf die SD-Karte geflasht.
Die Start-Firmwaer der CCU3 ist ja keine vollwertige Firmware, sondern mit der kann man nur eine vollwertige Homematic-Version nachladen.

Hier die CCU3->Raspymatic-Wechsel.tgz-Datei der aktuellesten Raspy-Version 3.53 als Update in der Webui eingespielt.

Raspberrymatic ist hochgefahren und dann hab ich das Backup der Version 3.51 eingespielt. ---> erfolgreich. Raspymatic Verseion 3.53-November
läuft super. Sofort ein Backup der Version 3.53 erstellt.... ca. 30 MB.

Einen Tag später (heute) wollte ich nochmal ein Backup ziehen: --> über 200 MB ???

Seitdem ich nun in der usr/local/backup die ".nobackup"-Datei stehen hab, sind die Backups nun wieder bei ca. 30 MB.

Trotzdem scheint hier beim "mounten" was schief gegangen zu sein. Aber wann?
Wie gesagt, die Backups der Version 3.51.XX waren alle bei ca. 50 MB.
Ob der Fehler also schon bei der Version 3.51 da war kann ich also nicht sagen, aufgefallen ist er mir auf jeden Fall durch das aufgeblähte
Backup der Version 3.53.

Aber warum das Backup mehr als 200 MB hat, weiß ich nicht, da ja das nächtliche Backup ja auch nur ca. 50 MB hat.
Und 50 MB "normales Backup" + 50 MB "nächtliches Backup" wären ja eigentlich nur um die 100 MB und nicht mehr als 200 MB.

Es kann also auch sein, dass der Fehler schon in der 3.51er Version da war und jetzt erst in der 3.53er Version "aktiv" wurde.
Aber das ist nur Vermutung. Es kann genauso sein, dass der Fehler erst mit der Version 3.53 entstanden ist.

Vielen Dank für Deinen Einsatz!!!!!!!!

Code: Alles auswählen

root@ccu3-webui:~# fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 59.49 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x71898ae0

Device         Boot   Start     End Sectors  Size Id Type
/dev/mmcblk0p1 *         63  524350  524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2       530145 2627296 2097152    1G 83 Linux
/dev/mmcblk0p3      2634660 6828963 4194304    2G 83 Linux

[twoxx]

Ich habe jetzt sicherheitshalber mal auf meinen anderen CCUs nachgesehen.

Alle meine CCUs habe ich zu CCU2-Zeiten eingerichtet und alle CCUs haben ungefähr den gleichen Werdegang von CCU2 über CCU3 zu Raspymatic.

Die anderen CCUs haben als "UUID" "deedbeef XXX".
Bei den anderen CCUs wurde auch die usr/local auf die gesamte restliche Größe der SD-Karte ausgedehnt.

Bei der hier betroffenen CCU ist das auch nicht der Fall (was bisher kein Problem war, aber es deutet eben darauf hin, dass irgendwann
bei einem Update/Umstieg was schief gelaufen war).

Ancheinend haben sich im Laufe der Zeit nur bei dieser einen CCU die IDs und das "mounten" "verbogen".

Kann es sein, dass dieses Problem auch die Ursache für das fehlerhafte Updaten per "ZIP-Datei" ist?

[jmaus]

Alle meine CCUs habe ich zu CCU2-Zeiten eingerichtet und alle CCUs haben ungefähr den gleichen Werdegang von CCU2 über CCU3 zu Raspymatic.

Die anderen CCUs haben als "UUID" "deedbeef XXX".
Bei den anderen CCUs wurde auch die usr/local auf die gesamte restliche Größe der SD-Karte ausgedehnt.

Bei der hier betroffenen CCU ist das auch nicht der Fall (was bisher kein Problem war, aber es deutet eben darauf hin, dass irgendwann
bei einem Update/Umstieg was schief gelaufen war).

Genau so deckt sich das jetzt mit meinen Recherchen und Tests anhand deiner Angaben hier. Das ursächliche Problem bei dir ist das die betroffene CCU die PARTUUID nicht auf "deedbeef" hat, sondern eine andere UUID dort hinterlegt ist und das passt nicht zur restlichen Logik der RaspberryMatic/CCU. Warum/Weshalb die SD Karte eine andere UUID bekommen hat kann ich natürlich nicht sagen, das passiert eigentlich nur wenn man irgendetwas manuell umpartitioniert und vergisst danach die UUID wieder auf "deebeef" zu setzen. RaspberryMatic selbst macht das natürlich, also muss da irgendwas/irgendwie bei dir damals bzw. im Verlauf der Nutzung schief gegangen zu sein.

Ich hab auch versucht dein Werdegang von CCU3 -> ccu3 basic image restore -> RaspberryMatic Upgrade nachzuvollziehen. Niemals war es mir möglich ein Image zu erzeugen das NICHT die UUID "deedbeef" aufwies. Die einzige Frage die da noch bleibt ist welches "ccu3 basic image" hast du zwischendrin mal verwendet um die SD karte der CCU3 wieder auf Werkseinstellungen zurück zu setzen? War das die die ich inzwischen als "ccu3-3.0.16.img.gz" unter raspberrymatic.de zum download anbiete oder war das die die "blackhole" eine zeitlang Angebotene?

Kann es sein, dass dieses Problem auch die Ursache für das fehlerhafte Updaten per "ZIP-Datei" ist?

Ja, in der Tat könnte es das erklären. Um deine Probleme mit dieser CCU3 inkl. falsche PARTUUID nun aber final zu lösen würde ich dir raten wie folgt vorzugehen:

1. Ein aktuelles System-Backup anlegen und sicher verwahren.
2. Ein Werksreset unter RaspberryMatic (Einstellungen -> Systemsteuerung -> Sicherheit -> System Reset) durchführen.
3. Backup wieder zurückspielen.

Gerade der Punkt 2 sollte unter RaspberryMatic dafür sorgen das nicht nur die zu kleine 2GB /usr/local Partition dann auf die maximale Größe vergrößert wird, sondern auch die PARTUUID sollte dann wieder repariert sein und das "blkid" kommando sollte dann dort korrekterweise "deedbeef" zeigen. Und wenn das so ist sollte auch das falsche doppelmounten von mmblk0p3 einmal als /usr/local und einmal als /media/usb1 aufhören und damit dann eben auch das falsche nächtliche Ablegen von Backups unter /usr/local/backup.

[twoxx]

Alle meine CCUs habe ich zu CCU2-Zeiten eingerichtet und alle CCUs haben ungefähr den gleichen Werdegang von CCU2 über CCU3 zu Raspymatic.

Die anderen CCUs haben als "UUID" "deedbeef XXX".
Bei den anderen CCUs wurde auch die usr/local auf die gesamte restliche Größe der SD-Karte ausgedehnt.

Bei der hier betroffenen CCU ist das auch nicht der Fall (was bisher kein Problem war, aber es deutet eben darauf hin, dass irgendwann
bei einem Update/Umstieg was schief gelaufen war).

Genau so deckt sich das jetzt mit meinen Recherchen und Tests anhand deiner Angaben hier. Das ursächliche Problem bei dir ist das die betroffene CCU die PARTUUID nicht auf "deedbeef" hat, sondern eine andere UUID dort hinterlegt ist und das passt nicht zur restlichen Logik der RaspberryMatic/CCU. Warum/Weshalb die SD Karte eine andere UUID bekommen hat kann ich natürlich nicht sagen, das passiert eigentlich nur wenn man irgendetwas manuell umpartitioniert und vergisst danach die UUID wieder auf "deebeef" zu setzen. RaspberryMatic selbst macht das natürlich, also muss da irgendwas/irgendwie bei dir damals bzw. im Verlauf der Nutzung schief gegangen zu sein.

Ich hab auch versucht dein Werdegang von CCU3 -> ccu3 basic image restore -> RaspberryMatic Upgrade nachzuvollziehen. Niemals war es mir möglich ein Image zu erzeugen das NICHT die UUID "deedbeef" aufwies. Die einzige Frage die da noch bleibt ist welches "ccu3 basic image" hast du zwischendrin mal verwendet um die SD karte der CCU3 wieder auf Werkseinstellungen zurück zu setzen? War das die die ich inzwischen als "ccu3-3.0.16.img.gz" unter raspberrymatic.de zum download anbiete oder war das die die "blackhole" eine zeitlang Angebotene?

Kann es sein, dass dieses Problem auch die Ursache für das fehlerhafte Updaten per "ZIP-Datei" ist?

Ja, in der Tat könnte es das erklären. Um deine Probleme mit dieser CCU3 inkl. falsche PARTUUID nun aber final zu lösen würde ich dir raten wie folgt vorzugehen:

1. Ein aktuelles System-Backup anlegen und sicher verwahren.
2. Ein Werksreset unter RaspberryMatic (Einstellungen -> Systemsteuerung -> Sicherheit -> System Reset) durchführen.
3. Backup wieder zurückspielen.

Gerade der Punkt 2 sollte unter RaspberryMatic dafür sorgen das nicht nur die zu kleine 2GB /usr/local Partition dann auf die maximale Größe vergrößert wird, sondern auch die PARTUUID sollte dann wieder repariert sein und das "blkid" kommando sollte dann dort korrekterweise "deedbeef" zeigen. Und wenn das so ist sollte auch das falsche doppelmounten von mmblk0p3 einmal als /usr/local und einmal als /media/usb1 aufhören und damit dann eben auch das falsche nächtliche Ablegen von Backups unter /usr/local/backup.

Super! Danke! ich werde das heute abend durchlaufen lassen.

War das die die ich inzwischen als "ccu3-3.0.16.img.gz" unter raspberrymatic.de zum download anbiete oder war das die die "blackhole" eine zeitlang Angebotene?

Ich habe das img nicht downgeloaded. Auch nicht von einem "blackhole".

Als ich mir die erste CCU3 kaufte, war überall zu lesen das die CCU3 mit einer internen SD-Karte arbeitet.
Das war der Grund warum ich von CCU2 auf CCU3 gewechselt habe, denn ich dachte mir das ich dadurch sehr einfach komplette "Sicherungen"
in Form von SD-Karten-Kopien machen kann. Aus diesem Grund habe ich auch die CCU3 sofort nach Kauf zerlegt und eine Kopie der
Original-CCU3-Software gemacht (ich glaube das es eine Version 3.0.16 war).
Mit dieser Original-CCU3-Firmware kann man nur eine Vollversion der Firmware nachladen. Was anderes geht damit nicht.

Diese Original-Software habe ich dazu genutzt um Deine CCU3-Wechsel-auf Raspy.tgz-Datei nachzuladen um die aktuellste Raspymatic-Version
auf der SD-Karte zu generieren.
Vermutlich ist hier im Prozess was schief gegangen.

[jmaus]

War das die die ich inzwischen als "ccu3-3.0.16.img.gz" unter raspberrymatic.de zum download anbiete oder war das die die "blackhole" eine zeitlang Angebotene?

Ich habe das img nicht downgeloaded. Auch nicht von einem "blackhole".

Als ich mir die erste CCU3 kaufte, war überall zu lesen das die CCU3 mit einer internen SD-Karte arbeitet.
Das war der Grund warum ich von CCU2 auf CCU3 gewechselt habe, denn ich dachte mir das ich dadurch sehr einfach komplette "Sicherungen"
in Form von SD-Karten-Kopien machen kann. Aus diesem Grund habe ich auch die CCU3 sofort nach Kauf zerlegt und eine Kopie der
Original-CCU3-Software gemacht (ich glaube das es eine Version 3.0.16 war).
Mit dieser Original-CCU3-Firmware kann man nur eine Vollversion der Firmware nachladen. Was anderes geht damit nicht.

Diese Original-Software habe ich dazu genutzt um Deine CCU3-Wechsel-auf Raspy.tgz-Datei nachzuladen um die aktuellste Raspymatic-Version
auf der SD-Karte zu generieren.
Vermutlich ist hier im Prozess was schief gegangen.

Schiefgelaufen nicht, nur ist das inhaltlich nicht wirklich angezeigt gewesen und ich denke das ist genau der Grund wieso du dir dieses Problem ins Haus geholt hast. Du hättest dieses Image nicht wiederverwenden sollen denn das hat genau zu dem Problem geführt weil anscheinend die PARTUUID sich aus irgendeinem Grund mal in frühen versionen der CCU3 Firmwareupdates oder ähnliches geändert hat oder eben beim ersten Install der CCU3 Firmware das passiert und damit hast du diese falsche PARTUUID mit in dein späteres RaspberryMatic System übernommen und das dein Backup sich aufbläht ist nun nur ein interessanter Nebeneffekt/Symptom davon der das erst aufgedeckt hat. Indem du jetzt mal dein RaspberryMatic einmalig komplett werkresettest sollten all diese Probleme auf einmal verschwinden. Und inzwischen habe ich noch hier/da ein paar Änderungen/Optimierungen vorgenommen das solch eine falsche PARTUUID nicht wieder zu solchen Problemen führt. Interessant ist/war dieser Fall aber auf jeden Fall schon einmal

[twoxx]

Schiefgelaufen nicht, nur ist das inhaltlich nicht wirklich angezeigt gewesen und ich denke das ist genau der Grund wieso du dir dieses Problem ins Haus geholt hast. Du hättest dieses Image nicht wiederverwenden sollen denn das hat genau zu dem Problem geführt weil anscheinend die PARTUUID sich aus irgendeinem Grund mal in frühen versionen der CCU3 Firmwareupdates oder ähnliches geändert hat oder eben beim ersten Install der CCU3 Firmware das passiert und damit hast du diese falsche PARTUUID mit in dein späteres RaspberryMatic System übernommen und das dein Backup sich aufbläht ist nun nur ein interessanter Nebeneffekt/Symptom davon der das erst aufgedeckt hat. Indem du jetzt mal dein RaspberryMatic einmalig komplett werkresettest sollten all diese Probleme auf einmal verschwinden. Und inzwischen habe ich noch hier/da ein paar Änderungen/Optimierungen vorgenommen das solch eine falsche PARTUUID nicht wieder zu solchen Problemen führt. Interessant ist/war dieser Fall aber auf jeden Fall schon einmal

Hallo Jens,
vielen Dank für Deinen Einsatz!!!!

Ich habe nun das von Dir vorgeschlagene Prozedere durch. Letztenendes ist es nun gut verlaufen, wenn auch nicht ganz wie zuerst erwartet:

1. Backup der aktuell problemlos laufenden Version 3.53 durchgeführt (einzig das Mounting-Problem bzw. UID-Problem war natürlich noch da).
2. Werksreset durchgeführt.
3. Neustart
4. Erst mal geprüft, ob nun die IDs richtig sind und auch die /usr/local die richtige größe auf der SD-Karte hat
5. sicherheitshalber mal die log-Dateien der noch "leeren" Homematic-Zentrale gecheckt---> sah alles OK aus
6. Backup Version 3.53 eingespielt
7. Fehlmermeldung, dass Backup fehlerhaft ist und das kein Coprozessor vorhanden ist. Man soll das Backup nochmal einspielen
8. Backup Version 3.53 nochmal eingespielt
9. erneute Fehlermeldung, dass Backup defekt und kein Coprozessor vorahnden ist.
10. .... überlegt ob ich die CCU an die Wand werfe
11. alternativ zum neuen Backup Ver.3.53 nun das letzte funktionierende alte Backup Ver. 3.51 eingspielt (hatte sich ja schon einmal bewährt)
12. Neustart
13. CCU fährt hoch
14. Log-Datei gecheckt.... vom hochfahren her alles OK, auch die 4 Prozessoren wurden anscheinend erkannt, lediglich ca. im Sekundentakt Meldung, das der Watchdog ein "undervoltage" entdeckt hat
15. Einfach mal ein wenig die CCU getestet, Geräte bedient, Programme geöffnet/ausgelöst, Geräte geöffnet etc. --> alles ok
16. Redmatic 7.1.1. wieder als Zusatzsoftware eingespielt --> alles OK
17. Redmatic - Nodes-Oberfläche geöffnet --> alles OK
18. Redmatic wieder verlassen. Webui meldet sich ab und Anmeldefenster erscheint wieder
19. Nach Anmeldung nochmal Geräte etc. gecheckt, alles ok, nochmal Redmatic gecheckt.... Meldung auf weißem Bildschirm "server unavailable"
20. Zurück zur Webui... Kein Aufruf von Menüs mehr möglich, auch kann die Systemsteuerung nicht mehr aufgerufen werden
21. Rote LED an der CCU
22. ....... erneut überlegt, ob ich die CCU an die Wand werfe
23. SD-Karte neu eingerichtet und Image Version 3.53 (November) drauf geflasht (einfach mal aus dem Bauch heraus entschieden)
24. Wie bereits in der Vergangenheit erlebt, fährt Version 3.53 hoch
25. Partitions-IDs gecheckt und auch Partionstgröße /user/local gecheckt....... alles OK
26. LOG-Datei gecheckt.....alles OK..... Prozessoren alle erkannt, keine meldung das irgendein Undervoltage vorhanden ist
27. Da ich ja nun - entgegen der Vergangenheit - auch bereits ein paar Backups der Version 3.53 habe, habe ich mich dazu entschieden
das heute gemachte Backup Ver 3.53 einzuspielen - dann muß Raspymatic nicht das alte Backup Ver 3.51 in die neue Version "einarbeiten".
Ich entschied mich für das jüngste Backup, das beim Versuch nach dem Werksreset als "fehlerhaft beschrieben wurde" (Bauchgefühl).
28. Siehe da!!! Diesmal KEINE Fehlermeldung, dass Backup fehlerhaft ist, auch keine Meldung eines fehlenden Coprozessors.
29. Neustart.
30. Aufruf Webui...sehr zäh, Laden und Anzeige der Favoriten dauerte sehr lang.... eine Meldung, das der Watchdog "RegaHSS" neu starten mußte war in den Alarmmeldungen.
31. Tests in der Webui alle erfolgreich. Seitdem dann auch keine Ladezeiten mehr in der Webui.
32. Nochmal die Logdatei gecheckt..... alles ruhig.. auch keine "undervoltage-Meldung".
33. Redmatic eingespielt.
34. Sicherheitshalber kompletten Neustart
35. Hochfahren erfolgreich.... auch keine zähen Ladezeiten in der Webui mehr.
36. Aufruf Redmatic erfolgreich, von den Wechselrichtern kommen die Daten rein, Werte werden berechnet und auch an die externe Influx-Datenbank weitergeleitet. Werte kommen auch in der Influx-Datenbank an.... Alles OK
37. Neues Backup erstellt.
38. Sieht jetzt alles gut aus.



Danke nochmals!!!! und es freut mich, dass das Thema auch ein wenig zur Verbesserung der Raspymatic beitragen konnte.
Ich hätte da noch einen Vorschlag:

Sofern es das nicht bereits gibt, würde ich es gut finden, wenn es so eine "Nachladesoftware" speziell für Raspberrymatic gäbe.
Einfach ein Image das man auf die SD-Karte schreibt und man fährt die Raspymatic hoch und kann dann Deine tgz-Datei oder sogar
eine ZIP-Datei hochladen und damit installieren.

Vielleicht ist sowas für den einen oder anderen Fall nützlich?

[hotroot]

Hallo Jens,

ich habe gerade diesen Thread gelesen und mich daran erinnert dass meine RaspberryMatic auf dem Tinkerboard S auch fälschlicherweise behauptet ein USB-Stick wäre angeschlossen obwohl keiner angeschlossen ist:

Bildschirmfoto vom 2020-11-25 14-16-20.png (10.68 KiB) 1264 mal betrachtet

Ich habe bei mir auch einmal die UUIDs angeschaut und habe das selbe "Problem":

Code: Alles auswählen

root@homematic-ccu2:~# cat /VERSION 
VERSION=3.53.34.20201121
PRODUCT=raspmatic_tinkerboard
PLATFORM=tinkerboard

Wie du siehst nutze ich das aktuelle Tinkerboard-Image (Hostname ist historisch, komme ursprünglich von einer CCU2)

Code: Alles auswählen

root@homematic-ccu2:~# blkid
/dev/mmcblk2p1: SEC_TYPE="msdos" LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="B974-C48D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c8837721-01"
/dev/mmcblk2p2: LABEL="rootfs" UUID="19c7da83-e45a-4972-8a99-2259623b4954" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c8837721-02"
/dev/mmcblk2p3: LABEL="userfs" UUID="c49677a5-afe0-49ce-9f5c-f634eb786756" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c8837721-03"
/dev/zram0: UUID="860e9396-92dd-4cf1-bf89-88dcb2e9306e" TYPE="swap"

Code: Alles auswählen

root@homematic-ccu2:~# mount
/dev/root on / type ext4 (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1016356k,nr_inodes=184594,mode=755)
proc on /proc type proc (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
tmpfs on /tmp type tmpfs (rw,noatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noatime,mode=755)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /var type tmpfs (rw,noatime)
tmpfs on /media type tmpfs (rw,noatime)
/dev/mmcblk2p3 on /usr/local type ext4 (rw,noatime,nodiratime,nodelalloc,data=journal)
/dev/mmcblk2p1 on /boot type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mmcblk2p3 on /media/usb1 type ext4 (rw,nodev,noexec,noatime,nodiratime,nodelalloc,data=journal)
192.168.133.31:/volume1/HomeMatic on /mnt type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.133.31,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.133.31)

Mein Backup läuft auf den NFS-Share und Diagramme nutze ich nicht, sodass ich von dem Problem mit großen Backups nicht betroffen bin.

Leider kann ich dir nicht mehr sagen, von welchem RaspberryMatic Image ich ursprünglich komme, da das Teil seit Jahren fehlerfrei läuft.

[jmaus]

ich habe gerade diesen Thread gelesen und mich daran erinnert dass meine RaspberryMatic auf dem Tinkerboard S auch fälschlicherweise behauptet ein USB-Stick wäre angeschlossen obwohl keiner angeschlossen ist:

Hmm, interessant. Dann solltest du das selbe wie von mir bereits vorgeschlagen machen: Backup erstellen, Werksreset durchführen und dann Backup wieder einspielen. Danach sollte dann hoffentlich die PARTUUID soweit wieder OK sein.