Lösungssuche zum Read-only-Problem (r/o)
<!doctype html>
1) Ausgangslage / Symptom
- Raspberry Pi mit NVMe als Root-Dateisystem (ext4)
- Nach ca. 12 Stunden Uptime wechselt das Root-FS in read-only
- SSH fällt aus, geordneter Shutdown kaum möglich → häufig Stecker ziehen
- Nach Reboot: ext4 meldet „orphan cleanup“ bzw. Hinweise auf unsauberen Shutdown
Einordnung: Unscharfe Shutdowns waren Folge des r/o-Zustands, nicht dessen Ursache.
2) Erste Prüfung: ext4 / fstab / errors=remount-ro
/etc/fstabgeprüft: nichts Ungewöhnliches, keine manuell gesetztenerrors=remount-ro-Optionen- Hinweis: ext4 kann bei I/O-Problemen über den Standard-Mechanismus in r/o wechseln (Selbstschutz)
3) Kernel-/NVMe-Analyse: cmdline, HMB und Parameter-Widerspruch
/proc/cmdlinewurde als maßgeblich identifiziert (Boot-„Wahrheit“)- Dort stand zeitweise eindeutig:
nvme.max_host_mem_size_mb=0 - Kernel-Meldung passte dazu:
min host memory (8 MiB) above limit (0 MiB)→ Host Memory Buffer (HMB) effektiv deaktiviert
4) Fix am Boot-Parameter
- Parameter wurde auf
nvme.max_host_mem_size_mb=64gesetzt - Danach im Kernel:
nvme nvme0: allocated 8 MiB host memory buffer.
Einordnung: Dass nur 8 MiB zugewiesen werden, ist typischerweise ein Controller-Limit und kein Zeichen, dass die Einstellung „ignoriert“ wird.
5) Logging-Problem erkannt (warum „vor dem Reboot“ keine Logs möglich waren)
- Bei r/o fällt SSH weg → Logs können nicht komfortabel per Remote gezogen werden
/var/log/journalwar leer/run/log/journal/<machine-id>existiert → journald läuft volatile (RAM-only)- Konsequenz: Reboot/Steckerziehen löscht genau die Logs, die den r/o-Moment erklären würden
6) Nebenbaustelle mit Einfluss: Home Assistant / systemd Restart-Loop
- In den Logs tauchte ein massiver systemd-Restart-Loop auf
- Fehlerbild: „Another Home Assistant instance is already running“
- Es liefen zeitweise mehrere hass-Prozesse parallel (z. B. alte „überlebende“ Prozesse nach unsauberen Stops)
- Versuche, das über systemd-Unit-Änderungen zu fixen, führten teils zu:
- Ungültigen hass-Argumenten (
--pid-file,--daemonnicht unterstützt →INVALIDARGUMENT) - Fehlkonfiguration von
ExecStartPre(pkill: only one pattern can be provided) - „Fatal signal“ /
status=9/KILLbeim ExecStartPre (zu aggressive/gefährliche Kill-Logik)
7) Stabilisierung von Home Assistant
- Alle riskanten
ExecStartPre=-Experimente wurden entfernt - Unit wurde auf eine minimale, saubere Form zurückgeführt (ein
ExecStart) - „Altprozesse“ wurden einmal manuell bereinigt
- Danach: genau eine HA-Instanz, systemd stabil, kein Restart-Loop
8) Aktueller Stand / Befunde nach der Stabilisierung
- NVMe/PCIe-Logs beim Boot ohne Timeout/Reset/I/O-Fehler
- HMB aktiv (Zuweisung sichtbar)
- Home Assistant läuft stabil (ein Prozess)
- Recorder/SQLite-Warnung: „DB nicht sauber beendet“ ist als Folge unsauberer Stops plausibel
- Bluetooth-Capabilities-Warnung (NET_ADMIN/NET_RAW): funktional meist optional; Container-Text kommt auch auf Host vor
9) Schlussfolgerung
Die wahrscheinlichste technische Ursache des r/o-Problems war eine NVMe-Instabilität im Zusammenspiel mit deaktiviertem Host Memory Buffer.
Der Home-Assistant/systemd-Restart-Loop war nicht die Grundursache, konnte die Situation aber durch Last/Logspam verschärfen.
Nach Aktivierung von HMB und Stabilisierung von HA/systemd liegt eine deutlich bessere Ausgangslage für Langzeittests vor.
10) Nächster sinnvoller Schritt
- Beobachten, ob der r/o-Fall nach ~12–24h weiter auftritt
- Wenn ja: Ursachenanalyse nur zuverlässig mit Live-Logging (z. B. seriell/UART) oder einem Logging-Weg, der bei r/o nicht ausfällt
