Ich habe ein Problem mit meinem Raspberry 4B (1 GB RAM). In unregelmäßigen Abständen (manchmal schon einige Stunden nach dem Hochfahren) reagiert der Desktop nicht mehr. Die Maus bewegt sich noch aber ich kann nichts mehr öffnen oder schließen usw. Per SSH komme ich noch auf die Konsole drauf, dann mache ich einen Reboot und dann läuft er erstmal wieder bis zum nächsten "einfrieren". Manchmal sieht die Grafik auch merkwürdig aus, die Eingabefelder und auch die Schaltflächen oben an den Fenstern sind dann teilweise schwarz eingefärbt. Ich habe ein Bild von der Anmeldemaske angehängt wie das heute aussah. Manchmal ist es aber auch so, dass mitten drin einfach die geöffneten Bash-Fenster mit den Scripten verschwinden. In dem Fall kann ich über den Desktop wieder neue Fenster öffnen und die Scripte wieder starten. Gelegentlich schien auch das Dateisystem verschwunden zu sein. Ich konnte also nicht mehr im Dateisystem navigieren und ich meine dass dann auch das gelbe Ordner-Symbol vom PCManFMDateimanager oben in der Leiste verschwunden war.
Operating System: Debian GNU/Linux 13 (trixie)
Kernel: Linux 6.18.34+rpt-rpi-v8
Die CPU-Temperatur beträgt meistens um die 40 °C.
Ich habe irgendwann XScreenSaver nachinstalliert weil ich eine automatische Bildschirmsperre haben wollte, aber die Probleme bestanden schon davor. Das Betriebssystem läuft auf einer "SanDisk Ultra 64 GB microSD XC I 10" und ich lasse zwei Python-Scripte laufen, eines loggt RS485 Nachrichten von meiner Heizungssteuerung (USB to RS232/485/TTL Adapter von Waveshare) sowie Temperaturen von ein paar DS18B20 Sensoren und das andere steuert über HTTP-Requests eine Funksteckdose. Ich hatte schon die SD-Karte im Verdacht, aber die Probleme traten ja schon ganz am Anfang auf und da konnte die neue SD-Karte unmöglich schon zu viel beschrieben worden sein. Das Netzteil ist ein Original Raspberry Pi Netzteil mit 15 Watt (5,1 V, 3,0 A, USB Type-C).
Bevor ich jetzt anfange irgendwelche Ersatzteile zu bestellen (z.B. stärkeres Netzteil oder eine High Endurance microSD Card), welche Ursache haltet ihr für wahrscheinlich?
Wenn du noch per SSH auf die Konsole kommst, würde ich zuerst mal mittels htop oder btop nach Auffälligkeiten schauen: Prozesse mit hoher CPU oder Speicherauslastung, andauernde I/O Operationen, RAM voll und Swap ausgelastet...
übertaktest du den RPI? Bei Bildfehler würde ich jetzt eher eien Hardware defekt vermuten RAM / CPU oder die Lötstellen davon. Hast du einen A2 µSD-Karte, wenn das nur eine alte Class 10 Karte ist hängst du am I/O Flaschenhals fest.
mit sudo iotop -o kannst du dir mal anschauen welche Prozesse dir die Karte totschreiben. Meist fängt es damit an das der RPI hängen bleibt weil die Speicherkarte mehrere Sekunden lang aussetzt irgendwan setzt der interne Controller die Karte dann auf read-only.
Ich habe vor ein paar Wochen eine PI4B auf einen btrfs rootpartition aufgesetzt, da das 5V Meanwell Netzteil, etwas Probleme hatte, wenn die Netzspannung bei Abschalter einen größeren Last (18kW) etwas hochging, dabei hat es mir anscheinend bei diesem kleinen Ausfall auch ne Karte zerschossen. Konnte das Dateisystem wieder reparieren,habe das ganze dann aber auf btrfs aufgesetzt. Das scheint bei plötzlichen Ausfällen gutmütiger zu sein da die alten Daten erst gelöscht werden wenn der aktuelle Schreibvorgang erfolgreich war.
in der fstab kannst du die Optionen noatime und z.B. commit=120 eintragen, das verhindert das die Zeiten jedes Lesezugriffs geschrieben werden und Daten aus dem RAM werden erst nach 120 Sekunden auf die Platte geschieben, zuvor hat das immer alle paar Sekunden Zugriffe gegeben.
Die Systemlogs landen jetzt erstmal auf einen RAM Laufwerk und werden nur ein paar mal am Tage auf die SD Karte geschrieben, aber mit dem Risiko wenn was schief läuft sind die logs weg.
Dann kann man den Kernel Buffer und das swapping verhalten noch etwas einbremsen.
Bei Bildfehler würde ich jetzt eher eien Hardware defekt vermuten RAM /
CPU oder die Lötstellen davon
Könnet ein Hardware-Grafik-Fehler denn so wie auf dem Bild aussehen? Leider ist das mein erster Rapspberry, aber bei den wenigen fehlerhaften PC-Grafikkarten die ich hatte zeigten sich in solchen Fällen eher Pixelfehler oder bunte Muster oder auch flackern. In meinem Fall sind die Bereiche wo die Fehler auftreten ja ungewöhnlich sauber abgegenzt.
Meist fängt es damit an das der RPI hängen bleibt weil die Speicherkarte
mehrere Sekunden lang aussetzt irgendwan setzt der interne Controller
die Karte dann auf read-only.
Kann man dieses Verhalten (read only) irgendwie ändern? Meine Scripte werden hoffentlich nicht die Karte an ihre Grenze bringen, auch wenn die nur Class 10 hat. Die Scripte schreiben vielleicht hundert Zeichen alle paar Sekunden an das Ende einer Text-Datei. Ich hatte ja vorher etwas recherchiert und dachte eigentlich, dass ich mit meiner SanDisk Extreme nicht viel falsch mache, da die teilweise sogar empfohlen wurde und die Kritik eher in die Richtung ging, dass man die bei sehr hoher permanenter Belastung eventuell schon nach einem Jahr entsorgen muss. Eigentlich wollte ich mir langfristig ne SanDisk High Endurance zulegen, weil die angeblich langlebiger bei permanenten Schreibzugriffen sein sollen. Aber auf den Abbildungen sehe ich da weder A1 noch A2. Wenn der Raspberry bei Verzögerungen auf das Schreiben warten würde und alles andere so lange im RAM gepuffert wird, könnte ich damit leben. Kann man das voreilige Einstufen des Controllers als read only irgendwie ändern?
Btrfs klingt gut und ich werde auch versuchen Deine anderen Optimierungs-Vorschläge umzusetzen.
Ich verstehe nicht, warum bei der Ausgangslage (Pi 4 B usw.) heute noch SD-Karten eingesetzt werden. Das mache ich nur noch mit meinem Bastel-Pi. Selbst bei meinem pihole (Pi 2 B, 24/7) wird nur von SD gebootet, dann per USB von SSD gestartet. Kostet genauso viel und läuft seit Jahren problemlos. Und das ganze wegen easy Datensicherung mit LVM und snapshot, den selbst der Pi 2 B dann ganz in Ruhe Weg sichern kann.
Der Pi 4 B kann sogar schon direkt von SSD booten.
In der Tat hatte ich anfangs auch solche Probleme. Aber mit einem anderen USB-Adapter war dann Ruhe. Einfach Mal nach den magischen Adaptern suchen (lsusb, falls Du sowieso noch eine hast).
Der Pi 4 B kann sogar schon direkt von SSD booten.
Kann er nicht, da man eine SSD gar nicht direkt anschließen kann. Er kann von USB-Massenspeicher booten. Der aber kann genausogut eine Festplatte, ein simpler USB-Stick oder was auch immer sein.
Anders sieht es beim Compute Module 4 aus - das belegt nicht die eine PCIe-Lane mit einem USB3.x-Controller, sondern erlaubt es, direkt daran eine NVMe-SSD zu betreiben. Und dann kann diese Variante des Raspberry Pi 4 tatsächlich auch direkt von SSD booten.
Das alles setzt natürlich voraus, daß das Compute Module auf einer Trägerplatine steckt, die entweder einen m.2-Sockel für eine SSD oder aber einen PCIe-Slot aufweist, in den man dann mit einem m.2-PCIe-Adapter die SSD reinsteckt.
Ich kaufe inzwischen keine normalen Pis mehr, sondern nur noch Compute Modules und Waveshare Carrierboards wie dieses hier für den CM5:
https://www.waveshare.com/cm5-io-base-b.htm
Auf der Unterseite ist ein M.2 Key M Slot, wo entweder eine SSD oder irgendwas anderes reinkommt. Zudem gibts die Compute Modules auch mit EMMC statt SD. EMMCs sind quasi SD-Karten im IC-Format, die schneller sind, langlebigeres Flash und einen besseren Controllerchip enthalten.
Weiterhin denke ich, das die 1G RAM unterdimensioniert sind. Ich habe einen Arbeitskollegen mit Olimex-Boards (A20, 1GB RAM, EMMC), und der hat auch irgendwelche seltsamen Probleme, die ich bei 4G-Boards nie gesehen habe.
Du willst ja auch um jedem Preis vermeiden, dass Dein System swappen muss. Das geht ja auch Flash und kostet Schreib/Löschzylen.
Aber selbst da habe ich mich darum gekümmert die dauernden
Schreibvorgänge zu verringern.
Sofern das keine extreme Ramsch-SSD ist oder eine sehr kleine (< 32 GByte), ist es effektiv nicht drin, so etwas "totzuschreiben". Die Mühe kann man sich sparen, wie zig Desktoprechner tagtäglich beweisen, die jahrelang mit einer SSD arbeiten, auf der sich ein Windows ausmärt.
war ja kein großer extra Aufwand habe das bei einem Pi wegen der sd-Karte gemacht und der SSD schadet es sicher auch nicht Schreibvorgänge zu verringen, sind übrigends WD RED 500GB da bewirbt der Hersteller mit 1000 Terrabyte write statt 300 TB bei den (Consumer) Blue Modellen. Vermutlich fängt der interierte DRAM auch kleine Daten ab damit die nicht ständig geschrieben werden müssen bis ein ganzer Block zusammen kommt
SSDs, die unter dem Label "WD" verkauft wurden, sind von SanDisk. Und wie es bei SanDisk um die Qualität bestellt ist, haben einige zu ihrem Leidwesen herausfinden können.
Achte höllisch darauf, nach Firmwareupdates für die SSD zu suchen, und die auch einzuspielen, sonst kannst Du sehr große Freude haben.
SanDisk ist WD.
Das ist so wie Parkside. Das ist auch Lidl. Aber Lidl hört sich auf nem Gartenhäcksler doof an.
WD hat sich nur überlegt, das man mechanische und elektronische Datenträger namentlich trennen sollte und verkauft daher drehende Scheiben unter dem Namen WD, SSDs dafür als SanDisk. Weil "dem Namen vertraut man bei Speicherkarten mehr als uns".
Und WD hat irgendwo stehen, das sie überhaupt niemals gar keine Updates raushauen, für keins der Laufwerke.
Da kann man sich jetzt seinen Teil zu denken...
Oder hat sich das in diesem Jahr schon wieder geändert???
SSDs, die unter dem Label "WD" verkauft wurden, sind von SanDisk. Und
wie es bei SanDisk um die Qualität bestellt ist, haben einige zu ihrem
Leidwesen herausfinden können.
Sandisk hatte früher ein Joint-Venture mit Toshiba, der Speicher kam also von einer Toshiba FAB und Sandisk beteiligte sich an den Kosten.
WD hat Sandisk übernommen inkl. der Fab-Anteile (jetzt Kioxia).
Ich bin da genauso beruhigt wie mit Speicher von Samsung, Hynix und Micron.
Und entschuldigung für das Terrabyte, das r prrellt auf meiner Tastatur so starrk ;-)
Könnte es sein, daß die Scripte Tochterprozesse starten oder selbst eine Schleife ausführen? So etwas kann dazu führen, daß sich Prozesse mit der Zeit tot rennen. So was hatte ich mal mit ein per Cron gestarteten Bashscript, das diverse Grafiken für eine Webseite aus einer RRD erstellen sollte. Ich hatte die Zeitabstände etwas zu knapp bemessen, so daß immer mehr Instanzen des Scriptes gestartet wurden, womit der Pi insgesamt immer langsamer wurde. Am Ende ist ihm die Luft ausgegangen und er ist einfach eingefroren.
Der Hinweis von Manuel die Prozesse zu überprüfen ist da schon mal ein guter Weg. Manchmal reicht da auch ein einfaches "sudo ps -A". Da einfach mal prüfen ob Prozesse mehrfach laufen, obwohl eigentlich nur eine Instanz laufen sollte.
Rein Interesse halber mal noch die Frage, warum läßt Du das Ding mit einer GUI laufen? Deine Anwendung ist ist doch prädistiniert dafür auf eine GUI zu verzichten.
Kann man dieses Verhalten (read only) irgendwie ändern? Meine Scripte
werden hoffentlich nicht die Karte an ihre Grenze bringen, auch wenn die
nur Class 10 hat.
Meine Pi's haben alle nur Class 10 Karten und laufen seit vielen Jahren fast störungsfrei. Allerdings schreibt keiner der Pi's auf die SD. Schreiboperationen erfolgen ausschließlich auf ein NAS-Laufwerk im Netz. Dem Pi (BananaPi) der als Empfänger für Wettersatelliten dient habe ich eine SSD spendiert, der braucht die SD nur zum Booten.
Das Problem sitzt in solchen Fällen meist vor dem Pi, diese Erfahrung mußte ich selbst schon machen. Fehler in Scripten sorgen oftmals dafür das sich das Ding am Ende tot rennt. Schreiben auf SD's ist bei Pi oftmals der Flaschenhals, insbesondere dann wenn so ein Schreibvorgang mal deutlich länger dauert und sich Schreibvorgänge bei per Cron gestarteten Scripten überlappen.
Selbst bei meinem pihole (Pi 2 B, 24/7) wird nur von SD gebootet, dann
per USB von SSD gestartet. Kostet genauso viel und läuft seit Jahren
problemlos.
Die 64 GB microSD-Karte hat mich weniger als 20 Euro gekostet. Bekommt man für das Geld wirklich eine vernünftige USB-SSD?
Weiterhin denke ich, das die 1G RAM unterdimensioniert sind.
Ich glaube nicht dass mein Hauptproblem (einfrieren) darauf zurückzuführen ist, aber generell hast Du sicher recht. Ich habe inzwischen Einträge im Log gefunden, die eventuell auf ein Problem mit der Hardwarebeschleunigung in der GPU unter Trixie hindeuten:
Rein Interesse halber mal noch die Frage, warum läßt Du das Ding mit
einer GUI laufen? Deine Anwendung ist ist doch prädistiniert dafür auf
eine GUI zu verzichten.
Hast ja recht, ich habe das aus Bequemlichkeit gemacht, weil ich es per VNC komfortabler finde diverse Terminal-Fenster zu verwalten, Scripte zu starten, parallel in der Entwicklungsumgebung zu arbeiten, etc. Das kann man zwar auch alles lokal Einrichten (SSH, Zertifikate, Tmux, etc.), aber ich wollte erstmal ohne großen Aufwand mit dem Raspberry starten. Ich habe das OS inzwischen aber auf Headless umgestellt.
Das eine Script loggt die RS485-Daten die von der Heizungssteuerung ca. alle 9 Sekunden kommen. Die Werte der Temperatursensoren speichere ich alle 15 Sekunden. Das werde ich später sicherlich noch optimieren, damit weniger Schreibzugriffe entstehen, aber ich ging davon aus, dass ich zumindest im Testbetrieb die paar hundert Bytes pro Log-Eintrag so speichern kann, ohne dass mir das OS ständig abschmiert. Langfristig würde ich dann ein zuverlässigeres Speichermedium verwenden.
Die Scripte schreiben vielleicht hundert Zeichen alle paar Sekunden an
das Ende einer Text-Datei.
wenn die auf dem Swap liegt, schreibst du die Karte tot und dann ist sie nur noch lesbar.
Wenn dann sollte man den Swap abschalten auf ein NAS schreiben oder RAM für eine Ramdisk für diese Swap einrichten, RAM kann zumindest nicht totgeschrieben werden.
Das SD Karten aller Arten durch Linux Swap getötet werden kenne ich seit RASPBMC auf PI1, später OSMC ab PI2 bis PI3 immer wieder, ab PI4 habe ich aufgegeben immer wieder neue Formen so daß meine gefrästen Vollalu nicht mehr passen, neue Buchsen (miniHDMI), neue Netzteile.... und dann jede Menge Anleitungen die veraltet sind weil fast nie, Linuxversion, Kernelversion und Abhängigkeiten genannt werden, jedesmal Probeinstallation, Test, Sicherung und bei Fehlfunktion, wieder alles zurück nervt auch.
RaspberryGrafik.png
(7,3 KB)
