Skilj först mellan en fullständig låsning av värden och ett nätverksfel
Den rapporterade maskinen förlorade nätverksåtkomst, ping, containrar, svar från den lokala konsolen och videoutgång. Det omfånget är större än ett SMB-, Docker- eller nätverkskortsavbrott och stämmer överens med en fullständig låsning av värden som kräver en strömcykel.
Om en server försvinner från fjärråtkomst, kontrollera den lokala konsolen och bildskärmen innan du köper ett nytt nätverkskort. En fungerande konsol riktar undersökningen mot nätverket; en frusen konsol och förlorad bildskärm riktar den mot kärnan, fast programvara, strömförsörjning, lagring eller maskinvara.
Notera den exakta tidpunkten för händelsen och om maskinen startade om av sig själv eller förblev påslagen men inte svarade. Dessa observationer avgör vilket tidsfönster från den föregående uppstarten och vilka externa övervakningsdata som kan jämföras.
Samla in bevis från föregående uppstart innan du ändrar variabler
Den första användbara insamlingen i tråden var journalctl -b -1, inklusive kärnmeddelanden och meddelanden med hög prioritet från den uppstart som slutade med frysningen. ZimaOS-teamet bad senare om de senaste 500 posterna från den föregående uppstarten samt den beständiga journalen för privat granskning.
Granska loggar efter personlig information innan du publicerar dem. I det här fallet var beständig journalföring aktiverad, men loggen upphörde abrupt vid den observerade tidpunkten för felet utan panik, OOM-avlivning, GPU-återställning, lagringsfel, termisk händelse, watchdog-låsning eller normal avstängning.
En tom slutlig post bevisar inte att inget misslyckades. Den visar att värden stoppade innan den tillgängliga lokala loggningsvägen hann registrera en orsak. Att upprepa samma loggkommando efter varje identiskt tyst låsningstillstånd tillför inte mycket om inte insamlingsmetoden ändras.
GPU- och Frigate-testerna identifierade ingen lösning
Systemet använde Intel i915-grafik och Frigate VAAPI, så författaren inaktiverade först GPU-acceleration. Värden frös fortfarande. Att stoppa Frigate helt gav vid ett tillfälle ett längre intervall, men senare tester fastställde inte att Frigate var orsaken.
Författaren försökte också inaktivera i915, vilket gjorde andra arbetsbelastningar oanvändbara, och systemet kraschade så småningom igen. Det resultatet utesluter ”inaktivera i915” som en fungerande åtgärd i det här fallet.
Jämförelsen med OpenMediaVault var betydelsefull: samma maskinvara och Frigate-konfiguration hade varit stabila där. Det väcker misstankar om en kärn- eller drivrutinsinteraktion som är specifik för ZimaOS, men identifierar inte i sig vilken komponent som slutade fungera.
Förslag om IOMMU, VFIO och SATA LPM avfärdades som lösningar
ZimaOS inkluderade ursprungligen intel_iommu=on och vfio_iommu_type1.allow_unsafe_interrupts=1. En teammedlem bad författaren att ta bort båda. Den aktiva kommandoraden bekräftade att de saknades, men maskinen låste sig igen.
Författaren testade sedan libata.force=nolpm eftersom datadiskarna använde en M.2-till-SATA-adapter. En annan frysning inträffade följande morgon. Tråden stöder därför inte att någon av de två ändringarna av startparametrar är en lösning.
Dessa tester visar också varför uppdateringar kan ogiltigförklara ett experiment: en uppdatering hade skrivit över den anpassade kommandoradsfilen. Verifiera alltid den aktiva startkommandoraden innan drifttid tolkas, och ändra en variabel i taget genom det etablerade kraschförloppet.
Beständiga journaler, pstore och fjärrvidarebefordran nådde sina gränser
Kärnan inkluderade pstore samt detektering av hårda och mjuka låsningar, och NMI-watchdogen var aktiv. Men /sys/fs/pstore förblev tom efter krascherna, medan ingen kraschkärna hade reserverats för kdump.
Netconsole vid uppstart tolkade sin konfiguration men startade innan eth0 fanns och inaktiverade sig själv. En vidarebefordrare i användarutrymmet journalctl-till-UDP-vidarebefordraren nådde en andra Linux-maskin, men den stannade också utan en slutlig orsak när värddatorn frös.
Det resultatet är användbart: vidarebefordran i användarutrymmet kan inte skicka meddelanden efter att schemaläggaren eller nätverksstacken har slutat fungera, och den kan inte skapa en kärnvarning som aldrig genererades. I detta läge är en leverantörsanpassad felsökningskärna eller riktad instrumentering mer värdefull än ännu en identisk insamling i användarutrymmet.
ZimaOS 1.7.1 ändrade de misstänkta komponenterna, men hade ännu inte validerats
En andra användare av ZimaBoard 2 rapporterade upprepade krascher av Python och andra processer nära ett låsningstillfälle. ZimaOS-teamet uppgav att det hade tagit bort Crudini-beroendet från zimaos-welcome, minskade den tjänstens frekvens av resursförfrågningar och planerade ändringarna för en testversion.
Teamet förtydligade senare att Crudini-problemet bara var en utlösande faktor och att den faktiska orsaken till systemkraschen fortfarande utreddes. I ZimaOS 1.7.1 återställdes även Docker Engine-versionen för att förbättra containerstarten och minska risken för blockering av DBus-mäklarmeddelanden.
Det sista inlägget frågar om en annan användare är stabil på 1.7.1, men innehåller inte det nödvändiga drifttidsresultatet. Beskriv inte 1.7.1 som en bekräftad lösning på låsningarna förrän det ursprungliga felförhållandet förblir stabilt längre än dess tidigare tidsfönster.
Eskalera med testerna som redan har avfärdats
Ett starkt supportunderlag innehåller hårdvarumodell, ZimaOS- och kärnversioner, lagringsstyrenhet, arbetsbelastningar, kraschtidpunkter, aktiva startparametrar, loggar från föregående start samt en lista över kontrollerade tester med resultat.
Ange uttryckligen att GPU-acceleration, Frigate-isolering, borttagning av IOMMU/VFIO-parametrar, inaktivering av i915, ändringar av SATA LPM, beständiga loggar, pstore och fjärrloggning från användarutrymmet inte gav någon bekräftad reparation i detta källfall.
Om ett annat operativsystem förblir stabilt under samma belastning medan ZimaOS fortsätter att låsa sig, bevara den jämförelsen och begär en riktad version eller en utredning av leverantören. När tillförlitligheten är verksamhetskritisk är det giltigt att återgå till den stabila miljön, i stället för att fortsätta lägga till overifierade parametrar utan slut.
Vanliga frågor
Orsakade Frigate eller Intel VAAPI krascherna i ZimaOS?
Det bevisades inte i tråden. Krascherna fortsatte efter att GPU-acceleration hade inaktiverats och efter ytterligare isoleringstester av i915.
Åtgärdade borttagningen av IOMMU- och VFIO-parametrarna låsningarna?
Nej. Den aktiva kommandoraden bekräftade att båda hade tagits bort, och värden låste sig igen.
Åtgärdar ZimaOS 1.7.1 fullständiga systemlåsningar?
Versionen ändrade Crudini, zimaos-welcome, Docker Engine och DBus-relaterat beteende, men ämnet avslutas innan något stabilitetsresultat bekräftar återhämtning.
