filesystem Read Only machen

http://blog.pi3g.com/2014/04/make-raspbian-system-read-only/

Dein Problem ist nicht, dass du bisher kein read-only Dateisystem hast, 
sondern dass die Daten auf der Karte zerstört werden.

Gehe also nochmal einen Schritt zurück und frag dich: Wie kannst du 
deine Daten schützen?
Vermutlich dürfte es schon ausreichen, eine gute / andere SD-Karte zu 
verwenden. Ich habe auf meinem Raspi im DAUERBETRIEB bisher noch nie ein 
solches Problem gehabt. Der läuft >100 Tage ohne Neustart durch.

Also probiere lieber mal eine andere Karte aus, das scheint eher das 
Problem zu sein!

Das Problem ist nicht unbedingt die sd Karte sondern das 
unvorhergesehene trennen der Spannungsversorgung. Da passiert es öfter 
mal das das Dateisystem kaputt geht. Alternativ eine power bank als USV 
dazwischen schalten und dann sauber herunterfahren

@ raspi_null (Gast)

>> Der läuft >100 Tage ohne Neustart durch.

>Leider wird meinem Pi mindestens zweimal am Tag der Saft entzogen?

Das sollte man ändern. Wenn der Stromausfall ohne Vorwarnung kommt, muss 
man die Versorgung mit einem Akku puffern, der mittels Diode angeklemmt 
wird. Sprich, Netzteil sowie Akku speisen über jeweils eine 
(Schottky)diode deine Himbeere.

@ raspi_null (Gast)

>> Das sollte man ändern.

>Sollte oder muß man?

Kommt drauf an.

>Wäre das Read Only keine Option?

Das müsste man im Linux-Kernel einstellen, daß KEINERLEI SWAP auf der 
SD-Karte stadtfindet. Soweit ich weiß geht dann aber die Leistung der 
Himbeere endgültig in den Keller.

raspi_null schrieb:
> Johannes O. schrieb:
>> Der läuft >100 Tage ohne Neustart durch.
>
> Leider wird meinem Pi mindestens zweimal am Tag der Saft entzogen?
> Lg

DA haben wir auch schon das Problem!
Diese Info hat im ersten Post gefehlt...


ist ein Pufferakku (beispielsweise eine billige Power-Bank zum 
Handyladen) eine Option für dich? Erkenne den Ausfall des Netzes und 
fahre anständig herunter.

Was die Karte INTERN macht weißt du nämlich auch nicht. Die 
Wahrscheinlichkeit dass etwas passiert ist zwar geringer, aber sicher 
kannst du das nicht sagen.
(Zumindest bei SSDs ist das so: Da laufen intern Prozesse ab die Daten 
auffrischen. Das willst du nicht unterbrechen!)

Falk B. schrieb:
> @ raspi_null (Gast)
>
>>> Der läuft >100 Tage ohne Neustart durch.
>
>>Leider wird meinem Pi mindestens zweimal am Tag der Saft entzogen?
>
> Das sollte man ändern. Wenn der Stromausfall ohne Vorwarnung kommt, muss
> man die Versorgung mit einem Akku puffern, der mittels Diode angeklemmt
> wird.

Oder eben alles read-only mounten. Was meinst du, wie das die ganzen 
Linux-basierten Router, Printserver und so machen? Meinst du ernsthaft, 
die haben  alle eine USV eingebaut, um beim Ausstecken noch runterfahren 
zu können?

Falk B. schrieb:
> @ raspi_null (Gast)
>
>>> Das sollte man ändern.
>
>>Sollte oder muß man?
>
> Kommt drauf an.
>
>>Wäre das Read Only keine Option?
>
> Das müsste man im Linux-Kernel einstellen, daß KEINERLEI SWAP auf der
> SD-Karte stadtfindet.

Was verstehst du unter "im Linux-Kernel"? Das stellt man in der 
/etc/fstab ein.

> Soweit ich weiß geht dann aber die Leistung der Himbeere endgültig in den
> Keller.

Das ist weniger ein Problem mit der Leistung, als damit, daß der 
OOM-Killer zuschlägt, wenn der Speicher alle ist.

Rolf M. schrieb:
> Oder eben alles read-only mounten. Was meinst du, wie das die ganzen
> Linux-basierten Router, Printserver und so machen? Meinst du ernsthaft,
> die haben  alle eine USV eingebaut, um beim Ausstecken noch runterfahren
> zu können?

Es ist falsch, das direkt zu vergleichen!

Diese Embedded Geräte haben zwar durchaus ein read-only Dateisystem. 
Aber praktisch alle haben mindestens eine Partition, die auch schreibbar 
ist. Dort werden Konfigurationsdaten abgelegt.
Auf dieser Partition kommen spezielle Dateisysteme zum Einsatz, die ein 
hartes Ausschalten besser vertragen als ein "normales" Dateisystem.

Die eingesetzten Speicher sind KEINE SD-Karten, sondern einfachere Flash 
ICs. Die haben intern deutlich weniger Intelligenz, da passiert in der 
Regel nichts im Hintergrund, im Gegensatz zu SD-Karten.


Also hier bitte keine falschen Schlüsse ziehen.

raspi_null schrieb:
> Rolf M. schrieb:
>> Oder eben alles read-only mounten. Was meinst du, wie das die ganzen
>> Linux-basierten Router, Printserver und so machen?
>
> Also doch eine Gute Idee?
> Hast Erfahrung damit?
> Kenne mich mit Linux leider nicht gut aus.

Ich hab bisher noch kein Debian auf read-only umgestellt, nur mal ein 
minimalistisches Linux benutzt, das von einer CF-Karte im 
read-only-Betrieb läuft.

Johannes O. schrieb:
> Diese Embedded Geräte haben zwar durchaus ein read-only Dateisystem.
> Aber praktisch alle haben mindestens eine Partition, die auch schreibbar
> ist. Dort werden Konfigurationsdaten abgelegt.
> Auf dieser Partition kommen spezielle Dateisysteme zum Einsatz, die ein
> hartes Ausschalten besser vertragen als ein "normales" Dateisystem.

Die braucht man aber auch nur, wenn man tatsächlich was schreiben muss.

> Die eingesetzten Speicher sind KEINE SD-Karten, sondern einfachere Flash
> ICs. Die haben intern deutlich weniger Intelligenz, da passiert in der
> Regel nichts im Hintergrund, im Gegensatz zu SD-Karten.

Solange man nur liest, sollte da auch nicht viel passieren. Abgesehen 
davon sind SD-Karten ja eigentlich primär für Geräte gebaut, die man 
laufenden Betrieb ausschaltet.

@ raspi_null (Gast)

>Sorry habe aber jetzt nicht ganz verstanden ob nun gut ist ein read only
>Filesystem zu haben oder nicht!

Probier es einfach aus! In einigen Situationen hat es keine Nachteile, 
in anderen schon.

Die Anleitung enthält auch ein link auf ein deutsches Howto...
Und ja das klappt so, wenn die Anleitung korrekt ist. Ich habe es nur 
überflogen aber das tmpfs wird dort genutzt und es sieht schlüssig aus. 
Du verlierst bei einem Stromausfall nur die Daten die ins tmpfs 
geschrieben wurden. Der Rest vom System bleibt erhalten. Allerdings 
weiss ich nicht ob sich deine SD auch beim nur lesen verabschiedet. Das 
musst du testen, sollte es so sein hast du noch ein anderes Problem( zu 
wenig Ram? Defekten Ram? Sd defekt etc...)
Viel Erfolg!

raspi_null schrieb:
> Johannes O. schrieb:
>> Der läuft >100 Tage ohne Neustart durch.
>
> Leider wird meinem Pi mindestens zweimal am Tag der Saft entzogen?

http://www.piusv.de/

Falk B. schrieb:
> Das müsste man im Linux-Kernel einstellen, daß KEINERLEI SWAP auf der
> SD-Karte stadtfindet.

Das erreicht man, indem man einfach kein Swapdevice / keine Swapdatei 
eingebunden wird. Im Kernel kann man nur die Neigung zum Swappen 
einstellen (/proc/sys/vm/swappiness).

> Soweit ich weiß geht dann aber die Leistung der Himbeere endgültig in den
> Keller.

Das kommt darauf an, was man damit macht. Wenn genug Arbeitsspeicher zur 
Verfügung steht, so daß Applikation(en) und Dateisystempuffer 
hineinpassen, ändert sich überhaupt nichts an der Leistung. Erst wenn 
der Arbeitsspeicher knapp wird, zwackt der Kernel den benötigten 
Speicher vom Dateisystempuffer ab, was sich auf die Performance von 
Dateioperationen auswirken kann. Aber solange ausreichend freier 
Speicher vorhanden ist, läuft Linux so schnell und stabil wie immer.

Jörg E. schrieb:
> Die Anleitung enthält auch ein link auf ein deutsches Howto...

Das wollte ich auch eben schreiben, aber dann habe ich auf den Link 
geklickt und bekam unverhofft einen 404 geschenkt. ;-)

Ups, den link hatte ich nicht "überflogen" ;) Die ganze Site scheint 
auch down zu sein. Dann
Musste wohl suchen...

Alter Thread aber nach wie vor aktuell.
Hat hier inzwischen jemand handfeste Langzeiterfahrungen?

Alle Raspberries (hauptsächlich als Medienplayer / Mediensteuerung) die 
ich mit read-only Dateisystem verwende funktionieren >2 Jahre ohne 
Probleme.
Morgens Strom an, Abends aus.
Einer mit Kiosk-Browser mountet mit Schreibzuggriff, hatte aber auch 
noch nie Probleme. Als SD Karten habe ich meistens samsung evo oder 
sandisk ultra genommen.

Jetzt würde ich doch mal gerne Log-Dateien schreiben.
Was wäre da das beste Vorgehen?

1) USB Stick verwenden der dann nichts blockiert falls er nicht mehr 
funktioniert?

2) weitere Partition erstellen und lesbar mounten?
--> Siehe:
Johannes O. schrieb:
> Rolf M. schrieb:
> (...)
> Diese Embedded Geräte haben zwar durchaus ein read-only Dateisystem.
> Aber praktisch alle haben mindestens eine Partition, die auch schreibbar
> ist. Dort werden Konfigurationsdaten abgelegt.
> (...)

3) log im Ram speichern und ab und zu lesbar mounten und gesammelt 
schreiben.


Ich wüsste gerne was denn nun wirklich problematisch für die SD Karte 
ist. Wird nur das Dateisystem beim Stromausfall während des Schreibens 
gefährdet oder wirklich die Karte zerstört.
Schiebt die SD-Karte am Ende selber noch low-level Daten hin und her, 
sodass auch eine separate read-write partition zur Gefahr wird?

Ich hatte durchaus Karten gesehen, die sich unwiederbringlich 
verabschiedet haben.

Für mich gibts da mehrere Konsequenzen:
1. Keinen Pi verwenden. Punkt. Es gibt genügend Alternativen, die 
technisch besser sind. Viele von denen enthalten einen eMMC-Chip. Der 
ist wesentlich langlebiger, da habe ich noch keinen sterben gesehen.

2. Vorschlag für die, die schon ganz tief unten im Brunnen sind: 
serielles SPI-Flash verwenden. Sowas z.B.:

https://www.gigadevice.com/datasheet/gd5f2gq4xfxxg

Das ist dumm, hat also keinerlei Eigenintelligenz, schiebt daher selber 
nichts hin und her und ist damit deterministisch. Linux kann damit 
umgehen - Stichwort MTD, und es gibt genau dafür spezielle Filesysteme.

fchk

Peter M. schrieb:
> Wird nur das Dateisystem beim Stromausfall während des Schreibens
> gefährdet oder wirklich die Karte zerstört.

Es werden nur die Daten zerstört. Es kann aber auch die Daten der 
Firmware betreffen, d.h. der Controller auf der SD bootet nicht mehr 
richtig. Dann läßt sie sich auch nicht mehr neu formatieren.
Für die Industrie gibt es daher schaltfeste SSDs mit eingebautem 
Pufferkondensator. Dieser reicht aus, um das Dateisystem geordnet 
abzuschließen und die Firmware zu schützen.

Peter D. schrieb:
> Peter M. schrieb:
>> Wird nur das Dateisystem beim Stromausfall während des Schreibens
>> gefährdet oder wirklich die Karte zerstört.
>
> Es werden nur die Daten zerstört. Es kann aber auch die Daten der
> Firmware betreffen, d.h. der Controller auf der SD bootet nicht mehr
> richtig. Dann läßt sie sich auch nicht mehr neu formatieren.

Was effektiv einer Zerstörung der SD-Karte gleich kommt. Man kann sie 
nicht mehr benutzen.

> Für die Industrie gibt es daher schaltfeste SSDs mit eingebautem
> Pufferkondensator. Dieser reicht aus, um das Dateisystem geordnet
> abzuschließen und die Firmware zu schützen.

Die SSD kennt in der Regel das Dateisystem gar nicht. Wie soll sie das 
also machen? Was sie machen kann, ist, alles, was noch im Cache der SSD 
selbst ist, in den Flash zu schreiben.

Peter D. schrieb:
> Für die Industrie gibt es daher schaltfeste SSDs mit eingebautem
> Pufferkondensator. Dieser reicht aus, um das Dateisystem geordnet
> abzuschließen und die Firmware zu schützen.
Laut Werbeangaben der Hersteller. Leider funktioniert das trotzdem 
nicht. Ich bekomme das Filesystem solcher Karten ganz einfach kaputt. 
Und in eine SSD passen natürlich deutlich mehr Energiespeicher als in 
eine SD oder gar microSD.

Rolf M. schrieb:
> Die SSD kennt in der Regel das Dateisystem gar nicht. Wie soll sie das
> also machen? Was sie machen kann, ist, alles, was noch im Cache der SSD
> selbst ist, in den Flash zu schreiben.
Die Hersteller versuchen herauszufinden, welches FS verwendet wird und 
machen dann u.U. vogelwilde Tricks, die im Fehlerfall (der ja eigentlich 
nicht hätte eintreffen sollen) letztlich noch mehr Verwirrung 
erzeugen...

Stefanus F. schrieb:
> Vermutlich spielt die Menge an Daten eine Rolle, die man auf die SD
> Karte schreibt. Die ist bei mir ziemlich gering.
Der Powerfail ist ein Spiel mit Wahrscheinlichkeiten.

> Mein Internet-Monitoring Script schreibt etwa alle 10 Sekunden zwei
> Zeilen in zwei Protokolldateien.
Auch dafür müssen 2 Blöcke gelöscht und umkopiert werden...  ;-)

Peter M. schrieb:
> Ich wüsste gerne was denn nun wirklich problematisch für die SD Karte
> ist. Wird nur das Dateisystem beim Stromausfall während des Schreibens
> gefährdet oder wirklich die Karte zerstört.
> Schiebt die SD-Karte am Ende selber noch low-level Daten hin und her,
> sodass auch eine separate read-write partition zur Gefahr wird?
Sobald auf der physikalisch selben SD Blöcke gelöscht werden, werden 
beim Pass-By auch andere Blöcke ein wenig "mitgelöscht" und darin Daten 
korrumpiert. So werden dann Dateien (auch in anderen Partitionen) 
"zerschlissen", die eigentlich nur gelesen werden und Bits kippen um, 
Programme laufen nur bis an eine bestimmte Stelle, Texte haben 
eigenartige Zeichen.
Im Anhang ein Screenshot einer Datei aus einer aktuellen Samsung EVO 
Plus 32GB, bei der die uralte ZIP.exe von aussen nicht sichtbar 
(Datum/Größe) beachädigt wurde.

Und natürtlich kann dieses Pass-By Löschen auch die Frimware des 
SD-Controllers erwischen, der dann bestenfalls gar nichts mehr oder 
schlimmstenfalls irgendwelchen Unsinn macht und eine "halblebige" SD 
vorgaukelt.

Hallo Lothar,

danke für die Antwort.
Also werde ich es doch mal mit einem extra USB Flashlaufwerk versuchen. 
Sollte der dann den Geist aufgeben kann zumindest die Hauptanwendung 
weiterlaufen und es gibt eben keine Logs mehr.

Habe in der Anwendung auch eine Funktion mit der Skripte o.ä. beim 
Starten über einen USB Flashlaufwerk selbstständig ausgetauscht werden. 
Dazu muss es natürlich lesbar gemountet werden. Da der Stecker aber 
meistens nicht kurz nach dem Starten gezogen wird sollte das klargehen.

Viele Grüße. Vielleicht gibt es hier mal ein Update mit weiteren 
Langzeiterfahrungen.