Maak eerst onderscheid tussen een volledig vastgelopen host en een netwerkstoring
De gemelde machine verloor netwerktoegang, ping, containers, lokale console-respons en video-uitvoer. Dat bereik is breder dan een SMB-, Docker- of netwerkkaartstoring en komt overeen met een volledige hostblokkering waarvoor een powercycle nodig is.
Als een server op afstand verdwijnt, controleer dan de lokale console en het scherm voordat je een vervangende netwerkkaart aanschaft. Een reagerende console leidt het onderzoek richting het netwerk; een vastgelopen console en weggevallen scherm wijzen eerder op de kernel, firmware, voeding, opslag of hardware.
Noteer het exacte tijdstip van de gebeurtenis en of de machine vanzelf opnieuw opstartte of ingeschakeld maar niet-reagerend bleef. Deze waarnemingen bepalen welk venster van de vorige opstartprocedure en welke externe monitoringgegevens kunnen worden vergeleken.
Verzamel gegevens over de vorige opstartprocedure voordat je variabelen wijzigt
De eerste nuttige verzameling in het onderwerp was journalctl -b -1, inclusief kernel- en berichten met hoge prioriteit uit de opstartprocedure die eindigde met de vastloper. Het ZimaOS-team vroeg later om de laatste 500 vermeldingen van de vorige opstartprocedure en het permanente journal voor privébeoordeling.
Controleer logs op persoonlijke informatie voordat je ze openbaar maakt. In dit geval was permanente journaling ingeschakeld, maar het log stopte abrupt op het waargenomen tijdstip van de storing, zonder kernel panic, OOM-kill, GPU-reset, opslagfout, thermische gebeurtenis, watchdog-blokkering of normale afsluiting.
Een leeg laatste logrecord bewijst niet dat er niets is misgegaan. Het laat zien dat de host stopte voordat de beschikbare lokale loggingmethode een oorzaak kon vastleggen. Hetzelfde logcommando na elke identieke stille vastloper herhalen levert weinig op, tenzij de vastleggingsmethode wordt gewijzigd.
De GPU- en Frigate-tests leverden geen oplossing op
Het systeem gebruikte Intel i915-graphics en Frigate VAAPI, dus de auteur schakelde eerst GPU-versnelling uit. De host liep nog steeds vast. Frigate volledig stoppen zorgde op een bepaald moment voor een langere tussenperiode, maar latere tests wezen niet uit dat Frigate de oorzaak was.
De auteur probeerde ook i915 uit te schakelen, waardoor andere workloads onbruikbaar werden en het systeem uiteindelijk opnieuw crashte. Dat resultaat sluit “i915 uitschakelen” uit als succesvolle oplossing voor dit geval.
De vergelijking met OpenMediaVault was betekenisvol: dezelfde hardware en Frigate-configuratie waren daar stabiel. Dit wekt het vermoeden van een ZimaOS-specifieke interactie met de kernel of driver, maar identificeert op zichzelf niet welk onderdeel faalde.
IOMMU-, VFIO- en SATA-LPM-suggesties werden als oplossingen uitgesloten
ZimaOS bevatte aanvankelijk intel_iommu=on en vfio_iommu_type1.allow_unsafe_interrupts=1. Een teamlid vroeg de auteur beide te verwijderen. De actieve commandoregel bevestigde dat ze ontbraken, maar de machine liep opnieuw vast.
De auteur testte vervolgens libata.force=nolpm omdat de gegevensschijven een M.2-naar-SATA-adapter gebruikten. De volgende ochtend volgde opnieuw een vastloper. De thread ondersteunt daarom geen van beide wijzigingen van bootparameters als oplossing.
Deze tests laten ook zien waarom updates een experiment ongeldig kunnen maken: een update had het aangepaste commandoregelbestand overschreven. Controleer altijd de actieve bootcommandoregel voordat je uptime interpreteert en wijzig één variabele binnen het vastgestelde crashvenster.
Persistente journal, pstore en externe forwarding bereikten hun grenzen
De kernel bevatte pstore en detectie van harde en zachte lockups, en de NMI-watchdog was actief. De /sys/fs/pstore bleef na crashes leeg, terwijl er geen crashkernel was gereserveerd voor kdump.
De boot-time netconsole parseerde de configuratie, maar startte voordat eth0 bestond en schakelde zichzelf uit. Een userspace journalctl-naar-UDP-forwarder bereikte een tweede Linux-machine, maar stopte eveneens zonder definitieve oorzaak toen de host vastliep.
Die uitkomst is nuttig: forwarding vanuit de userspace kan geen berichten verzenden nadat de scheduler of netwerkstack stopt, en kan geen kernelwaarschuwing fabriceren die nooit is uitgegeven. Op dit moment is een debugkernel van de leverancier of gerichte instrumentatie waardevoller dan nog een identieke userspace-capture.
ZimaOS 1.7.1 Verdachte componenten gewijzigd, maar nog niet gevalideerd
Een tweede gebruiker op ZimaBoard 2 meldde herhaalde crashes van Python en andere processen vlak voor een vastloper. Het ZimaOS-team zei dat het de Crudini-afhankelijkheid had verwijderd uit zimaos-welcome, verlaagde de frequentie waarmee die service resourceverzoeken deed en plande de wijzigingen voor een testrelease.
Het team verduidelijkte later dat het Crudini-probleem slechts een trigger was en dat de daadwerkelijke oorzaak van de systeemcrash nog werd onderzocht. In ZimaOS 1.7.1 werd ook de versie van Docker Engine teruggedraaid om het starten van containers te verbeteren en de kans op blokkering van DBus-brokerberichten te verkleinen.
Het laatste bericht vraagt of een andere gebruiker stabiel is op 1.7.1; het geeft niet het vereiste uptime-resultaat. Beschrijf 1.7.1 niet als een bevestigde oplossing voor vastlopers totdat de oorspronkelijke foutconditie stabiel blijft tot voorbij het eerdere tijdsvenster.
Escaleren met de tests die al zijn uitgesloten
Een sterk supportpakket bevat het hardwaremodel, de versies van ZimaOS en de kernel, de opslagcontroller, de workloads, de tijdstippen van crashes, de actieve opstartparameters, logs van eerdere boots en een lijst met gecontroleerde tests en resultaten.
Vermeld expliciet dat GPU-versnelling, Frigate-isolatie, het verwijderen van IOMMU/VFIO-parameters, het uitschakelen van i915, wijzigingen aan SATA LPM, persistente logs, pstore en logging vanuit userspace op afstand in deze broncasus geen bevestigde oplossing hebben opgeleverd.
Als een ander besturingssysteem onder dezelfde belasting stabiel blijft terwijl ZimaOS blijft vastlopen, bewaar die vergelijking dan en vraag om een gerichte build of onderzoek door de leverancier. Wanneer betrouwbaarheid operationeel kritiek is, is terugkeren naar de stabiele omgeving een geldige stopgrens, in plaats van eindeloos niet-geverifieerde parameters toe te voegen.
Veelgestelde vragen
Veroorzaakten Frigate of Intel VAAPI de crashes van ZimaOS?
Dat werd in de thread niet bewezen. De crashes gingen door nadat GPU-versnelling was uitgeschakeld en na verdere i915-isolatietests.
Losten het verwijderen van IOMMU- en VFIO-parameters de vastlopers op?
Nee. De actieve opdrachtregel bevestigde dat beide waren verwijderd, waarna de host opnieuw vastliep.
Lost ZimaOS 1.7.1 volledige systeemvastlopers op?
De release wijzigde Crudini, zimaos-welcome, Docker Engine en DBus-gerelateerd gedrag, maar het onderwerp eindigt voordat een stabiliteitsresultaat bevestigt dat het probleem is opgelost.
