RaspberryMatic SD Karte als USB Speicher nutzen

[Shaker]

Aloha!

Seit der Version 3.37 (vielleicht auch seit 3.35) können die Diagramme nicht mehr auf die SD Karte geschrieben werden, die bei einem RaspiMatic ja ohnehin im Gerät steckt. Es muss ein USB Speicher angeschlossen werden. Das kann Vorteile haben, wenn die SD Karte geflashed werden muss, dann sind die Diagrammdaten auf dem USB Stick immer noch da.
Ich für meinen Teil will aber keinen zweiten Speicher in den Raspi stecken, sondern arbeite da lieber mit Backups, falls die SD Karte mal plattgemacht werden muss.

Daher meine Lösung:
Ein Skript mit dem Inhalt:

Code: Alles auswählen

#!/bin/sh
ln -s /usr/local/sdcard /media/usb0
touch "/var/status/USBinitialised"
touch "/var/status/SDinitialised"

Diese Zeilen müssen (am besten beim booten) ausgeführt werden, um der WebUI das Vorhandensein eines USB Speichers zu simulieren. Die Zugriffe auf den Haupt-USB-Speicher (im Filesystem /media/usb0) werden auf die bereits gemountete SD Karte (in /usr/local/sdcard) umgeleitet.

Habe nur noch keine Lösung für den Bootvorgang. Kann da einer helfen, dass das Skript automatisch ausgeführt wird? Einfach in init.d platzieren funktioniert leider irgendwie nicht.

[jp112sdl]

Moin!

Hast du mal getestet, zu welchem Zeitpunkt beim Booten der Symlink und die Dateien existieren müssen?

Es kämen mir zunächst 2 Varianten in den Sinn:
1.) Aufruf des Skripts durch ein Programm in der WebUI.
Ein Programm (ohne WENN Bedingung) wird beim Starten der ReGa eh ausgeführt.
Dort kann man im DANN das Shell-Skript mit system.Exec() aufrufen

2.) Hinterlegen des Skripts in /etc/config/rc.d
Dann wird es aber auch in einem recht späten Stadium des Bootvorgangs ausgeführt.

Wenn das Ausführen des Skripts aber an der Stelle schon zu spät ist, weil z.B. HMIPServer beim Start bereits die status-Files prüft, dann müsste das Skript (als ordentliches Init-Skript) im /etc/init.d mit S(<62) ausgeführt werden.

[Familienvater]

Hi,

primärer Hintergrund der Übung ist es nicht, das beim Flashen der Karte die Diagrammdaten im /dev/nul landen, sondern das die Karte länger hält, weil ohne Diagrammdaten auf der SD-Karte serienmäßig nur die Rega regelmäßig auf die Karte geschrieben wird, und die Gefahr deutlich geringer ist, das bei einem unsauberen Shutdown (z.B. durch Stromausfall) keine Dateien offen sind, und der Raspi danach beim Booten nicht wegen einem defekten Dateisystem hängen bleibt.

Wer also unbedingt potentielle Showstopper einbauen will, die nach Murphy dann zuschlagen, wenn man keinen physikalischen Zugriff auf die Zentrale hat, der kann das ja gerne machen, aber bitte nachher nicht jammern.

Der Familienvater

[jmaus]

Auch wenn es technisch natürlich möglich ist das ganze wieder (wie teilweise hier beschrieben) auf die Nutzung der SD Karte umzubiegen, so möchte ich hier trotzdem nicht unerwähnt lassen, das die Umstellung auf den Zwang eines USB Sticks für die Speicherung der Diagrammdaten nicht ohne Grund passiert ist in der 3.x.x Firmware. Es gab in der Vergangenheit einfach zu viele Hinweise darauf, dass die dauerhafte Nutzung der internen microSD Karte für das Speichern der Diagramme auf Dauer zu Problemen führen kann.

Insofern kann ich von solchen Lösung wie sie hier beschrieben werden nur abraten und alle dazu aufrufen den kleinen Aufwand in Kauf zu nehmen bei Nutzung der Diagrammfunktionen doch bitte in der Tat einen externen USB Stick zu nutzen. Das hat bei RaspberryMatic dann zumindest noch den zusätzlichen Charme, das dann auf diesen USB Stick automatisch jede Nacht auch Einstellungsbackups (*.sbk) gemacht werden und man sich dann (wenn man kein NAS, etc. hat) darüber auch keine Gedanken mehr machen muss.

Auch gebe ich noch zu bedenken das durch das eigene "umbiegen" von /media/usb0 auf einen anderen Pfad das zur folge haben wird, das sobald man einen USB Stick einsteckt dieser Pfad wieder vom System selbst abgeändert wird. Des Weiteren werden dann die automatischen Backups auch dort landen auf das /media/usb0 zeigt und somit dann eben zwangsläufig auf /usr/local, was wiederum ein Problem darstellen könnte.

[Xel66]

Das kann Vorteile haben, wenn die SD Karte geflashed werden muss, dann sind die Diagrammdaten auf dem USB Stick immer noch da.

Das kann nicht nur Vorteile haben, sondern es hat ganz handfeste. Wenn im Moment eines Schreibvorganges auf einen Speicher die Spannung unterbrochen wird, oder der schreibende Rechner abstürzt, dann kann dabei das ganze Dateisystem beschädigt werden. Somit ist das Betriebssystem nicht start- und lauffähig. Das heißt im Umkehrschluss auch, dass Du in diesem Falle bei Deinem Vorgehen (wie mit der bisherigen Lösung auch), die aufgezeichneten Daten gänzlich verlierst und die Karte komplett neu gemacht werden muss. Ja, den Passus mit den Backup habe ich gelesen, aber nicht jeder hat die Infrastruktur für ein externes Backup.

Bei einem USB-Speicher hast Du für Deine Daten wenigstens noch eine 50%ige Chance (eher mahr, wenn das Betriebssystem lauffähig ist). Und vom Hersteller wurde vermutlich auch das Schreiben auf die einzusetzende SD als separaten Speicher nicht nur wegen der Speicherknappheit der originalen CCU vorgesehen. Es ist davon auszugehen, dass deren Beweggründe ähnlich waren. In den aktuellen Lösungen mit Raspberry ist aber die eingesetzte SD auch das Bootmedium mit der Firmware und den daraus resultierenden "Nachteilen". Aber jeder wie er will. Das nur als Hinweis für Nachahmer. Ich halte die Entscheidung, die Diagrammdaten auf ein separates Speichermedium auszulagern für zielführend, zumal USB-Speicher wirklich "kein" Geld kosten und der Raspberry über ausreichend Anschlüsse verfügt. Es gibt eigentlich keinen Grund für die hier vorgestellte Maßnahme, außer der "Wunsch" des Anwenders (aus welchen Grund auch immer). Aber ich will hier keine Grundsatzdiskussion auslösen, nur mal einen Kommentar abgeben.

Gruß Xel66

EDIT: zu lange getippt, Jens war schnelle. Ich lasse es aber trotzdem stehen.

[NickHM]

da ich keine Lust auf redundante Beiträge habe ..

viewtopic.php?f=65&t=45671&p=459627#p459627

[Shaker]

Danke für alle Inputs. Bezüglich des Startskripts habe ich grad auch in der rcS gesehen, dass da alle, die mit S... beginnen der Reihe nach ausgeführt werden, also ist es wohl das Einfachste, mein Skript entsprechend zu benennen, am besten nach S06, denke ich, also vielleicht "S07InitSD". Ohne komplett zu verstehen, warum zunächst nur die rcS ausgeführt wird. Funktioniert tatsächlich auch.

Die Vorteile einer separaten Speicherung auf einem USB Stick leuchten ein, ja. Falls irgendwann mal Probleme auftreten, weil die SD Karte "abgenutzt" ist oder nach einem Stromausfall, weiß ich ja, wie man's rückgängig macht. Und ja, wenn ich jetzt einen USB Stick einstecken würde, würde usb0 überschrieben werden, das wurde mir dann auch bewusst, hatte es aber sowieso nicht vor.

[jp112sdl]

Ist es tatsächlich so? - Ist die Lebensdauer einer SD Karte wirklich geringer als die eines USB-Sticks?
Werden unterschiedliche Flash-Speicher-Technologien eingesetzt? Ich finde leider keine verlässlichen Angaben im Internet.

Aus eigener praktischer Erfahrung kann ich in den letzten 4-5 Jahren jedoch bisher 4 defekte USB-Sticks vorweisen, ggü. 0 defekten SD Karten.

Ich persönlich präferiere auch nach wie vor die SD Variante.

[Shaker]

Ist es tatsächlich so? - Ist die Lebensdauer einer SD Karte wirklich geringer als die eines USB-Sticks?
Werden unterschiedliche Flash-Speicher-Technologien eingesetzt? Ich finde leider keine verlässlichen Angaben im Internet.

Aus eigener praktischer Erfahrung kann ich in den letzten 4-5 Jahren jedoch bisher 4 defekte USB-Sticks vorweisen, ggü. 0 defekten SD Karten.

Ich persönlich präferiere auch nach wie vor die SD Variante.

Vermutlich geht es eher darum, dass auf der SD Karte das OS drauf ist und man im Falle eines Defektes, lieber den USB Stick tauscht, anstatt sich ne neue SD Karte zu machen. Die Flash-Technik wird dieselbe sein, klar. Aber darüberhinaus hatte ich auch noch kein Flash-Speichermedium, das den Abnutzungstod gestorben ist.

[jmaus]

Danke für alle Inputs. Bezüglich des Startskripts habe ich grad auch in der rcS gesehen, dass da alle, die mit S... beginnen der Reihe nach ausgeführt werden, also ist es wohl das Einfachste, mein Skript entsprechend zu benennen, am besten nach S06, denke ich, also vielleicht "S07InitSD". Ohne komplett zu verstehen, warum zunächst nur die rcS ausgeführt wird. Funktioniert tatsächlich auch.

Wenn du solche "harten" Modifikationen vornimmst, sollte dir aber auch bewusst sein das diese nach einem Firmware-Update komplett wieder verschwunden sein werden. Lediglich alles unter /usr/local überlebt ein Firmware-Update und das gesamte rootfs wird bei einem Firmware-Update eben durch das neue "platt" gemacht.