Pi3b+ und Libreelec Hart vom Strom trennen beschaedigt Partition?

Ext4 mit journal ist eigentlich unkaputtbar als Dateisystem. Ich habe kein LibreElec, Erfahrung bloss von OSMC, aber diesbezueglich ist da garantiert kein Unterschied.

Wenn man die SD Karte zerschossen war, dann lag das an der ersten, FAT Partition. Inzwischen wird die bei mir vom System nur noch read-only remounted, seitdem hat sich da die SD Karte nicht mehr zerlegt. RPI3+ auch bloss vom Strom des Fernsehers (via USB) versorgt, schaltet sich also immer aus, wenn Fernseher ausgeschaltet wird. Muss man dann halt nur manuell read/write mounten bevor man einen systemupgrade oder ein system-re-config machen will (raspi-config oder so). Das sind die beiden einzigen Operationen AFAIK wo auf diese Partition geschrieben werden muss.

Das sich das ext4 Filesystem nicht zerschiesst heisst natuerlich nicht, das sich nicht doch Dateien durch power-off zerschiessen koennen. Wenn Kodi so config-dateien geoeffnet hat, dann kann das halt schon vorkommen, das da temporaer die datei nur partiell geschrieben wurde, wenn der strom ausfaellt. Da kann man natuerlich auch mit scripts gegen anstinken. Hatte schon beim fetten server mal das problem, das da kodi man mit bugs gecrasht war, das war fuer die user config datei genauso toedlich wie power off auf dem raspi. Seitdem wird da halt beim starten des systems geguckt, ob die user config empty ist, und wenn ja wird ein backup zurueckkopiert.

Aka: kannst entweder solche SW bastelei machen, oder halt HW-bastelei, so das der RPI nur noch kontrolliert runterfaehlt.

Zitat von te36

Wenn man die SD Karte zerschossen war, dann lag das an der ersten, FAT Partition. Inzwischen wird die bei mir vom System nur noch read-only remounted, seitdem hat sich da die SD Karte nicht mehr zerlegt.

War die /boot Partition nicht schon immer RO gemounted, wenn man Distributionen wie LE, OE, Raspbian, etc. verwendet?

Bei mir hat es (unter Raspbian) nach Stromausfällen auch schon mal Daten von der / Partition zerstört. Dann waren in einigen Dateien einzelne Bytes zerstört, was die Datei dann meist komplett unbrauchbar gemacht hat.

Sauber runterfahren vor Stromabschalten ist auf jeden Fall (auch bei journalisierenden Dateisystemen) keine schlechte Idee.

Zitat von root2

War die /boot Partition nicht schon immer RO gemounted, wenn man Distributionen wie LE, OE, Raspbian, etc. verwendet?

Kann mich nicht erinnern, das ich das so bemerkt haette, aber wie gesagt, vor allem OSMC und raspian im Einsatz, und das Raspian ewig nicht neu installiert sondern seit jahren upgegraded.

Zitat von root2

Bei mir hat es (unter Raspbian) nach Stromausfällen auch schon mal Daten von der / Partition zerstört. Dann waren in einigen Dateien einzelne Bytes zerstört, was die Datei dann meist komplett unbrauchbar gemacht hat.

Am logischten ist das zu erklaeren, wenn so wie ich das oben beschrieben habe, dieser Zustand der Datei sich ergeben hat koennen, dadurch, das da halt das Schreiben des journals zu einem bestimmten Zeitpunkt abbrach wegen Stromausfall. Ich hab da z.b. schon mal die user-config datei leer gesehen, weil Kodi die wohl auch mal komplett vom Anfang an neu schreibt, und wenn dann mittendring der Strom weg ist, dann steht da halt nach dem restaurieren des (abgebrochenen journals halt nur der anfang (der null sein kann) drin.

Zitat von root2

Sauber runterfahren vor Stromabschalten ist auf jeden Fall (auch bei journalisierenden Dateisystemen) keine schlechte Idee.

Naja, journalbasierende Dateisystem existieren im Prinzip ja bloss um den Fall eines NICHT sauberen herunterfahrens zu unterstuetzen. Aber wie erklaert schuetzen die halt bloss die Dateisystemstrukturen durch ein journal mit sauberen checkpointing. Fuer die konsistenz der Dateiinhalte bei beliebigem Stromausfall muessten halt die schreibenden Anwendungen selbst passend checkpointing machen. Was halt die normalen linux anwendungen nicht machen.

Ich wuerde nie einen RPI an unkontrolliertem Strom betreiben, wenn der relevant neue Daten schreiben muesste, also sagen wir mal Aufnahmen aufnehmen oder so. Aber wenn der RPI bloss zum abspielen von Medien via Kodi verwendet wird, dann ist da halt sehr wenig, was geschrieben wird. In erster Naeherung halt NIX, und in zweiter Naeherung halt leider sowas wie die user-config, und da kann man halt workarounds basteln. Und so software workarounds basteln ist halt einfacher, als so hardware mit fettem 1 fahrrad kondensator und IRQ ausloesung, die dann im linux die buffers flusht wenn die stromversorgung weggeht. Hab sowas naemlich leider auch nicht fertig als modul bisher gesehen... oder doch ? Kann mich gar nicht mehr erinnern.

Zitat von Megacayman8x

Danke fuer deine Antwort, das wollte ich wissen
Dann lags vll an dem Stick den ich fuer Backups angeklemmt habe, war glaub nen Fat fornatierter aber angeschlossen hab ich den ueber eine USB Verlaengerung (ca 20 cm oder 30 cm) was ich aber nicht verstehe ich hab den extra nach der wiederherstellung wieder abgestoepselt , hing nur die Verlaengerung drann wenn ich wieder was einspielen will, dsas ich nich ans Pi hinter der Glotze muss .

Was schlaegst du vor ? Das dann vll besser in zukunft ueber die NFS Freigabe der Synology klaere mit dem Backup einspielen? Habs halt am PC im Kodi gebastelt und dann via Backup alles beim Pi eingespielt, koennte das vll das Problem gewesen sein ? → Hat anfangs aber ja funktioniert fuer bestimmt 10 mal starten.

Kapiere noch nicht so genau, was Du da machst. Ein USB Kabel an dem nix dran ist sollte AFAIK nicht stoeren. Was genau machst Du da fuer" backup ?

Ich mache halt inkrementell backup vom Raspi ab und zu mal manuell wenn ich weiss das er nicht abgeschaltet wird und dann halt einfach per rsync auf eine kopie auf einem server. von der kopie kann man dann immer recht einfach die sd neu erstllen, wenn noetig.

Ich habe bei meinem alten Pi3 und Kodi den andauernd "hart" getrennt. War nie ein Thema, das hat er problemlos weggesteckt.

Ob es bisher immer geklappt hat ist ja auch nur eine Frage der Wahrscheinlichkeit, bis es mal nicht mehr klappt.

Sauber runterfahren schadet jedenfalls nicht.

Ist ja auch nicht so, dass ich mein Fahrzeug immer so "abschalte", dass ich es abwürge, indem ich die Kupplung im ersten Gang schnellen lasse, wenn ich auf dem Parkplatz angekommen bin

Ich habe das täglich über mindestens 1,5 Jahre gemacht und hatte nicht einen Defekt. Bei über 500 harten Abschaltungen werde ich wohl kaum nur Glück gehabt haben. Ich denke, dass es an der Qualität der SD-Karte liegt, sowie eventuell daran, welche Addons installiert sind und eventuell dadurch zusätzliche Schreibvorgänge durchgeführt werden.

Inzwischen bin ich soweit, dass ich ein Script auf einem anderen Gerät (Linuxserver) laufen habe, welches alle 5min mittels Anpingen prüft, ob der Fernseher noch läuft. Wenn nicht, wird diese Prüfung nach 60s wiederholt, dann noch mal nach 120s. Wenn alle drei Versuche erfolglos waren, signalisiert das Script durch einen Aufruf dem Kodi, dass er runterfahren soll. Das macht er dann und so ist ein hartes Abschalten nicht mehr nötig.

Naja, qualitaet der SD Karte ist evtl. nicht das vorrangige. Das haengt auch viel von der Software ab. Die erste Partition geht mir z.b. regelmaessig kaputt wenn die schreibbar gemountet ist und ich hart abschalte, aber nie, wenn sie read-only gemountet ist. Aber ob sie kaputt geht, wenn sie schreibbar gemountet ist haengt halt auch vom OS und den Anwendungen ab. Glaube wenn da irgendeine Datei auf der partition offen in einer anweendung ist dann ist die chance das zumindestens die datei danach futsch ist groesser.

qualitaet der sd karte ist in meiner erfahrung eher wichtig fuer die anzahl scheibzyklen bevor die sd karte abkackt.

das linux ist die zweite partition, die muss schreibbar sein, allerdings sollte natuerlich so wenig wie moeglich geschrieben werden, wegen lebensdauer der SD Karte. Da sollte im allgemeinen eine spezielle distribution, wie hoffentlich LibreElec optimiert sein gegenueber einem allgemenen OS wie raspian.

Geht ja um die vfat boot partition. um die read-only zu mounten, guckste z.b. hier:

https://indibit.de/raspberry-pi-d…nt-rw-mount-ro/

musste halt dann read-write mounten, wenn du einen update vom OS machst oder eine systemconfig app laufen laesst, die wollen jeweils auf die boot partition schreiben.