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

[hotroot]

Hallo Jens,

also ein Werksreset über die Systemsteuerung hat zumindest bei mir nicht geholfen. Die PartUUID ist immer noch falsch:

Code: Alles auswählen

root@homematic-ccu2:/var/log# 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="20ed6c32-9005-4074-8b88-40fe6cccb7bb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c8837721-03"
/dev/zram0: UUID="6575b829-641a-495c-8446-27de1cca2119" TYPE="swap"

Habe jetzt einfach mal den fix der udev-rules (https://github.com/jens-maus/RaspberryM ... b812b76e9d) implementiert und jetzt passt es.

Gruß
hotroot

[jmaus]

also ein Werksreset über die Systemsteuerung hat zumindest bei mir nicht geholfen. Die PartUUID ist immer noch falsch:

Code: Alles auswählen

root@homematic-ccu2:/var/log# 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="20ed6c32-9005-4074-8b88-40fe6cccb7bb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c8837721-03"
/dev/zram0: UUID="6575b829-641a-495c-8446-27de1cca2119" TYPE="swap"

Habe jetzt einfach mal den fix der udev-rules (https://github.com/jens-maus/RaspberryM ... b812b76e9d) implementiert und jetzt passt es.

Das ist nur ein Workaround. Das eigentliche Problem bleibt: deine PARTUUID ist falsch und das wird dir früher oder später auf die Füße fallen und du dich wundern warum etwas irgendwie/irgendwo nicht richtig geht wie es soll. Und das der Werksreset bei dir nicht funktioniert hat, liegt daran weil deine /usr/local Partition bereits maximal groß ist und damit dann kein resizing mit anschließendem neusetzen der PARTUUID stattfindet. Das habe ich mit folgendem Fix für die nächste Version vorgesehen zu ändern:

https://github.com/jens-maus/RaspberryM ... dacce7a068

Mit dieser Änderung solle die PARTUUID dann bei jedem Werksreset gesetzt werden, egal ob die Partition vergrößert werden muss oder nicht.

Also entweder baust du diese Änderung noch ein und machst einen neuen/frischen Werksreset oder du führst nur das folgende Kommando aus:

Code: Alles auswählen

echo -en '\xEF\xBE\xED\xDE' | dd of=/dev/mmcblk2 conv=notrunc bs=1 seek=$((0x1B8))

Und bootest danach dann neu, dann sollte die PARTUUID auch wieder stimmen ohne den Werksreset. Aber trotzdem gilt auch hier: Vor dieser änderung ein frisches Backup machen, denn du greifst mit diesem Kommando ziemlich hart auf das Medium ein

[hotroot]

No risk no fun

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="deedbeef-01"
/dev/mmcblk2p2: LABEL="rootfs" UUID="19c7da83-e45a-4972-8a99-2259623b4954" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="deedbeef-02"
/dev/mmcblk2p3: LABEL="userfs" UUID="20ed6c32-9005-4074-8b88-40fe6cccb7bb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="deedbeef-03"
/dev/zram0: UUID="1f1b6989-3c46-41cc-bb1a-9731bdbefe79" TYPE="swap"

[DJDieter]

Hallo Jens,

bei mir trat bereits am 23.09. der gleichen Fehler auf(viewtopic.php?f=65&t=61136&p=606423#p606423). Ich hatte immer nach dem Flashen einer neuen SD-Karte die User-Partition manuell auf ein Maximum erhöht und bis dahin gab es keine Probleme. Seit dem 23.09. mußte ich nun nach jedem Reboot händisch die ganzen Mounts berichtigen. Jetzt weiß ich wenigstens den Grund dafür und werde nach deinem Workaround bei Gelegenheit mein System reparieren. Bei mir stehen die PARTUUID ebenfalls nicht auf "deedbeef-XX".

Komischerweise trat der Fehler nur bei meinem Wirksystem auf. Mein Ersatzsystem hat trotz gleichem Vorgehen die PARTUUID richtig gesetzt.

Vielen Dank Jens für deinen unermüdlichen Einsatz.

[jmaus]

bei mir trat bereits am 23.09. der gleichen Fehler auf(viewtopic.php?f=65&t=61136&p=606423#p606423). Ich hatte immer nach dem Flashen einer neuen SD-Karte die User-Partition manuell auf ein Maximum erhöht und bis dahin gab es keine Probleme.

Und genau da liegt ja der Fehler. Wie genau bist du denn auf die Idee gekommen die userfs selbst ausserhalb von RaspberryMatic auf ein Maximum zu vergrößern?!? Das ist nirgends so dokumentiert in der RaspberryMatic Dokumentation und damit hast du dir dann quasi selbst genau dieses Ei gelegt!

Das nächste mal einfach einen Werksreset machen oder die frisch mit RaspberryMatic bespielte SD Karte einfach 1x booten lassen und dann vergrößert er selbstständig die userfs Partition und setzt dann auch die PARTUUID auf den einzig korrekten Wert. Alles andere ist Murks bzw out-of-specs.

[DJDieter]

Wie genau bist du denn auf die Idee gekommen die userfs selbst ausserhalb von RaspberryMatic auf ein Maximum zu vergrößern?!?

Das stammt noch aus der Original-CCU-Firmware-Zeit. Soviel ungenutzter Speicherplatz war mir ein Dorn im Auge. Dass die RaspberryMatic-Firmware das automatisch macht, war mir nicht bewußt.

[Hütte]

@jmaus
Hallo Jens,

den Fall hatten wir schon öfters hier im Forum, dass nach einem Umstieg auf Raspberrymatic die Backups rekursiv anwuchsen weil wohl auch andersherum scheinbar der USB-Stick intern als Bestandteil von /usr/local/ gemountet wurde, obwohl nach Angaben der Nutzer sie hier nichts geändert oder manuell angelegt haben.

Aber irgendwie deutet sich hier eine Parallelität an. Umstieg von einer CCU2 mit SD-Karte für Diagramme direkt auf eine Raspberrymatic-Version, die für die Diagramme einen USB-Stick erfordert oder über einen Zwischenschritt über die CCU3, an der eventuell noch kein USB-Stick verwendet wurde.

Auch ich hatte zuerst eine CCU2 mit SD-Karte für die Diagramme. Bin aber schon seit fast den ersten Versionen von RaspberryMatic dabei, anfangs mit einem Pi3. Damals wurden die Diagrammdaten in RaspberryMatic noch auf die SD-Karte mit dem System unter /usr/local/sdcard/measurements/ abgelegt. Und ein Update über die WebUI war noch nicht möglich. Später kam dann, erst in RaspberryMatic und später auch auf der CCU3, die Voraussetzung hinzu, dass für die Diagrammdaten ein USB-Stick notwendig ist. Aktuell bin ich auf einem Tinker-S mit angeschlossenem USB-Stick, den einfach vom Pi3 übernommen hatte. Ich habe bei mir dieses Problem nicht, aber wohl, weil ich diese ganzen Enwicklungskette mitgemacht hatte.