Questa fonte ha infine portato a una causa principale confermata da IceWhale. Dopo l’aggiornamento a ZimaOS 1.5.3, l’array RAID NVMe stesso veniva assemblato e montato, ma zimaos-local-storage lo ha smontato immediatamente perché il database RAID conteneva fs_type = 'BTRFS' in maiuscolo invece del valore minuscolo previsto dal gestore dello storage.
Dina di IceWhale ha fornito un aggiornamento SQLite mirato. L’autore del post originale lo ha eseguito e ha confermato esplicitamente che in seguito il RAID veniva montato normalmente. ZimaOS 1.5.4 ha quindi elencato il problema del montaggio automatico del RAID BTRFS in maiuscolo tra le correzioni ufficiali. Gli utenti attuali dovrebbero pertanto considerare l’SQL come indicazione storica per il ripristino di quel bug specifico, non come comando generico di riparazione RAID.
L’array RAID era integro prima che il gestore dello storage lo smontasse
Il journal mostrava che il kernel rilevava automaticamente il RAID e che systemd montava /media/RAID-Storage-2, e poi zimaos-local-storage smontandolo forzatamente pochi secondi dopo.
Il record del database originale mostrava inoltre il RAID come status ok. Questo rendeva meno probabile che un membro fosse guasto o che il file system Btrfs fosse danneggiato.
fstab manuale ha funzionato solo come soluzione temporanea
L’utente ha montato manualmente il RAID e aggiunto una /etc/fstab entry, ma la gestione dello storage di ZimaOS non lo trattava come configurazione autorevole. Al riavvio, il servizio local-storage continuava ad applicare il proprio stato e database interni.
Per questo, lo storage gestito dall’appliance dovrebbe normalmente essere riparato tramite il livello di storage di ZimaOS, anziché essere mantenuto come montaggio manuale parallelo.
La community ha correttamente identificato zimaos-local-storage come il livello coinvolto
Prima che IceWhale pubblicasse la causa principale, gelbuilding aveva individuato la sequenza chiave: il montaggio riesce, poi zimaos-local-storage lo smonta. Ha correttamente consigliato di inviare i log a IceWhale invece di modificare ripetutamente i metadati RAID.
La sua ipotesi su una convalida più rigida non era la diagnosi finale; la diagnosi ufficiale successiva era molto più specifica.
IceWhale ha individuato l’errore di capitalizzazione di fs_type
Dina ha scritto che il database fs_type il valore era scritto in maiuscolo, causando il fallimento del montaggio. IceWhale ha fornito:
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"L’utente ha poi risposto: «Questo ha effettivamente risolto il problema.»
BTRFS in minuscolo btrfs.ZimaOS 1.5.4 ha risolto ufficialmente lo stesso bug del montaggio automatico
Le note di rilascio della versione 1.5.4 elencano esplicitamente una correzione per il mancato montaggio automatico quando i record del database RAID erano memorizzati BTRFS in maiuscolo.
Consulta la correzione ufficiale di ZimaOS 1.5.4 per il montaggio RAID.
Un utente successivo della versione 1.5.4 ha segnalato nuovamente un RAID non montato
Un altro partecipante ha riferito che sul suo sistema 1.5.4 si verificava ancora un problema di montaggio. Dina ha chiesto una nuova diagnostica del disco e una descrizione dei sintomi, invece di presumere che si trattasse ancora del bug di fs_type in maiuscolo.
Questo è il limite corretto: sintomi simili possono avere cause diverse.
Non eseguire il vecchio SQL su un RAID attuale senza prove corrispondenti
La versione corrente di ZimaOS è la 1.7.1. Prima di modificare local-storage.db, verifica che:
- l'array viene effettivamente assemblato;
- il journal mostra che il servizio local-storage lo sta smontando;
- il database contiene effettivamente il valore storico in maiuscolo;
- hai un backup e un rapporto diagnostico aggiornati.
Se tali condizioni non corrispondono, modificare il database può rendere più difficile il recupero da un problema di storage diverso.
La correzione ufficiale è stata trovata grazie ai log corretti forniti dall'utente
IceWhale ha chiesto /ZimaOS-HD/.log/casaos/local-storage.log dopo che la community ha identificato il livello del gestore dello storage. Quel log ha permesso al team di passare da una teoria generale all'esatto bug di capitalizzazione.
Per un errore di montaggio attuale, conserva lo stesso schema di prove: stato dell'assemblaggio RAID, righe del journal, stato dello storage di ZimaOS e diagnostica dello storage locale prima di modificare i metadati.
Esegui il backup dei metadati interni prima di qualsiasi modifica manuale al database
L'SQL originale era una correzione su una sola riga fornita da IceWhale per un difetto noto della versione 1.5.3. Se fosse nuovamente necessaria una modifica guidata dallo staff al database, esegui prima un backup del database e dello stato, quindi applica solo la condizione esatta da correggere.
Aggiornamenti SQL generici sui record RAID possono scollegare la visualizzazione del gestore dello storage dall'array reale e trasformare un bug di montaggio recuperabile in un problema di recupero dei metadati.
La reinstallazione non è la prima soluzione per un RAID integro ma non montato
Poiché l'array stesso era stato assemblato e i dati erano intatti, reinstallare o ricreare il RAID sarebbe stato inutilmente distruttivo. Quando un array integro viene rifiutato dai metadati di gestione, riparare il livello di gestione o contattare il supporto del fornitore prima di modificare la struttura dell'array.
FAQ sul montaggio RAID
Il RAID stesso era stato danneggiato nella fonte?
No. L'array è stato assemblato e montato prima che la gestione dello storage di ZimaOS lo smontasse.
Qual era la causa principale confermata?
Il database RAID memorizzava fs_type in maiuscolo BTRFS anziché in minuscolo btrfs.
IceWhale ha risolto il problema in una versione successiva?
Sì. ZimaOS 1.5.4 indica esplicitamente come risolto il bug di montaggio automatico di BTRFS scritto in maiuscolo.
