Si ambas ranuras de arranque de ZimaOS fallan y la consola informa de errores al montar la superposición, fallos al leer el superbloque o errores de E/S de NVMe, no empieces reconstruyendo el grupo de almacenamiento. Primero determina si el fallo está en el dispositivo de arranque o en los discos de datos independientes.
En este caso de junio de 2026, los diagnósticos de solo lectura mostraron errores de medios repetidos en el NVMe de arranque, mientras que el gran grupo de datos Btrfs estaba en discos independientes. El usuario reemplazó la unidad de arranque, reinstaló ZimaOS y posteriormente confirmó que el grupo de datos seguía allí.
Primero separa el dispositivo de arranque del grupo de datos
La salida del shell de rescate del hilo mostraba un NVMe de aproximadamente 119 GB que contenía las particiones de arranque y datos de ZimaOS, además de un grupo Btrfs independiente compuesto por varios discos. Esa distinción cambió el plan de recuperación: el fallo del NVMe de arranque no implicaba automáticamente que el grupo de almacenamiento hubiera fallado.
Empieza con comandos de solo lectura:
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdlineAnota los nombres exactos de los dispositivos antes de ejecutar cualquier comando dirigido a un disco o una partición.
Comprueba los registros del kernel en busca de errores reales de E/S
El caso original contenía errores repetidos de critical medium error, Buffer I/O error, fallos al montar EXT4 y errores de NVMe relacionados con el dispositivo de arranque. Estos mensajes son pruebas mucho más sólidas de un fallo de almacenamiento que un pánico genérico en la pantalla de arranque.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'Si los errores apuntan sistemáticamente al NVMe de arranque y los discos de datos no informan de fallos, centra la investigación en la ruta de arranque.
Un resultado SMART «PASSED» no anula los errores de medios
En el hilo, el resumen del estado SMART del NVMe todavía indicaba PASSED, pero los contadores detallados mostraban 76 errores de medios o integridad de datos y el kernel ya registraba lecturas fallidas. La comprobación del sistema de archivos en modo de solo lectura también se canceló al encontrar bloques ilegibles.
Usa datos detallados del estado, como smartctl -x /dev/nvmeXn1 o nvme smart-log /dev/nvmeXn1, después de confirmar el nombre correcto del dispositivo. No consideres la única palabra del estado general como el diagnóstico completo.
Usa primero comprobaciones del sistema de archivos en modo de solo lectura
La comunidad utilizó e2fsck -fn en la partición de superposición EXT4 afectada para inspeccionar el sistema de archivos sin escribir reparaciones. Incluso esa comprobación de solo lectura encontró bloques ilegibles, lo que reforzó el diagnóstico de un fallo de hardware.
No ejecutes nunca fsck en modo de escritura sobre un sistema de archivos montado ni adivines los nombres de las particiones. Si el SSD de arranque está fallando físicamente, los intentos repetidos de escritura pueden dificultar la recuperación.
Por qué pueden fallar las ranuras A y B
ZimaOS utiliza ranuras de sistema A/B para la recuperación, tal como se documenta en la guía de recuperación del sistema de ZimaOS. Sin embargo, ambas opciones de arranque siguen dependiendo de componentes de almacenamiento compartidos en buen estado dentro del dispositivo de arranque. Por ello, una superposición o un NVMe de arranque defectuoso puede impedir que ambas ranuras completen el inicio.
Cuándo es más seguro reemplazar la unidad
Cuando el caso original mostró errores de medios del kernel, contadores detallados de errores de medios en SMART y bloques ilegibles del sistema de archivos en el NVMe de arranque, la comunidad recomendó tratar ese SSD como poco fiable en lugar de intentar repararlo en el mismo dispositivo. El usuario lo reemplazó y reinstaló ZimaOS correctamente.
Durante la reinstalación, identifica claramente los discos de datos y evita inicializar o recrear un grupo existente. La guía de solución de problemas de instalación de ZimaOS ayuda con la instalación del sistema de arranque, mientras que la guía de recuperación del almacenamiento tras la reinstalación refuerza la regla clave: no recrees un grupo que ya contiene tus datos.
En resumen
En este caso, el pánico del kernel se debió a un fallo del NVMe de arranque, no era una prueba de que el grupo de datos independiente hubiera sido destruido. Realiza diagnósticos de solo lectura, confirma qué dispositivo presenta los errores de E/S y no toques los discos de datos. El usuario original reemplazó la unidad de arranque defectuosa, reinstaló ZimaOS y confirmó que el grupo de datos existente había sobrevivido.
