Si usas Linux tarde o temprano verás el temido mensaje de error relacionado con el superblock (superbloque): cosas como “Can’t read superblock”, “bad superblock” o errores de fsck que hablan de superbloques alternativos. Y claro, en ese momento cunde el pánico porque tu partición no monta, el sistema entra en BusyBox o tu disco USB externo parece muerto.
La buena noticia es que los sistemas de ficheros tipo ext2, ext3 y ext4 están pensados precisamente para sobrevivir a estos sustos: guardan copias de seguridad del superbloque en varios puntos del disco y existen un montón de herramientas (fsck, e2fsck, dumpe2fs, debugfs, badblocks, etc.) que permiten comprobar, reparar y hasta recuperar datos en situaciones muy feas. En este artículo vas a ver con calma qué es el superbloque, cómo se corrompe, cómo usar sus copias de respaldo y qué hacer en cada escenario realista, desde un portátil que arranca en BusyBox hasta un pendrive que ya no monta ni a tiros.
Qué es el superbloque en Linux y por qué es tan importante
En un sistema de archivos ext2/ext3/ext4, el superbloque es el “cerebro” del volumen. Es una estructura de datos que se guarda en el disco y que contiene prácticamente toda la “ficha técnica” del sistema de archivos: cuántos bloques tiene, cuántos inodos, qué tamaño de bloque usa, cuántos bloques libres quedan, estado del sistema, características activadas, tiempos de montaje y chequeo, etc.
El superbloque principal se almacena al inicio del sistema de archivos (en el bloque 0 o tras el boot block, según el tamaño de bloque), pero el diseño de ext2/3/4 es prudente: también guarda copias de seguridad del superbloque repartidas por varios grupos de bloques. Esas copias son las que nos permiten “resucitar” un sistema de archivos cuando el superbloque principal queda dañado.
Internamente, el superbloque es una estructura enorme con decenas de campos: contador total de inodos (s_inodes_count), número total de bloques (s_blocks_count_lo y la parte alta s_blocks_count_hi en ext4 64 bits), bloques reservados para root, bloques e inodos libres, primer bloque de datos, tamaño de bloque a partir de s_log_block_size, bloques por grupo, inodos por grupo, sello mágico 0xEF53 que identifica ext2/3/4, flags de características compatibles, incompatibles y solo-lectura, UUID, etiqueta de volumen, ruta donde se montó por última vez, parámetros de journaling, tiempos de último montaje y chequeo, número máximo de montajes antes de forzar fsck, información de errores, checksums, soporte de cifrado, RAID, snapshots, etc.
Todo esto hace que un superbloque corrupto sea un problema muy serio, porque el kernel deja de saber dónde empieza y acaba cada cosa dentro del sistema de archivos. Por eso, si al montar una partición ves mensajes tipo “wrong fs type, bad option, bad superblock…”, tienes casi todas las papeletas de que el superbloque principal (o parte de los metadatos) está tocado.
Dónde se guardan las copias de superbloque y cómo localizarlas
Lo primero que hay que entender es que ext2/ext3/ext4 guardan copias de superbloque en distintos bloques del disco, de forma que si se daña la copia principal podamos recurrir a uno de esos respaldos. La ubicación exacta depende del tamaño de bloque y de cómo se creó el sistema de archivos.
Hay dos maneras muy habituales de averiguar dónde están esas copias usando herramientas estándar:
- Leyendo la documentación/man de
e2fsck. - Usando
dumpe2fso unmke2fsen modo “simulación” (-n) para que nos liste los bloques que contienen copias de superbloque.
Para sistemas ext con tamaños de bloque clásicos tenemos unos valores “típicos” para la primera copia de respaldo: si el tamaño de bloque es de 1K, la copia suele estar en el bloque 8193; con bloques de 2K suele ser el 16384; y con bloques de 4K, el bloque 32768. Pero para estar seguros, lo ideal es consultar el tamaño de bloque real del dispositivo.
Para averiguar el tamaño de bloque de un sistema de archivos ext podemos ejecutar algo así (siempre mejor con la partición desmontada):
sudo dumpe2fs /dev/sdb5 | grep "Block size"
La salida típica de dumpe2fs incluye una línea del estilo “Block size: 4096”, lo que significa que el tamaño de bloque es 4K. Con ese dato ya sabemos que la primera copia de superbloque probable se encuentra en el bloque 32768.
Si queremos conocer no solo una copia sino todas las copias de superbloque, la manera más práctica es “simular” la creación de un sistema de archivos nuevo con mke2fs usando la opción -n (muy importante) para que no toque el disco de verdad:
sudo mke2fs -b 4096 -n /dev/sdb5 | grep -A 3 "Respaldo"
La opción -b fija el tamaño de bloque (por ejemplo 4096) y la opción -n le dice a mke2fs que no escriba nada en disco, solo que muestre la configuración que usaría. En la salida verás una sección del tipo “Respaldo del superbloque guardado en los bloques:” seguida de una lista larga de números de bloque: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, etc.
Errores típicos: “Can’t read superblock” y fallos de montaje
Un síntoma tremendamente común de que algo va mal con el superbloque es encontrarse con un error del estilo:
mount: /dev/sdb5: Can't read superblock
Este mensaje suele aparecer al intentar montar un disco USB externo, una memoria USB o incluso una partición interna que hasta hace poco funcionaba sin problema. En muchos casos significa que el superbloque principal está corrupto o que hay inconsistencias graves en los metadatos.
También puedes ver errores más largos cuando el sistema intenta montar la raíz durante el arranque y termina dándote una shell de BusyBox (initramfs). Por ejemplo, mensajes indicando que no se pueden montar /sys o /proc en /root, o que no se puede abrir /root/dev/console. Esto suele venir de que la partición raíz no ha podido montarse por problemas de superbloque o de sistema de ficheros.
En ese contexto, ejecutar fsck directamente sobre la partición problemática puede devolver errores del tipo: “fsck.ext4: el intento de leer el bloque del sistema de archivos resultó en una lectura breve… ¿podría ser esta una partición de longitud cero?”. Ese mensaje normalmente significa que el superbloque que intenta usar fsck está dañado o que la tabla de bloques no cuadra.
Antes de liarte a reparar a ciegas, conviene asegurarse de que el problema no es algo tan simple como una mala alimentación (muy típico en Raspberry Pi con discos USB sin fuente propia). Cuando la fuente de alimentación se queda corta, el subsistema de journaling puede fallar y el sistema monta la partición como ext2 de solo lectura para no jugársela. En una Pi, por ejemplo, puede aparecer un rayo amarillo o un recuadro de colores en pantalla indicando falta de energía.
Si tras volver a montar con sudo mount -a el sistema funciona temporalmente, es posible que cambiando la fuente a una de 2,5A (en el caso de la Raspberry) el problema desaparezca. Pero si tras revisar la alimentación y reintentar el montaje los errores de superbloque siguen ahí, toca pasar al plan de rescate con copias de superbloque y herramientas de chequeo.
Uso de fsck y e2fsck con superbloques alternativos
La herramienta estándar para comprobar y reparar sistemas ext2/ext3/ext4 es e2fsck, que normalmente invocamos a través de fsck. Es fundamental usarla siempre con la partición desmontada (o montada solo en lectura) para evitar daños mayores; la propia documentación insiste en ello. Esta es su sintaxis básica:
sudo fsck -b 32768 -p /dev/sdb5
Con la opción -b indicamos el número de bloque donde está la copia de superbloque que queremos usar (por ejemplo 32768) y con -p le pedimos una reparación automática sin exigir interacción en cada cambio (la vieja opción -a se mantiene por compatibilidad pero se recomienda usar -p).
En sistemas más antiguos o si queremos ver todo el proceso paso a paso, podemos llamar directamente a e2fsck con el superbloque alternativo:
sudo e2fsck -b 32768 /dev/hda2
El chequeo pasa por varias fases. Cuando e2fsck termina sin errores críticos, puedes intentar montar de nuevo la partición desde el Live CD o el sistema normal:
sudo mount /dev/hda2 /mnt
En muchos casos, tras una reparación con un superbloque de respaldo, el sistema de archivos vuelve a un estado coherente y puedes acceder de nuevo a tus datos. A partir de ahí, lo sensato es hacer copia de seguridad de todo lo importante por si vuelve a dar problemas más adelante.
Comprobación de bloques defectuosos y herramientas avanzadas
Cuando empiezan a aparecer errores de superbloque, conviene sospechar también de la salud física del disco o dispositivo. Si hay bloques defectuosos en las zonas donde se guardan superbloques o metadatos críticos, el sistema de archivos acabará corrompiéndose una y otra vez. Estas herramientas son de gran utilidad:
badblocks
La herramienta badblocks sirve para buscar bloques defectuosos en un dispositivo (normalmente una partición o un disco completo). Puede trabajar en modo solo lectura o en modo destructivo de escritura, y admite distintas opciones:
-b: tamaño del bloque en bytes (por defecto 1024).-e: número máximo de bloques defectuosos “posibles” antes de abortar.-i <fichero>: leer una lista de bloques malos ya conocidos para no volver a probarlos.-n: prueba no destructiva (solo lectura, no combinar con-w).-o <archivo>: escribir la lista de bloques defectuosos en un fichero.-s: mostrar el porcentaje de progreso.-w: modo destructivo de escritura (sobrescribe datos).
Para integrar estos resultados con el sistema de archivos ext se suele usar e2fsck -c, que llama internamente a badblocks y añade los bloques defectuosos descubiertos a la lista de “bloques malos” del sistema, de forma que no se vuelvan a usar para nuevos archivos.
dumpe2fs
Otra herramienta potente es dumpe2fs, que muestra un informe completo del sistema de archivos ext: tamaño de bloque, UUID, tamaño de inodo, veces montado, flags, lista de superbloques de respaldo, bloques marcados como malos, etc. Sus opciones más interesantes son:
-b: listar solo los bloques marcados como defectuosos.-o superblock=<sb>: usar un superbloque concreto para examinar el dispositivo.-o blocksize=<bs>: forzar un tamaño de bloque específico (útil en sistemas muy dañados).-h: mostrar únicamente la información del superbloque.
tune2fs
Si lo que quieres es ajustar parámetros de funcionamiento del sistema de archivos ext (intervalos de chequeo, porcentaje de bloques reservados para root, añadir journaling a ext2, etc.), la herramienta clave es tune2fs:
-c: número máximo de montajes sin pasarfsck.-C: fijar el conteo actual de montajes.-i <tiempo>: intervalo máximo entre chequeos (d, w, m).-j: añadir journaling a un ext2 (lo convierte en ext3/ext4).-m: porcentaje de bloques reservados para root (por defecto 5%).-r: reservar un número absoluto de bloques.-f: forzar ejecución aunque haya ciertos errores.-g: reservar bloques a un grupo UNIX concreto.
debugfs
Para operaciones aún más bajas y quirúrgicas existe debugfs, un depurador interactivo de sistemas de archivos ext que permite examinar y modificar estructuras internas. Algunas de sus capacidades:
-w: abrir el sistema de archivos en modo lectura/escritura.-c: forzar apertura en solo lectura (útil si hay inconsistencia).-f <archivo>: ejecutar una lista de comandos y salir.
Una vez dentro de debugfs, tienes comandos como show_super_stats / stats para ver superbloques, stat para ver el inodo de un archivo, lsdel para listar inodos borrados, undel para intentar recuperar un archivo eliminado conociendo su inodo, write para extraer archivos a otro sistema de archivos, además de equivalentes a cd, rm, ln, mkdir, etc. Es una navaja suiza, pero hay que usarla con extremo cuidado.
Superbloque y reparación en otros sistemas de archivos (XFS, herramientas varias)
Aunque aquí nos hemos centrado en ext2/3/4, otros sistemas de archivos también tienen sus propias estructuras de “superbloques” y herramientas específicas para gestionarlos, como es el caso de XFS.
En XFS, las utilidades más relevantes para temas de integridad y metadatos son varias. Por ejemplo, xfs_info muestra información técnica del sistema de archivos XFS montado (a diferencia de otras herramientas, aquí sí debe estar montado).
Para depurar metadatos, existe xfs_metadump, que crea un volcado de los metadatos del sistema de archivos en un archivo para análisis posterior. Es importante recalcar que no es una herramienta de copia de seguridad de datos, sino de depuración:
-g: mostrar el progreso del volcado.-e: ignorar errores de lectura y copiar solo lo accesible.-f: indicar que el sistema de archivos está en un archivo regular.-w: mostrar por pantalla los errores encontrados.
Para modificar parámetros de configuración de un XFS ya creado se utiliza xfs_admin, algo así como el equivalente de “bajo nivel” a tune2fs pero para XFS:
-j: habilitar la versión 2 de journaling.-ly-u: mostrar etiqueta y UUID del sistema de archivos.-L <Etiqueta>y-U <UUID>: cambiar etiqueta y UUID.
Siempre hay que desmontar el sistema de archivos XFS antes de aplicar cambios con xfs_admin o realizar comprobaciones destructivas para evitar daños.
Para comprobar consistencia en XFS se usa xfs_check, que examina la coherencia del sistema de ficheros, y xfs_repair para repararlo. Ambos requieren que el sistema de archivos esté desmontado, salvo la opción especial de xfs_repair -d que permite reparar un sistema montado en solo lectura (por ejemplo, la raíz) y exige reiniciar después:
xfs_check -f <archivo.img>: tratar la imagen como archivo regular.xfs_check -l <log-file>: log externo.xfs_check -s: mostrar solo errores graves.xfs_repair -n: no repara, solo indica qué está mal.xfs_repair -P: desactivar la prelectura de inodos/directorios.xfs_repair -m <maxmem>: limitar RAM usada.xfs_repair -d: permitir reparar en solo lectura (caso especial).
Otras herramientas como xfs_ncheck listan inodos e identifican rutas de archivos, o xfs_check determina si el sistema está consistente. Todo este arsenal viene muy bien cuando el problema no es un ext4 sino un XFS que se ha corrompido por un apagón o un fallo de hardware.
En conjunto, entender qué es el superbloque, dónde se guardan sus copias y cómo usar herramientas como fsck, e2fsck, dumpe2fs, badblocks, debugfs o las utilidades XFS te pone en una posición mucho mejor para no entrar en pánico cuando aparezcan errores de “bad superblock” en Linux y para tomar decisiones sensatas entre intentar recuperar datos, reparar de forma segura o directamente rehacer la partición desde cero cuando ya no hay nada que salvar.
