FHEM kann nicht mehr auf SSD Schreiben

[GeZi3560]

Hallo Gemeinde,
ich schreib das mal zu Anfängerfragen, weil ich mir wie ein Anfänger vorkomme obwohl ich mein FHEM schon Jahrelang problemlos betreibe.

Umgebung:  Raspberry 4 4GB, Icebox USB -SATA Adapter, Sandisc SSD,  4 X CUL, 1 x Z.Wave Stick.
Boot von SSD, mit neustem Raspberry OS

Ich hatte ja in der Vergangenheit immer mal wieder das FHEM nicht auf die Platte schreiben konnte da das Filesystem schreibgeschützt war.
Festgestellt hab ich es, das die SVGs nichts angezeigt hatten, da die LOGs nicht geschrieben wurden.
Die Automatisierung lief brav weiter.
Das ärgerliche wenn das passiert ist das die Somfy Rolling codes verloren gehen.
Eine Ursache konnte ich nicht finden, vermutlich ein Defekt der SSD.
Nach dem letzten Vorfall hab ich nun FHEM auf neuer SSD aufgesetzt und Backup eingespielt.
Nun hatte ich heute ein ähnliches Problem, ich habe es erst bemerkt das FHEM das "fhem.save" nicht schreiben konnte.
Die SVGs waren aber vollständig!?
Nach reboot sind nun die SVGs und deren Logs von letzten drei Tagen leer und setzen erst wieder mit  dem Neustart an.
Die logs wurden also nicht geschrieben, aber die SVGs mit Daten versorgt?
Das versteh nicht. (Schreibcache?)

Eine Idee wie ich herausfinden kann was bewirkt das die Platte schreibgeschütz ist?
Da die SDD neu ist hab ich jetzt mal den USB -SATA Adapter getauscht.

Gruss Gerd

[Otto123]

Hallo Gerd,

klingt eventuell einfach nach einem Berechtigungsproblem?
Idee:
Mit

Code Auswählen Erweitern

ls -lhaR /opt/fhem | grep root Mal schauen und mit

Code Auswählen Erweitern

chown -R fhem: /opt/fhem/ beheben.

Gruß Otto

[GeZi3560]

Danke für dein Feedback.
Kann ich wohl ausschließen, da sich das wohl während der Laufzeit nicht verändert. 

Code Auswählen Erweitern


pi@FHEM2022:~ $ ls -lhaR /opt/fhem | grep root
drwxr-xr-x  5 root root    4,0K 28. Aug 15:45 ..
-rw-r--r-- 1 fhem dialout 1,4K 28. Aug 15:49 SM_FS_root.gplot
-rw-r--r--  1 fhem dialout 1,4K  9. Apr 09:34 SM_FS_root.gplot
pi@FHEM2022:~ $


[Wernieman]

Ich würde auf ein USB-Problem tippen. Hast Du neben dem USB-Adapter noch anderes am BUS? Abgesehen von der Internen Verwendung z.B. Ethernet?

Interessant währe eigentlich die Syslog/kern.log zu der Zeit. Nur da nicht geschrieben wurde und reboot, sind die Infos "weg" .....

[GeZi3560]

Am USB 3 Bus hängt nur die SSD
An den USB 2 die CULs und der Zwave.

[Wernieman]

Da USB3 und 2 vom gleichen Controller Betrieben, hast Du am BUSS also 4 Geräte.

Wie sieht es mit der Stromversorgung aus? Eventuell Underpower-Probleme

Code Auswählen Erweitern

vcgencmd get_throttled
Wenn dort z.B. "throttled=0x50005" kommt, hast Du ein Problem. Erklärung des Codes:

Code Auswählen Erweitern

Bit Hex Value Meaning
0 1 Under-voltage detected
1 2 ARM frequency has been caped
2 4 Currently throttled
3 8 Soft temperature limit is active
16 1000 Under-voltage has occurred
17 2000 ARM frequency capping has occurred
18 4000 Throttling has occurred
19 8000 Soft temperature limit has occurred
In Meinem Beispiel:
5 = Bit 0 und 2 Gesetzt (1+4=5), also aktuell underpower und deshalb CPU-Drosselung
5 = Bit 16 und 18 Gesetzt, obiges schon mal aufgetreten (natürlich bei Aktuellen auch gleich gesetzt)

Alternativ:

Code Auswählen Erweitern

dmesg | grep -iC3 "under-voltage"
Dieses gibt aus dem Log noch 3 Zeilen Vor/Nach dem Ereignis aus, um die Umstände und Folgen besser abschätzen zu können.

Hinweis: Da dmesg den Kernel-Ringpuffer ausliest und dieser nur X Einträge speichern kann bevor überschrieben wird, dafür aber aus dem RAM, ist er für Historische Betrachtungen wenig geeignet. Bei aktuellen Probleme dagegen sehr Informativ. Ein Reboot löscht natürlich den Buffer

[GeZi3560]

Danke für den Input, werde dem beim nächsten Ausfall mal nachgehen.
Im Moment alles OK.

Code Auswählen Erweitern


pi@FHEM2022:~ $ vcgencmd get_throttled
throttled=0x0
pi@FHEM2022:~ $ dmesg | grep -iC3 "under-voltage"
pi@FHEM2022:~ $