[GELÖST] Raspberrymatic stürzt regelmäßig ab

[jmaus]

Also ich kann mich meinen Vorrednern nur anschließen. Die einzige Möglichkeit die es bei einem reproduzierbarem Abstürzen bei einem BadBlockCheck gibt ist die SD Karte bzw den Storage auszuwechseln, denn in 99% der Fälle wird der Absturz durch einen defekten Datenträger hervorgerufen. RaspberryMatic hat hier keinerlei Möglichkeit den Kernel Panic in den der Linux Kernel bei solch einem Event rennt zu umgehen oder zu identifizieren und den Nutzer darüber in Kenntnis zu setzen.

Das ganze habe ich nun auch entsprechend für die Nachwelt im entsprechenden Issue Ticket von fischmir noch einmal auf Englisch zusammengefasst:

https://github.com/jens-maus/RaspberryMatic/issues/1906

Das einzige was ich mir theoretisch vorstellen könnte zu verbessern wäre, den Grund des Absturzes ggf zu identifizieren indem man vor dem BadBlocksCheck eine Statusdatei generiert und dann beim Neustart versucht zu erkennen, das diese Datei existier und der darauf folgende unclean shutdown ggf auf den BadBlocksCheck zurückzuführen ist.

[jp112sdl]

Ich habe den Thread auch noch mal zum Anlass genommen, etwas umfangreicher zu recherchieren, aber ich konnte Google keinerlei Ergebnisse entlocken, wo "badblocks" zum Kernel-Crash führt.

Zumal der Test nur lesend ausgeführt wird, sollte das erst recht nicht zu Problemen führen.
Ich kann im Sourcecode in der Read-Funktion auch nichts Exotisches erkennen:
https://git.kernel.org/pub/scm/fs/ext2/ ... cks.c#n367
Da wird einfach mit read ein Block gelesen, wie es andere Anwendungen auch machen.

Bleibt die Frage, ob das System auch crashen würde, wenn man bspw. mit "cat" eine Datei liest, die sich über einen defekten Block erstreckt.
Bzw. handelt es sich überhaupt um ein Problem in der "badblocks"-Anwendung oder in der darunterliegenden ext2 Implementierung?

RaspberryMatic hat hier keinerlei Möglichkeit den Kernel Panic in den der Linux Kernel bei solch einem Event rennt zu umgehen oder zu identifizieren und den Nutzer darüber in Kenntnis zu setzen.

Ließe sich evtl. ein Core Dump auf der R/W Partition ablegen? In der Hoffnung, dass das auf "guten" Blöcken passiert.
Ich kenne mich da mit der BusyBox Kernel-Config nicht aus.

Aber vielleicht könnte man im Dump (mit Call Stack?) sehen, worauf der Crash beruht.

[Xel66]

Ich habe den Thread auch noch mal zum Anlass genommen, etwas umfangreicher zu recherchieren, aber ich konnte Google keinerlei Ergebnisse entlocken, wo "badblocks" zum Kernel-Crash führt.

Hier im Forum sollten nach meiner Erinnerung aber ein paar Erfahrungsberichte aus der Zeit sein, als jmaus das Feature in Raspberrymatic eingeführt hat. Eines zumindest mit absolut identischer Fehlerbeschreibung. Daher habe ich ja gleich auf einen Kartendefekt getippt. Andere mit Beschreibungen zu Auslastungs- und Temperaturproblemen. Grundsätzlich sehe ich das auch so, dass solch ein Programm ein OS nicht ins Straucheln bringen sollte. Zumal es ja genau für diesen Zweck, Defekte zu detektieren, gebaut ist. Aber vielleicht fehlt der Impementation in dem "abgespeckten" Linux unter der RM genau eine Fehlerbehandlungsroutine um das abzufangen, weil eine Abhängigkeit nicht dokumentiert ist, die auf anderen "normalen" Linux-Umgebungen standardmäßig vorhanden ist und so nicht auffällt.

Gruß Xel66

[jmaus]

Ich habe den Thread auch noch mal zum Anlass genommen, etwas umfangreicher zu recherchieren…
[…]
Zumal der Test nur lesend ausgeführt wird, sollte das erst recht nicht zu Problemen führen.
Ich kann im Sourcecode in der Read-Funktion auch nichts Exotisches erkennen:
https://git.kernel.org/pub/scm/fs/ext2/ ... cks.c#n367
Da wird einfach mit read ein Block gelesen, wie es andere Anwendungen auch machen.

In der Tat sollte das mit anderen Anwendungen dann auch passieren, ja. Zumindest dann wenn sie auf exakt den gleichen bzw die gleichen defekten Blöcke der SD Karte treffen wie das der badblocks check systematisch ja tut.

Der Punkt warum es hier zu einem Kernel Crash kommt wird in der besonderheiz der SD/MMC Treiber bzw des zugrundeliegenden Controllers liegen. Meinem Wissen nach passiert es nämlich, das in Falle eines defekten Medium der Treiber wohl aus Sicherheitsgründen entscheidet das gesamte device an dem die SD Karte angebunden wird abzuschalten bzw einen reset des Controllers durchzuführen und das löst daraufhin eine "oops" Kernelpanik aus weil andere Schreib- bzw Zugriffsoperationen dann ja nicht weiterkommen. Und der Kernel von RaspberryMatic ist ja so eingestellt das bei einer Kernelpanik ein harter reset ausgelöst wird damit die zentrale daraufhin schnellstmöglichst wieder verfügbar ist und nicht einfach stehen bleibt. Auch kann es gut sein das der Hardware Watchdog - den es ja auch noch gibt - hier eingreift und die Zentrale hart neustartet weil die kernelpanik auch das /dev/watchdog device gleich noch mitreist.

Bleibt die Frage, ob das System auch crashen würde, wenn man bspw. mit "cat" eine Datei liest, die sich über einen defekten Block erstreckt.

Ja, ich denke selbst mit einem einfachen dd über das gesamte device sollte es zum selben Problem kommen sobald das dd auf die blöcke trifft bei dem dann der Treiber des SD Karten controllers dann entscheidet zuzumachen und der Linux kernel dann in einer kernelpanik endet.

Ließe sich evtl. ein Core Dump auf der R/W Partition ablegen? In der Hoffnung, dass das auf "guten" Blöcken passiert.
Ich kenne mich da mit der BusyBox Kernel-Config nicht aus.

Aber vielleicht könnte man im Dump (mit Call Stack?) sehen, worauf der Crash beruht.

Ich denke das wird vmtl in diesem Falle nicht mehr funktionieren, weil eben der gesamte Treiber der SD Karte quasi abgeschalten wird und folglich dann auch kein coredump dann auf das selbe medium mehr abgelegt werden kann. Aber es kann gerne jemand mal probieren.

Jedoch denke ich wäre es zumindest möglich mit der erwähnten Statusdatei den Grund für den Absturz besser zu identifizieren und dann bei der unclean shutdown Alarmmeldung diesen mit auszugeben. Das sollte dann zumindest ein besserer Hint darauf sein warum es zum Neustart gekommen ist bzw welche letzte Aktion vor dem Neustart stattgefunden hat.

[fischmir]

Seid ihr euch sicher, dass im Logs nix drin steht?

https://github.com/jens-maus/RaspberryM ... cks.sh#L33

Wohin müsste ich den Log schreiben, damit dieser den Reset überlebt?

[Motorpsycho]

Ich kann das Problem und die Lösung bestätigen. Hatte nachts immer wieder Abstürze. Seit ich vor ein paar Wochen auf Emmc umgestellt habe ist alles total stabil.

[fischmir]

Bin such auf emmc umgestiegen. Läuft gut.