Solución de la comunidad

Solución de problemas al crear RAID en ZimaOS con hardware que no es ZimaCube

Page 2 of a long RAID troubleshooting thread documented old ZimaOS 1.2.x/1.3.x disk-slot mapping problems on non-ZimaCube systems, community config edits, and later reports that newer builds resolved some cases.

Si ZimaOS detecta tus unidades, pero la pantalla de creación de RAID las asigna a las bahías incorrectas, deja vacías algunas ranuras seleccionables o muestra solo algunos discos, primero distingue un problema actual de estado del RAID del antiguo problema de asignación de discos en hardware no ZimaCube documentado en este hilo. La página 2 refleja en gran medida el comportamiento de ZimaOS 1.2.x y las primeras versiones 1.3.x en hardware DIY.

La solución de problemas de RAID actual de ZimaOS comienza con el recuento de unidades, el estado de los discos, el formateo individual, un punto de montaje vacío y un reinicio. Solo después de esas comprobaciones deberías considerar las soluciones antiguas para la asignación de ranuras, y únicamente si puedes reproducir el mismo defecto de asignación en tu versión actual.

Cómo se veía el antiguo error de asignación de discos

Varios usuarios de hardware no ZimaCube informaron de que las unidades conectadas físicamente aparecían en posiciones virtuales inesperadas. La página de almacenamiento podía mostrar discos en las bahías 4, 5 y 6, mientras que el cuadro de diálogo de RAID esperaba discos en posiciones anteriores, dejando desactivado el botón «Siguiente» u ocultando una unidad de la selección.

Vista de almacenamiento antigua de ZimaOS que muestra discos no ZimaCube asignados a bahías inesperadas
Una versión antigua de ZimaOS asignaba los discos del hardware DIY a posiciones de bahía inesperadas.
Administrador de almacenamiento antiguo de ZimaOS con discos mostrados en las bahías 4, 5 y 6
La interfaz de almacenamiento podía reconocer los discos mientras el modelo de selección de RAID aún dificultaba su uso.

El reconocimiento y la elegibilidad para RAID eran dos capas diferentes

Pantalla antigua de creación de RAID de ZimaOS en hardware LincStation con ranuras de disco no disponibles
Un sistema DIY podría mostrar el almacenamiento y aun así dejar incompleto el proceso de selección de RAID.

Esta distinción sigue siendo útil hoy. Ver un disco en lsblk demuestra que el kernel detecta un dispositivo de bloques. Verlo en Archivos o en el Administrador de almacenamiento demuestra que otra capa lo reconoce. Que se pueda seleccionar para RAID añade otra capa de elegibilidad y de interfaz de usuario.

Si falla una capa, registra dónde desaparece el disco en lugar de borrarlo inmediatamente. Comprueba el estado del sistema de archivos, los metadatos de RAID existentes, el estado del montaje y si la interfaz actual considera que el disco está disponible para una matriz nueva.

Panel antiguo de «Nuevo disco duro» de ZimaOS en un caso de solución de problemas de RAID en hardware no ZimaCube
La capa de almacenamiento podía detectar una unidad aunque el proceso de RAID no la asignara como se esperaba.
Pantalla antigua de RAID 0 de ZimaOS con solo una bahía de disco seleccionable en hardware DIY
Otra captura de pantalla muestra el mismo desajuste desde el proceso de creación de RAID: el almacenamiento detectado no se reflejaba en las bahías seleccionables esperadas.

Ejecuta las comprobaciones actuales de RAID antes de editar la configuración del sistema

La guía oficial actual para solucionar problemas de RAID recomienda verificar que haya al menos dos unidades, comprobar el estado de los discos, confirmar que cada disco se pueda formatear correctamente, asegurarse de que el punto de montaje previsto esté vacío y reiniciar antes de volver a intentar la creación.

La lista de comprobación actual para solucionar problemas de RAID en ZimaOS debería ser tu primer recurso incluso con hardware DIY, porque evita suposiciones que podrían provocar la pérdida de datos.

SataStartNumber era una solución alternativa comunitaria específica de una versión

En el hilo antiguo, una respuesta del equipo de IceWhale reconoció que la lógica inicial de la interfaz de ZimaOS estaba estrechamente vinculada a la distribución de ranuras del ZimaCube. Se indicó a los usuarios que inspeccionaran la ubicación de los discos en los controladores mediante lsblk -o hctl y, en ciertos sistemas DIY, ajustar SataStartNumber en /etc/casaos/local-storage.conf.

Algunos usuarios confirmaron que esto corrigió la asignación de las bahías virtuales; posteriormente, otros informaron que las versiones más recientes de ZimaOS solucionaron su configuración sin conservar la misma solución alternativa. Por eso, la edición es una técnica histórica de compatibilidad, no un requisito universal actual.

No apliques una SataStartNumber valor de otra placa base. La topología del controlador varía según el sistema, y es posible que el ZimaOS actual ya no utilice las mismas suposiciones.

Las capturas de pantalla muestran por qué son importantes los límites entre versiones

Administrador de almacenamiento de una versión anterior de ZimaOS después de corregir la asignación de las bahías de discos
Más adelante, un usuario mostró los discos ocupando las posiciones de bahía iniciales esperadas después de corregir el problema de asignación.
Pantalla de versión de ZimaOS que muestra una versión beta inicial 1.3.1
Partes del hilo se probaron en versiones iniciales 1.3.x, mucho más antiguas que la interfaz actual de la serie 1.7.x.

ZimaOS 1.7.1 también incluye una corrección para mostrar con precisión el estado del RAID en ciertos escenarios. Esto no demuestra que se hayan resuelto todos los casos de asignación de bahías en sistemas DIY, pero es otra razón para reproducir el problema en una versión actual antes de seguir una modificación de configuración de 2024.

No conviertas la solución alternativa de shell para cinco discos en una receta general

Más adelante, un participante tenía cinco dispositivos NVMe de 8 TB. La interfaz solo mostraba cuatro para la creación del RAID, aunque el quinto dispositivo era visible en otra sección, y finalmente el usuario amplió RAID5 manualmente con mdadm.

Vista de almacenamiento anterior de ZimaOS que detectaba cinco dispositivos NVMe, con uno asignado a un número de ranura inusual
El quinto NVMe era visible para el sistema, pero estaba asignado de forma diferente a los cuatro primeros.
Lista anterior de discos de ZimaOS que mostraba cinco dispositivos miembros de Linux RAID
La lista de discos y la interfaz de creación del arreglo RAID no mostraban el mismo conjunto utilizable.
Pantalla anterior de selección de RAID5 de ZimaOS del caso de solución de problemas con cinco unidades NVMe
El flujo de trabajo de RAID5 formaba parte de las pruebas utilizadas para comparar qué discos eran visibles y cuáles se podían seleccionar.
Pantalla anterior de creación de RAID5 de ZimaOS que mostraba solo cuatro unidades NVMe seleccionables
El quinto dispositivo no aparecía en el paso normal de selección de RAID5.
Estado de RAID5 de una versión anterior de ZimaOS mientras se incorporaba un quinto disco
Finalmente, el usuario amplió el arreglo desde la shell, pero ese procedimiento no se reproduce aquí como recomendación general.

Detener, volver a ensamblar o ampliar un arreglo con comandos de bajo nivel puede provocar la pérdida de datos si la lista de dispositivos o las suposiciones sobre los metadatos son incorrectas. En un sistema actual que reconoce los discos pero no puede utilizarlos en la interfaz de RAID, haz una copia de seguridad de los datos importantes y escala el caso con la versión, lsblk salida, topología del controlador, capturas de pantalla y estado actual del arreglo, en lugar de copiar la antigua secuencia de comandos de shell.