Sicheres Booten nach "kaltem" Ausschalten?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Moin,

    ich nutze meine Raspberry Pis meist als Appliance (Funkempfänger mit RTLSDR), Wetterstation etc. Bei einem Stromausfall (kommt bei uns im Dorf leider 2-3x pro Jahr vor) oder wenn der Stecker gezogen wird ist gelegentlich das Dateisystem beschädigt und benötigt einen händischen Boot mit fsck.ext4, es lief aber auch schonmal dumm und ich musste /boot am Notebook reparieren.

    Die Daten sind dank täglichem Backup (mein eigen geschriebenes r5backup) nicht weg, aber da die Rechner teilweise weit weg betrieben werden und nicht an Tastatur/Bildschirm angeschlossen ist eine lästige Sache.

    Um das zu vermeiden fallen mir 2 Lösungen, die aber teuer, gross oder aufwändig sind:

    • Eine Raspberry Pi USV die gegen Ende der Akkus einen shutdown startet
    • Ein zusätzlicher Arduino mit WLAN, über den ich via RS232 das "fsck -f -y" aufrufen kann
    • ReadOnly Dateisysteme und Daten sonstwo schreiben (weiss ja nicht ....)

    Geschickter wäre ein zusätzliches Script irgendwo im Bootsystem, das vor dem eigentlichen mounten einen "fsck -f -y" für beide Dateisysteme startet. Dabei können zwar Daten verloren gehen, aber Hand auf's Herz: Wenn ich den fsck händisch aufrufe bleibt mir auch nicht viel anderes übrig als alles abzunicken.

    Gibt's da bereits etwas? Ein Script, ein Paket vielleicht, das auch ein Systemupdate übersteht?

    Dankbar für Hinweise

  • Soviel ich weiss, gibt es einen Boot-Parameter, über den du steuern kannst, ob beim Booten ein fsck durchgeführt werden soll.

    Zum Thema kontrolliertes Herunterfahren bei Stromausfall habe ich mir im Rahmen meines Wohnmobil-Projekts auch schon Gedanken gemacht. Ich plane, das Problem folgendermassen zu lösen:
    - an den Raspberry wird parallel zur externen Stromversorgung ein 5 Volt Akku angeschlossen - es genügt ein Akku mit kleiner Kapazität, die gibt es schon unter 10,- Euro
    - über einen GPIO des Raspberry wird ständig gemessen, ob die externe Stromversorgung verfügbar ist
    - falls die externe Stromversorgung zusammen bricht, fährt sich der Raspberry selbst kontrolliert herunter
    - zwischenzeitlich wird er durch den Akku mit Strom versorgt
    Automatisch zusammengefügt:
    Gerade entdeckt - so was gibt's ja schon: https://raspiprojekt.de/kaufen/shop/st…v-pi-basic.html

    Einmal editiert, zuletzt von kaiuwe (5. Februar 2016 um 08:32)


  • , es lief aber auch schonmal dumm und ich musste /boot am Notebook reparieren.

    Das macht mich etwas stutzig. /boot sollte eine FAT32-Partition sein auf der keinerlei Schreibzugriffe im Normalbetrieb stattfinden.
    Jedenfalls glaube ich nicht, das die partition durch einen powerfailure beschädigt sein soll. Wenn, dann wars was anderes....
    Automatisch zusammengefügt:


    Soviel ich weiss, gibt es einen Boot-Parameter, über den du steuern kannst, ob beim Booten ein fsck durchgeführt werden soll.

    Nein, kein Boot-Parameter.
    debian-basierte Betriebsysteme testen beim Booten auf die existenz einer Datei namens /forcefsck . Wenn diese Datei existiert, wenden die Dateisysteme in /etc/fstab vor dem einbinden geprüft. Bei ext-basierten Dateisystemen gibt es dafür ein flag, das man mit tune2fs setzen kann, um ein fsck zu erzwingen.

    Einmal editiert, zuletzt von Monarch73 (5. Februar 2016 um 09:53)


  • Soviel ich weiss, gibt es einen Boot-Parameter, über den du steuern kannst, ob beim Booten ein fsck durchgeführt werden soll.

    Doch, es gibt einen Parameter, einen FSCK auf die Linux Partition durchzuführen bevor es gemounted und gebootet wird.

    Einfach den Parameter "fsck.repair=yes" in der ersten Befehlszeile von "/boot/cmdline.txt" hinzufügen.

    Ich hoffe es hilft :thumbs1:

    Einmal editiert, zuletzt von carriba (5. Februar 2016 um 12:05)

  • Moin,

    Doch, es gibt einen Parameter, einen FSCK auf die Linux Partition durchzuführen bevor es gemounted und gebootet wird.

    Einfach den Parameter "fsck.repair=yes" in der ersten Befehlszeile von "/boot/cmdline.txt" hinzufügen.

    Ich hoffe es hilft :thumbs1:

    danke, ich fürchte das hilft nicht. Ich ging jetzt doch etwas tiefer in das Bootsystem. Es gibt (falls es nicht fies in einem Binary steckt) unterhalb von /etc nichts, das den Parameter fsck.repair auswertet. Es gibt allerdings in /etc/default/rcS die Variable FSCKFIX.

  • Moin, danke für die Antwort.

    Das macht mich etwas stutzig. /boot sollte eine FAT32-Partition sein auf der keinerlei Schreibzugriffe im Normalbetrieb stattfinden.
    Jedenfalls glaube ich nicht, das die partition durch einen powerfailure beschädigt sein soll. Wenn, dann wars was anderes....
    Automatisch zusammengefügt:

    Nein, kein Boot-Parameter.
    debian-basierte Betriebsysteme testen beim Booten auf die existenz einer Datei namens /forcefsck . Wenn diese Datei existiert, wenden die Dateisysteme in /etc/fstab vor dem einbinden geprüft. Bei ext-basierten Dateisystemen gibt es dafür ein flag, das man mit tune2fs setzen kann, um ein fsck zu erzwingen.

    Es gibt in /etc/default/rcS die Variable FSCKFIX. Ist bei mir (wahrscheinlich als Default) auf "yes" gesetzt. Ausgewertet wird das in /etc/init/mountall.conf indem mountall (wahrscheinliich /sbin/mountall) mit dem Parameter "--fsck-fix" aufgerufen wird. Laut Manpage also "Attempt to fix all fsck errors". Warum das nicht fruchtete weiss ich nicht.

    Das hatte bei mir dann offensichtlich nicht funktioniert, während sich die in ein Linux-Notebook gesteckte Karte mit "fsck.ext4 -y ....." reparieren lies. Beim vfat war es noch ein Stück heftiger. Da funktionierte dann der Aufruf "fsck.vfat -w -r -l -a -v -t /dev/mmcblk0p1".

    Mal sehen, am WE ist Zeit die zwei fraglichen Rechner einige Male hart auszuschalten. Vielleicht ergeben sich neue Erkenstnisse.

    Rundum Dank an alle.

  • Ich nutze neben dem hier erwähnten Ansätzen noch Folgendes:
    Boot ist komplett schreib geschützt.
    Komplettes System ist auf nem USB Stick. Alternativ könntest du denn Stick zumindest zum Schreiben von Daten nutzen und SD komplett schreibschützen
    S. Usv für 30 Euro. Funktioniert super und mit großem Akku läuft der pi auch ohne Strom paar Stunden

    Einmal editiert, zuletzt von onkelandy (6. Februar 2016 um 07:42)

  • Eine Prüfung und Reparatur des Dateisystems nach so einem Ausschalten funktioniert leider in den seltensten Fällen. Die bessere Lösung ist tatsächlich, nur die Bootpartition auf der SD-Karte zu lassen. Der Datenträger für den Rest sollte dann ausgelagert werden, allerdings ist das auch kein 100% Schutz. Eine S.USV scheint die beste Lösung zu sein, da damit in jedem Fall regulär runtergefahren werden kann.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!