USB-Boot Mode Pi3B / Pi4B - Speicherverzeichnis in /usr bereitstellen um Nutzer-, Diagrammdaten und Backups speichern zu können

[Baxxy13]

Is your feature request related to a problem? Please describe. Momentan ist es bei von USB-bootenden RaspberryMatics nicht (ohne manuelle Eingriffe) möglich Nutzerdaten zu speichern. Das betrifft z.B. WebUI-Diagramme, nächtliche Backups oder die CCU-Historian Datenbank. Grund ist das "kein USB-Speicher" zur Verfügung steht.

Describe the solution you'd like Idealerweise erkennt RaspberryMatic beim booten das keine SD-Karte (mmcblk) vorhanden ist und verlinkt media/usb0 mit einem Verzeichnis innerhalb von /usr. Der Einfachheit halber am besten similar zur .ova Version nach /usr/local/sdcard.

Describe alternatives you've considered Als Alternative könnte ich mir eine vom Nutzer anzulegende Datei (z.B. /usr/local/etc/config/UsbBootOnly ) vorstellen die RaspberryMatic beim booten erkennt und bei deren Vorhandensein usb0 entsprechend zu einem Verzeichnis in /usr verlinkt wird.

Additional context Bei der .ova ist es meines Wissens momentan so das in der /usr/local/sdcard auch gleich die .nobackup angelegt wird. Das bewahrt natürlich davor z.B. die Historian-Datenbank mit ins Backup aufzunehmen. Das Backup Verzeichnis selber (/usr/local/sdcard/backup) bekommt auch eine .nobackup, somit ist dahingehend alles i.O.. Andererseits wird durch /usr/local/sdcard/.nobackup --> /usr/local/sdcard/measurement vom Backup ausgeschlossen und dementsprechend landen die Diagrammdaten nicht mit im Backup. Kann man alles selbst beeinflussen. Trotzdem sollte man überlegen was hier die beste Vorgehensweise wäre.

[Newbie-2]

Ab welcher RaspberryMatic Version ist eine automatische Abfrage nach dem Bootmedium (Speicherkarte-SDHC oder USB-SSD) zwecks Umstellung der USB0 bis USB8 Speicherplätze, geplant ? Erst dann könnten die täglichen Backups und Historian genutzt werden. Ein manueller Workaround macht ja keinen Sinn, wenn ein Update die Information der Speicherpläte wieder löscht.

[Baxxy13]

Ein manueller Workaround macht ja keinen Sinn, wenn ein Update die Information der Speicherpläte wieder löscht.

Mein Workaround den ich im anderen Ticket beschrieben hatte übersteht problemlos Systemupdates. Nur eine /usr/local/sdcard/.nobackup sollte noch angelegt werden.

Man kann das Backup auch wieder auf SD-Boot Pi's zurückspielen, muss aber nach dem ersten Start die angelegte /usr/local/etc/rc.local (oder dessen Inhalt bezüglich des Symlinks) löschen und nochmal rebooten.

[jens-maus]

... oder einfach noch ein bisschen warten. Geplant habe ich dieszgl. verbesserungen. Muss nur Zeit und Muße dazu finden :)

[jens-maus]

@Baxxy13 Das geht vielleicht sogar schneller als erwartet. Kannst du mal bitte folgende Änderung der /etc/init.d/S01InitHost Datei überprüfen. Vielleicht setzt diese ja bereits das nutzen von /usr/local als Diagramm und Backup speicher ausreichend um:

--- /etc/init.d/S06InitSystem
+++ /etc/init.d/S06InitSystem
@@ -90,7 +90,7 @@ init_system() {
   # on a virtual ova platform system we put diagrams on the
   # same disk in the old /usr/local/sdcard directory path and
   # don't force to use an external USB thumb drive.
-  if echo "${HM_HOST}" | grep -q ova-; then
+  if grep " /usr/local " /proc/mounts | grep -qv "^/dev/mmc"; then
     if [[ ! -d /usr/local/sdcard/measurement ]]; then
       mkdir -p /usr/local/sdcard/measurement
     fi

[Baxxy13]

folgende Änderung der /etc/init.d/S01InitHost Datei überprüfen

Das war ein "bist du schon wach Test", oder?

Spaß beiseite. Habe die entsprechende Zeile in der /etc/init.d/S06InitSystem ausgetauscht.

Ergebnis:

• das Verzeichnis: /usr/local/sdcard wird angelegt, inclusive inkludierter .nobackup und inkludiertem measurement Verzeichnis
• die erste Ausführung von /bin/cronBackup.sh legt entsprechend das Verzeichnis /usr/local/sdcard/backup mit inkludierter .nobackup an und das Backup wurde gespeichert
• die allgemeinen Einstellungen in der Systemsteuerung geben an das ein externer USB-Speicher vorhanden ist

Fazit:

Aus meiner Sicht ist das Problem gelöst

[jens-maus]

Sehr gut! Dann bitte noch gegencheck das bei nutzung einer microSD trotzdem alles wieder wie vorher funktioniert. Und was passiert wenn man zusätzlich noch einen USB stick stecken hat? Und die ova variante müsste man dann auch nochmal testen mot der Änderung.

[Baxxy13]

Ich kann erst Anfang nächster Woche alles ausgiebig durchtesten. Vielleicht hilft ja jemand mit / springt ein.

Und was passiert wenn man zusätzlich noch einen USB stick stecken hat?

Das ist bei von USB-bootenden Pi's (noch) verboten. Siehe: #416

Edit: Man kann interessanterweise nun doch mit einem 2. angesteckten USB-Stick booten. Hatte ich lange nicht getestet. Der wird als usb1 eingebunden und das wars. Genutzt wird weiterhin /usr/local/sdcard.

[Newbie-2]

Ich kann unter FTP SSH (Port: 22) Zugriff zwar die Datei "/etc/init.d/S06InitSystem" auf den PC kopieren und abändern. Aber ich kann die geänderte Datei nicht auf den Pi4 zurück kopieren. Nutze aktuell den SSH Benutzer und Passwort, welches ja funktioniert. Muss ich dafür noch irgendwelche Rechte verändern ?

Wenn ich die Pi4-SSD am PC anschließe, wird mir nur die Startpartition angezeigt. Die Systempartition die ich unter SSH aufrufen kann wird unter Windows als unformatiert ausgewiesen.

Welcher Weg für das ändern der Daten in einem Sytemverzeichniss ist der Beste, wenn ich den Test unterstützen möchte ?

[Baxxy13]

Ich als Windows User nutze dafür meistens WinSCP. Vorher musst du aber das Dateisystem der RaspberryMatic beschreibbar machen (per ssh-Sitzung z.B.) um deine Änderungen auch speichern zu können. mount -o rw,remount /

Wenn alles fertig ist dann wieder mount -o ro,remount / oder halt rebooten.

[jens-maus]

Hab nun wie gewünscht diese Funktionalität integriert. D.h. mit dem nächsten nightly snapshot und dem kommenden release im Januar sollte es dann entsprechend integriert sein und bei einem USB Boot automatisch der /usr/local/sdcard pfad genutzt werden um diagramme und die nächtlichen Backups zu speichern.

[Baxxy13]

wie gewünscht diese Funktionalität integriert

Als erstes... Danke, es funktioniert wie gewünscht. Aber: Bei jedem Reboot wird innerhalb der /usr/local/sdcard die .nobackup erzeugt. Demzufolge landen alle Unterverzeichnisse (/measurement; /historian, etc.) nicht mit im Backup. Das Unterverzeichnis /backup bekommt ja selbst auch noch eine .nobackup somit besteht "keine Gefahr" das die vorhandenen Backups wieder Bestandteil des Backups werden.

Ich würde es favorisieren das die /usr/local/sdcard/.nobackup nicht automatisch erzeugt wird damit der User anhand selbst angelegter .nobackup-Dateien entscheiden kann was im Backup landen soll und was nicht.

Das gilt auch für die .ova-Version, dort ist es identisch.

[jens-maus]

Das müsste man erst einmal noch genauer über alle Platformen analysieren, denn mitunter ist es ja nicht gewollt das z.B. die Daten von Historian mit um Backup landen (Historian setzt meines erachtens selbst ja inzwischen deshalb die .nobackup datei ein. Auch ein Backup der Diagrammdaten ist bis jetzt ja noch kein Standard und deshalb gibt es die extra Backup funktion die nur die Diagrammdaten herunterladen lässt. Genau aus dem Grund wirs in der /usr/local/sdcard direkt das .nobackup gesetzt um einfach sicherzustellen das das verzeichnis (falls es eben auf einem externen medium liegt) nicht mit ins Backup aufgenommen wird. Bin mir also weiterhin unsicher wie man da genau herangehen sollte, denn ich sehe schon wieder hundertfach Nachrichtem im Forum auftauchen wo leute sich beshweren das ihr Backup von 19MB auf 40MB angestiegen ist, auch wenn das natürlich aus heutiger sicher totaler Humbug ist :)

[Baxxy13]

Ich kann deine Argumente natürlich nachvollziehen. Andererseits haben wir ja bei USB-Boot Systemen und der .ova kein externes Medium was man mal abstöpselt und zusätzlich sichert. Ich habe z.B. außer dem Historian-Datenbank Verzeichnis auch noch separate Verzeichnisse für die Historian-Logs, CUxD-Devlogs (Highcharts) sowie CUxD-Systemlogs. Das alles lag sonst auf dem USB-Stick und war dementsprechend auf einer "neuen" Zentrale sofort verfügbar. Jetzt müsste ich alles was in /usr/local/sdcard steckt regelmäßig händisch wegsichern für den Fall das mal was schiefläuft.

Der größte "Brocken" dürfte die Historian-DB sein. Eine .nobackup innerhalb des Historian-DB-Verzeichnisses wird aber meines Wissens nicht automatisch gesetzt.

Vielleicht gibt es ja noch ein paar Ideen wie man hier am besten vorgeht.

Mein "Workaround" löscht momentan nach dem Reboot die /usr/local/sdcard/.nobackup. Somit kann ich über die WebUI ein vollständiges Backup meiner Daten erzeugen. Wichtiger als die Größe ist mir ein Backup zu haben.

Die separate Diagrammdaten-Backup Funktion habe ich noch nie getestet. Die könnte ja bei meinen Vorschlag auch entfallen. ;-)

[Newbie-2]

Aktuell werden alle nächtlichen Backups und die Historian Datenbank auf USB0 gespeichert, was bei der SSD ohne USB-Stick ja auch Sinn macht. Was passiert eigentlich wenn es eine neuen Version der Raspberrymatic gibt und diese installiert wird ? Werden dann alle Daten im Speicherbereich USB0 durch die Installation überschrieben; gelöscht , oder bleiben diese erhalten ?

[Baxxy13]

Wenn RM beim booten erkennt das von USB gebootet wird dann wird ein "Link" erzeugt der von USB0 auf /usr/local/sdcard zeigt. Bootet man normal (mit SD-Karte + Stick) zeigt USB0 auf USB1.

Beim normalen WebUI Update bleiben deine Daten erhalten, genau wie alles andere im /usr - Verzeichnis. Aufpassen musst du nur wenn du komplett neu aufsetzt. Hier heißt es das ganze /usl/local/sdcard - Verzeichnis händisch zu sichern und anschließend zurückzuspielen weil es nicht Bestandteil des Backups ist.