Zuerst einen vollständigen Host-Lockup von einem Netzwerkausfall unterscheiden
Der gemeldete Rechner verlor den Netzwerkzugriff, die Ping-Erreichbarkeit, die Container, die Reaktion der lokalen Konsole und die Videoausgabe. Dieser Umfang geht über einen SMB-, Docker- oder NIC-Ausfall hinaus und entspricht einem vollständigen Host-Lockup, der einen Aus- und Wiedereinschaltvorgang erfordert.
Wenn ein Server aus der Ferne nicht mehr erreichbar ist, prüfen Sie die lokale Konsole und Anzeige, bevor Sie eine Ersatz-Netzwerkkarte kaufen. Eine reagierende Konsole lenkt die Untersuchung in Richtung Netzwerk; eine eingefrorene Konsole und eine ausgefallene Anzeige weisen eher auf Kernel, Firmware, Stromversorgung, Speicher oder Hardware hin.
Notieren Sie den genauen Zeitpunkt des Ereignisses und ob der Rechner selbst neu gestartet wurde oder eingeschaltet, aber nicht reagierend blieb. Diese Beobachtungen bestimmen, welches Zeitfenster des vorherigen Bootvorgangs und welche Daten externer Überwachung verglichen werden können.
Beweise zum vorherigen Bootvorgang sammeln, bevor Variablen geändert werden
Die erste nützliche Sammlung im Thema war journalctl -b -1, einschließlich Kernel- und Meldungen mit hoher Priorität aus dem Bootvorgang, der mit dem Einfrieren endete. Das ZimaOS-Team forderte später die letzten 500 Einträge des vorherigen Bootvorgangs sowie das dauerhafte Journal zur privaten Prüfung an.
Prüfen Sie Protokolle vor der öffentlichen Veröffentlichung auf persönliche Informationen. In diesem Fall war die dauerhafte Protokollierung aktiviert, aber das Protokoll endete zum beobachteten Zeitpunkt des Ausfalls abrupt, ohne Kernel-Panic, OOM-Kill, GPU-Reset, Speicherfehler, thermisches Ereignis, Watchdog-Blockierung oder ordnungsgemäßes Herunterfahren.
Ein leerer letzter Eintrag beweist nicht, dass nichts ausgefallen ist. Er zeigt, dass der Host angehalten wurde, bevor der verfügbare lokale Protokollierungsweg eine Ursache aufzeichnen konnte. Den gleichen Protokollbefehl nach jedem identischen, lautlosen Absturz zu wiederholen, bringt wenig, solange sich die Erfassungsmethode nicht ändert.
Die Tests mit GPU und Frigate führten zu keiner Lösung
Das System verwendete die Intel-i915-Grafik und Frigate VAAPI, daher deaktivierte der Autor zunächst die GPU-Beschleunigung. Der Host fror weiterhin ein. Das vollständige Beenden von Frigate führte zeitweise zu einem längeren Intervall, spätere Tests konnten Frigate jedoch nicht als Ursache bestätigen.
Der Autor versuchte außerdem, i915 zu deaktivieren, wodurch andere Workloads unbrauchbar wurden und das System schließlich erneut abstürzte. Dieses Ergebnis schließt „i915 deaktivieren“ als erfolgreiche Reparatur für diesen Fall aus.
Der Vergleich mit OpenMediaVault war aussagekräftig: Dieselbe Hardware und Frigate-Konfiguration lief dort stabil. Das weckt den Verdacht auf eine ZimaOS-spezifische Wechselwirkung mit Kernel oder Treibern, identifiziert jedoch für sich genommen nicht, welche Komponente ausgefallen ist.
IOMMU-, VFIO- und SATA-LPM-Vorschläge wurden als Lösungen ausgeschlossen
ZimaOS enthielt zunächst intel_iommu=on und vfio_iommu_type1.allow_unsafe_interrupts=1. Ein Teammitglied bat den Autor, beide zu entfernen. Die aktive Befehlszeile bestätigte, dass sie nicht vorhanden waren, dennoch sperrte sich der Rechner erneut.
Der Autor testete anschließend libata.force=nolpm weil die Datenträger über einen M.2-zu-SATA-Adapter angeschlossen waren. Am nächsten Morgen trat ein weiterer Freeze auf. Der Thread stützt daher keine der beiden Änderungen an den Boot-Parametern als Lösung.
Diese Tests zeigen außerdem, warum Updates ein Experiment ungültig machen können: Ein Update hatte die angepasste Befehlszeilendatei überschrieben. Überprüfe immer die aktive Boot-Befehlszeile, bevor du die Laufzeit interpretierst, und ändere innerhalb des etablierten Absturzfensters jeweils nur eine Variable.
Persistentes Journal, pstore und Remote-Weiterleitung stießen an ihre Grenzen
Der Kernel enthielt pstore sowie die Erkennung von Hard- und Soft-Lockups, und der NMI-Watchdog war aktiv. Allerdings /sys/fs/pstore blieb nach den Abstürzen leer, während kein Crash-Kernel für kdump reserviert war.
Die beim Booten gestartete Netconsole analysierte ihre Konfiguration, startete jedoch, bevor eth0 war vorhanden und deaktivierte sich selbst. Ein Userspace- journalctl-to-UDP-Weiterleitung erreichte einen zweiten Linux-Rechner, stoppte jedoch ebenfalls ohne abschließende Ursache, als der Host einfror.
Dieses Ergebnis ist hilfreich: Die Weiterleitung im Userspace kann keine Nachrichten senden, nachdem der Scheduler oder der Netzwerk-Stack angehalten wurde, und sie kann keine Kernel-Warnung erzeugen, die nie ausgegeben wurde. Zu diesem Zeitpunkt ist ein Debug-Kernel des Herstellers oder eine gezielte Instrumentierung wertvoller als eine weitere identische Aufzeichnung im Userspace.
ZimaOS 1.7.1 entfernte vermutete Komponenten, war aber noch nicht validiert
Ein zweiter Benutzer von ZimaBoard 2 berichtete kurz vor einem Systemstillstand von wiederholten Abstürzen von Python und anderen Prozessen. Das ZimaOS-Team teilte mit, dass es die Crudini-Abhängigkeit aus zimaos-welcome, die Häufigkeit der Ressourcenanforderungen dieses Dienstes reduziert und die Änderungen für ein Test-Release eingeplant.
Das Team stellte später klar, dass das Crudini-Problem lediglich ein Auslöser war und die eigentliche Ursache des Systemabsturzes weiterhin untersucht wurde. In ZimaOS 1.7.1 wurde außerdem die Version der Docker Engine zurückgesetzt, um den Containerstart zu verbessern und die Wahrscheinlichkeit einer Blockierung von DBus-Broker-Nachrichten zu verringern.
Der letzte Beitrag fragt, ob ein anderer Benutzer mit 1.7.1 stabil ist; das erforderliche Ergebnis zur Betriebszeit wird jedoch nicht angegeben. Beschreiben Sie 1.7.1 nicht als bestätigte Lösung für die Abstürze, solange die ursprüngliche Fehlerbedingung nicht über das bisherige Zeitfenster hinaus stabil bleibt.
Mit den bereits ausgeschlossenen Tests eskalieren
Ein aussagekräftiges Support-Paket enthält das Hardwaremodell, die ZimaOS- und Kernel-Versionen, den Speichercontroller, die Workloads, die Absturzzeiten, die aktiven Boot-Parameter, Protokolle vorheriger Starts sowie eine Liste kontrollierter Tests mit ihren Ergebnissen.
Es sollte ausdrücklich festgehalten werden, dass GPU-Beschleunigung, die Isolation von Frigate, das Entfernen der IOMMU-/VFIO-Parameter, die Deaktivierung von i915, Änderungen an SATA LPM, persistente Protokolle, pstore und die Protokollierung im entfernten Userspace in diesem Ausgangsfall keine bestätigte Reparatur bewirkt haben.
Wenn ein anderes Betriebssystem unter derselben Auslastung stabil bleibt, während ZimaOS weiterhin einfriert, sollte dieser Vergleich beibehalten und ein gezielter Build oder eine Untersuchung durch den Anbieter angefordert werden. Wenn Zuverlässigkeit betrieblich kritisch ist, ist die Rückkehr zur stabilen Umgebung eine sinnvolle Abbruchgrenze, statt endlos ungeprüfte Parameter hinzuzufügen.
FAQ
Verursachten Frigate oder Intel VAAPI die Abstürze von ZimaOS?
Der Thread konnte das nicht belegen. Die Abstürze traten weiterhin auf, nachdem die GPU-Beschleunigung deaktiviert worden war, sowie nach weiteren Isolationstests mit i915.
Haben das Entfernen der IOMMU- und VFIO-Parameter die Abstürze behoben?
Nein. Die aktive Befehlszeile bestätigte, dass beide entfernt wurden, und der Host fror erneut ein.
Behebt ZimaOS 1.7.1 vollständige Systemabstürze?
Das Release hat Crudini geändert, zimaos-welcome, das Verhalten der Docker Engine und von DBus, aber das Thema endet, bevor ein Stabilitätsergebnis die Wiederherstellung bestätigt.
