Esta fuente acabó proporcionando una causa raíz confirmada por IceWhale. Tras actualizar a ZimaOS 1.5.3, la propia matriz RAID NVMe se ensamblaba y montaba, pero zimaos-local-storage lo desmontó inmediatamente porque la base de datos de RAID contenía fs_type = 'BTRFS' en mayúsculas en lugar del valor en minúsculas esperado por el gestor de almacenamiento.
Dina, de IceWhale, proporcionó una actualización específica de SQLite. El autor original la ejecutó y confirmó explícitamente que el RAID se montó con normalidad después. Posteriormente, ZimaOS 1.5.4 incluyó el problema de montaje automático del RAID con BTRFS en mayúsculas como un elemento corregido oficialmente. Por lo tanto, los usuarios actuales deberían considerar el SQL como una guía histórica de recuperación para ese error concreto, no como un comando general de reparación de RAID.
La matriz RAID estaba en buen estado antes de que el gestor de almacenamiento la desmontara
El diario mostraba que el kernel detectaba automáticamente el RAID y que systemd montaba /media/RAID-Storage-2, y luego zimaos-local-storage lo desmontaba por la fuerza unos segundos después.
El registro de la base de datos original también mostraba el RAID como estado correcto. Eso hacía menos probable que hubiera un miembro defectuoso o un sistema de archivos Btrfs destruido.
fstab manual solo funcionó como solución temporal
El usuario montó manualmente el RAID y añadió una entrada en /etc/fstab entry, pero la gestión de almacenamiento de ZimaOS no lo trataba como la configuración autoritativa. Al reiniciar, el servicio local-storage seguía aplicando su estado y base de datos internos.
Por eso, el almacenamiento administrado por el dispositivo normalmente debe repararse mediante la capa de almacenamiento de ZimaOS, en lugar de mantenerse como un montaje manual paralelo.
La comunidad identificó correctamente zimaos-local-storage como la capa responsable
Antes de que IceWhale publicara la causa raíz, gelbuilding detectó la secuencia clave: el montaje tiene éxito y luego zimaos-local-storage lo desmonta. Aconsejó correctamente enviar los registros a IceWhale en lugar de modificar repetidamente los metadatos de RAID.
Su especulación sobre una validación más estricta no fue el diagnóstico final; el diagnóstico oficial posterior fue mucho más específico.
IceWhale encontró el error de capitalización de fs_type
Dina escribió que la base de datos fs_type el valor estaba en mayúsculas, lo que provocaba que el montaje fallara. IceWhale proporcionó:
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"El usuario respondió después: «Esto efectivamente solucionó el problema».
BTRFS en minúsculas btrfs.ZimaOS 1.5.4 corrigió oficialmente el mismo error de montaje automático
Las notas de la versión 1.5.4 indican explícitamente una corrección para el fallo de montaje automático cuando los registros de la base de datos RAID almacenaban BTRFS en mayúsculas.
Consulte la corrección oficial del montaje de RAID en ZimaOS 1.5.4.
Un usuario posterior de la versión 1.5.4 siguió informando que el RAID no se montaba
Otro participante dijo que seguía teniendo un problema de montaje en su sistema 1.5.4. Dina solicitó un diagnóstico reciente del disco y una descripción de los síntomas en lugar de asumir que todavía se trataba del error de fs_type en mayúsculas.
Ese es el límite correcto: síntomas similares pueden tener causas diferentes.
No ejecute el SQL antiguo en un RAID actual sin evidencias coincidentes
La versión actual de ZimaOS es la 1.7.1. Antes de modificar local-storage.db, verifique que:
- el arreglo se ensambla correctamente;
- el registro muestra que el servicio de almacenamiento local lo desmonta;
- la base de datos contiene realmente el valor histórico en mayúsculas;
- tiene una copia de seguridad y un informe de diagnóstico actuales.
Si esas condiciones no coinciden, editar la base de datos puede dificultar la recuperación de un problema de almacenamiento diferente.
La solución oficial se encontró porque el usuario proporcionó los registros adecuados
IceWhale solicitó /ZimaOS-HD/.log/casaos/local-storage.log después de que la comunidad identificara la capa del gestor de almacenamiento. Ese registro permitió al equipo pasar de una teoría general al error exacto de capitalización.
Ante un fallo de montaje actual, conserve el mismo conjunto de evidencias: el estado del ensamblaje del RAID, las líneas del registro, el estado del almacenamiento de ZimaOS y los diagnósticos del almacenamiento local antes de modificar los metadatos.
Haga una copia de seguridad de los metadatos internos antes de editar manualmente la base de datos
El SQL original era una corrección de una sola línea proporcionada por IceWhale para un defecto conocido de la versión 1.5.3. Si alguna vez vuelve a ser necesario editar la base de datos con la orientación del personal, haga primero una copia de seguridad de la base de datos o del estado y aplique únicamente la condición exacta que se está corrigiendo.
Las actualizaciones SQL generales en los registros de RAID pueden desconectar la vista del gestor de almacenamiento del arreglo real y convertir un error de montaje recuperable en un problema de recuperación de metadatos.
Reinstalar no es la primera respuesta ante un RAID sano pero sin montar
Como el arreglo se ensamblaba correctamente y los datos estaban intactos, reinstalar o recrear el RAID habría sido innecesariamente destructivo. Cuando la gestión rechaza un arreglo en buen estado debido a los metadatos, repare la capa de gestión o use el soporte del proveedor antes de modificar la geometría del arreglo.
Preguntas frecuentes sobre el montaje de RAID
¿Se destruyó el RAID en el origen?
No. El arreglo se ensamblaba y montaba antes de que la gestión de almacenamiento de ZimaOS lo desmontara.
¿Cuál fue la causa raíz confirmada?
La base de datos de RAID almacenaba fs_type en mayúsculas BTRFS en lugar de minúsculas btrfs.
¿IceWhale corrigió esto en alguna versión?
Sí. ZimaOS 1.5.4 indica explícitamente que se corrigió el error de montaje automático de BTRFS en mayúsculas.
