Distingui innanzitutto un blocco completo dell'host da un guasto di rete
La macchina segnalata ha perso l'accesso alla rete, il ping, i container, la risposta della console locale e l'uscita video. L'ampiezza del problema va oltre un'interruzione di SMB, Docker o della scheda di rete ed è coerente con un blocco completo dell'host che richiede un ciclo di spegnimento e riaccensione.
Se un server scompare dalla rete, controlla la console locale e il display prima di acquistare una scheda di rete sostitutiva. Una console reattiva orienta l'indagine verso la rete; una console bloccata e la perdita del display la orientano verso kernel, firmware, alimentazione, archiviazione o hardware.
Registra l'ora esatta dell'evento e indica se la macchina si è riavviata autonomamente o è rimasta alimentata ma non reattiva. Queste osservazioni determinano quale intervallo del boot precedente e quali dati del monitoraggio esterno possono essere confrontati.
Raccogli le prove del boot precedente prima di modificare le variabili
La prima raccolta utile nella discussione è stata journalctl -b -1, inclusi i messaggi del kernel e quelli ad alta priorità dell'avvio terminato con il blocco. Il team di ZimaOS ha in seguito richiesto, per un'analisi privata, le ultime 500 voci del boot precedente e il journal persistente.
Esamina i log per verificare la presenza di informazioni personali prima di pubblicarli. In questo caso, la registrazione persistente era abilitata, ma il log si è interrotto bruscamente all'ora del guasto osservato, senza panic, terminazione per esaurimento della memoria (OOM), ripristino della GPU, errori di archiviazione, eventi termici, blocco del watchdog o arresto normale.
Un record finale vuoto non dimostra che non sia avvenuto alcun errore. Indica che l'host si è arrestato prima che il sistema locale di registrazione disponibile potesse registrare una causa. Ripetere lo stesso comando di log dopo ogni identico blocco silenzioso serve a poco, a meno che non cambi il metodo di acquisizione.
I test su GPU e Frigate non hanno individuato una soluzione
Il sistema utilizzava la grafica Intel i915 e Frigate VAAPI, quindi l'autore ha innanzitutto disabilitato l'accelerazione GPU. L'host ha continuato a bloccarsi. L'arresto completo di Frigate ha prodotto a un certo punto un intervallo più lungo, ma i test successivi non hanno dimostrato che Frigate fosse la causa.
L'autore ha anche provato a disabilitare i915, rendendo inutilizzabili altri carichi di lavoro, e il sistema si è infine bloccato di nuovo. Questo risultato esclude «disabilitare i915» come soluzione efficace in questo caso.
Il confronto con OpenMediaVault era significativo: lo stesso hardware e la stessa configurazione di Frigate erano rimasti stabili. Ciò fa sospettare un'interazione specifica di ZimaOS con il kernel o i driver, ma non identifica di per sé quale componente abbia smesso di funzionare.
IOMMU, VFIO e i suggerimenti su SATA LPM sono stati esclusi come soluzioni
Inizialmente ZimaOS includeva intel_iommu=on e vfio_iommu_type1.allow_unsafe_interrupts=1. Un membro del team ha chiesto all'autore di rimuoverli entrambi. La riga di comando attiva ha confermato la loro assenza, ma la macchina si è bloccata di nuovo.
L'autore ha quindi testato libata.force=nolpm perché i dischi dati utilizzavano un adattatore da M.2 a SATA. Un altro blocco si è verificato la mattina seguente. Pertanto, la discussione non supporta nessuna delle due modifiche ai parametri di avvio come soluzione.
Questi test mostrano anche perché gli aggiornamenti possono invalidare un esperimento: un aggiornamento aveva sovrascritto il file personalizzato della riga di comando. Verificare sempre la riga di comando di avvio attiva prima di interpretare l'uptime e modificare una sola variabile durante la finestra di crash stabilita.
Journal persistente, pstore e forwarding remoto hanno raggiunto i propri limiti
Il kernel includeva pstore e il rilevamento dei lockup hard/soft, e il watchdog NMI era attivo. Tuttavia, /sys/fs/pstore fosse rimasto vuoto dopo gli arresti anomali, mentre non era stato riservato alcun kernel di crash per kdump.
Il netconsole all'avvio ha analizzato la configurazione, ma si è avviato prima che eth0 era presente e si è disabilitato. Un processo nello spazio utente journalctlIl forwarder -to-UDP ha raggiunto una seconda macchina Linux, ma si è anch'esso arrestato senza una causa finale quando l'host si è bloccato.
Questo risultato è utile: il forwarding nello spazio utente non può inviare messaggi dopo l'arresto dello scheduler o dello stack di rete e non può generare un avviso del kernel che non è mai stato emesso. A questo punto, un kernel di debug del fornitore o una strumentazione mirata sono più utili di un'altra cattura identica nello spazio utente.
ZimaOS 1.7.1: i componenti sospetti sono cambiati, ma non sono ancora stati convalidati
Un secondo utente di ZimaBoard 2 ha segnalato arresti anomali ripetuti di Python e di altri processi poco prima di un blocco. Il team di ZimaOS ha dichiarato di aver rimosso la dipendenza Crudini da zimaos-welcome, ha ridotto la frequenza delle richieste di risorse di quel servizio e ha pianificato le modifiche per una versione di test.
Il team ha successivamente chiarito che il problema di Crudini era solo un fattore scatenante e che la causa effettiva del crash del sistema era ancora oggetto di indagine. In ZimaOS 1.7.1 ha inoltre riportato alla versione precedente il motore Docker per migliorare l'avvio dei container e ridurre la probabilità di blocco dei messaggi del broker DBus.
Il post finale chiede se un altro utente è stabile con la versione 1.7.1; non fornisce il risultato di operatività continua richiesto. Non descrivere la versione 1.7.1 come una soluzione confermata ai blocchi finché la condizione di errore originale non rimane stabile oltre la finestra precedente.
Escalation con i test già esclusi
Un solido pacchetto di supporto include il modello hardware, le versioni di ZimaOS e del kernel, il controller di archiviazione, i carichi di lavoro, gli orari dei crash, i parametri di avvio attivi, i log dell'avvio precedente e un elenco dei test controllati con i relativi risultati.
Dichiara esplicitamente che l'accelerazione GPU, l'isolamento di Frigate, la rimozione dei parametri IOMMU/VFIO, la disattivazione di i915, le modifiche a SATA LPM, i log persistenti, pstore e la registrazione remota dello spazio utente non hanno prodotto una riparazione confermata in questo caso specifico.
Se un altro sistema operativo rimane stabile con lo stesso carico di lavoro mentre ZimaOS continua a bloccarsi, conserva questo confronto e richiedi una build mirata o un'indagine del fornitore. Quando l'affidabilità è operativamente critica, tornare all'ambiente stabile è un limite di arresto valido, invece di accumulare indefinitamente parametri non verificati.
Domande frequenti
Frigate o Intel VAAPI hanno causato i crash di ZimaOS?
La discussione non lo ha dimostrato. I crash sono continuati dopo la disattivazione dell'accelerazione GPU e dopo ulteriori test di isolamento di i915.
La rimozione dei parametri IOMMU e VFIO ha risolto i blocchi?
No. La riga di comando attiva ha confermato che entrambi erano stati rimossi, e l'host si è bloccato di nuovo.
ZimaOS 1.7.1 risolve i blocchi completi del sistema?
La versione ha modificato Crudini, zimaos-welcome, il motore Docker e il comportamento correlato a DBus, ma l'argomento si interrompe prima che un risultato sulla stabilità confermi il ripristino.
