Se entrambi gli slot di avvio di ZimaOS non funzionano e la console segnala errori di montaggio overlay, errori di lettura del superblocco o errori I/O NVMe, non iniziare ricostruendo il pool di archiviazione. Determina prima se il problema riguarda il dispositivo di avvio o i dischi dati separati.
In questo caso di giugno 2026, la diagnostica in sola lettura ha mostrato errori multimediali ripetuti sull’NVMe di avvio, mentre il grande pool dati Btrfs risiedeva su dischi separati. L’utente ha sostituito l’unità di avvio, reinstallato ZimaOS e in seguito ha confermato che il pool dati era ancora presente.
Prima separa il dispositivo di avvio dal pool dati
L’output della shell di ripristino nella discussione mostrava un NVMe da circa 119 GB contenente le partizioni di avvio e dati di ZimaOS, oltre a un pool Btrfs separato composto da più dischi. Questa distinzione ha modificato il piano di recupero: il guasto dell’NVMe di avvio non implicava automaticamente il guasto del pool di archiviazione.
Inizia con comandi in sola lettura:
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineAnnota i nomi esatti dei dispositivi prima di eseguire comandi che interessano un disco o una partizione.
Controlla i log del kernel per verificare gli errori I/O effettivi
Il caso originale conteneva messaggi ripetuti critical medium error, Buffer I/O error, errori di montaggio EXT4 ed errori NVMe riferiti al dispositivo di avvio. Questi messaggi sono una prova molto più forte di un guasto dell’archiviazione rispetto a un generico kernel panic nella schermata di avvio.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'Se gli errori indicano sistematicamente l’NVMe di avvio mentre i dischi dati non segnalano problemi, concentra l’analisi sul percorso di avvio.
Un risultato SMART “PASSED” non annulla gli errori multimediali
Nella discussione, il riepilogo dello stato SMART dell’NVMe indicava ancora PASSED, ma i contatori dettagliati mostravano 76 errori multimediali e di integrità dei dati e il kernel registrava già letture non riuscite. Anche il controllo del filesystem in sola lettura si era interrotto a causa di blocchi illeggibili.
Usa dati dettagliati sullo stato, come smartctl -x /dev/nvmeXn1 o nvme smart-log /dev/nvmeXn1, dopo aver verificato il nome corretto del dispositivo. Non considerare l’unica parola relativa allo stato generale come una diagnosi completa.
Utilizza prima i controlli del filesystem in sola lettura
La community ha utilizzato e2fsck -fn sulla partizione overlay EXT4 interessata, così da ispezionare il filesystem senza scrivere correzioni. Anche questo controllo in sola lettura ha rilevato blocchi illeggibili, rafforzando la diagnosi di un guasto hardware.
Non eseguire mai fsck in modalità di scrittura su un filesystem montato e non indovinare i nomi delle partizioni. Se l’SSD di avvio sta cedendo fisicamente, tentativi di scrittura ripetuti possono rendere più difficile il recupero.
Perché possono non funzionare né lo slot A né lo slot B
ZimaOS utilizza slot di sistema A/B per il ripristino, come documentato nella guida al ripristino del sistema ZimaOS. Tuttavia, entrambe le opzioni di avvio dipendono da componenti di archiviazione condivisi e funzionanti sul dispositivo di avvio. Un overlay o un NVMe di avvio guasto può quindi impedire a entrambi gli slot di completare l’avvio.
Quando la sostituzione è la scelta più sicura
Quando il caso originale ha mostrato errori multimediali del kernel, contatori SMART dettagliati relativi agli errori multimediali e blocchi illeggibili sul filesystem dell’NVMe di avvio, la community ha consigliato di considerare l’SSD non affidabile invece di tentare di ripararlo sul posto. L’utente lo ha sostituito e ha reinstallato ZimaOS con successo.
Durante la reinstallazione, identifica chiaramente i dischi dati ed evita di inizializzare o ricreare un pool esistente. La guida alla risoluzione dei problemi di installazione di ZimaOS è utile per la parte relativa all’installazione sul dispositivo di avvio, mentre la guida al recupero dello spazio di archiviazione dopo la reinstallazione ribadisce la regola fondamentale: non ricreare un pool che contiene già i tuoi dati.
In sintesi
In questo caso, il kernel panic era dovuto a un guasto dell’NVMe di avvio e non dimostrava che il pool dati separato fosse stato distrutto. Esegui la diagnosi in sola lettura, conferma quale dispositivo presenta gli errori I/O e non modificare i dischi dati. L’utente originale ha sostituito l’unità di avvio guasta, reinstallato ZimaOS e confermato che il pool dati esistente era sopravvissuto.
