Recuperación del sistema tras un fallo de arranque

Objetivo:

Comprender y aplicar los procedimientos críticos de recuperación de un sistema Linux que no arranca, utilizando un medio externo (Live USB), el entorno de cambio de raíz (chroot), la reparación de tablas de ficheros con fsck y la reconstrucción del gestor de arranque GRUB.

Escenario:

  • Herramientas: Live USB de rescate, terminal Linux, comandos chroot, mount, fsck, update-grub y grub-install.
  • Conceptos analizados: Proceso de arranque del sistema operativo, puntos de montaje virtuales del kernel (/dev, /proc, /sys), sistemas de ficheros dañados por cortes de energía y reparación de la interfaz de arranque MBR/UEFI.
  • Proceso clave: Simulación de un fallo crítico de arranque, arranque desde un entorno Live USB externo, vinculación de la instalación dañada mediante chroot, reparación del sistema de archivos y reinstalación del cargador GRUB.

Escenario Real: Servidor con corrupción de arranque tras apagón

Un servidor crítico de la empresa ha sufrido un corte repentino de energía eléctrica. Al reiniciar, el sistema se queda congelado en una pantalla negra con un error de GRUB o entra en modo de emergencia debido a la corrupción masiva de la partición raíz. Al no poder iniciar el sistema operativo de forma habitual, debes utilizar un medio externo de rescate para acceder al disco interno, reparar la integridad de los datos y restaurar el arranque.

Por defecto, los sistemas operativos están diseñados para arrancar de forma totalmente automatizada. Sin embargo, fallos de hardware, corrupción de sectores o fallos humanos al actualizar el gestor de archivos pueden bloquear por completo el inicio. Dominar el uso de chroot y las herramientas de rescate es la última línea de defensa para un administrador de sistemas.

NOTA: Para realizar esta práctica de simulación de rescate, puedes emplear una máquina virtual o un entorno de prácticas donde dispongas de acceso a una ISO de rescate o Live CD.

Instrucciones:

Fase 1: Arranque externo (Live USB) e identificación de particiones:

  • Arrancar el equipo utilizando un medio de rescate externo (Live USB o ISO en entorno virtual).
  • Abrir una terminal en el sistema Live e identificar las particiones del disco duro interno dañado mediante el comando: lsblk o sudo fdisk -l
  • Localizar la partición raíz (ej. /dev/sda2 o /dev/nvme0n1p2) y, si procede, la partición EFI o de arranque independiente (/boot/efi).

Fase 2: Montaje del sistema de archivos y reparación con fsck:

  • Si sospechas que el fallo se debe a un apagón que ha corrompido el sistema de archivos, puedes ejecutar una comprobación y reparación de bloques (asegúrate de que la partición NO esté montada): sudo fsck -y /dev/sda2
  • Crear un directorio temporal de montaje para acceder al sistema dañado: sudo mkdir -p /mnt/rescate
  • Montar la partición raíz interna en dicho directorio: sudo mount /dev/sda2 /mnt/rescate
  • Si tu sistema utiliza una partición de arranque UEFI independiente, móntala también en su ruta correspondiente: sudo mount /dev/sda1 /mnt/rescate/boot/efi

Fase 3: Cambio de raíz (chroot) para entrar en el sistema dañado:

  • Para poder ejecutar comandos como si estuvieras dentro del sistema operativo averiado, debes montar los sistemas de archivos virtuales del kernel (dispositivos, procesos y kernel virtual) compartiéndolos con el directorio de rescate: 
    sudo mount --bind /dev /mnt/rescate/dev
sudo mount --bind /proc /mnt/rescate/proc
sudo mount --bind /sys /mnt/rescate/sys
sudo mount --bind /run /mnt/rescate/run
  • Acceder al interior del sistema dañado cambiando la raíz del entorno mediante el comando chroot: sudo chroot /mnt/rescate
  • A partir de este momento, cualquier comando que ejecutes se aplicará directamente sobre el sistema operativo instalado en el disco duro interno.

Fase 4: Reinstalación y actualización del gestor de arranque (GRUB):

  • Una vez dentro del entorno chroot, reinstalar el cargador GRUB en el disco principal (por ejemplo, /dev/sda): grub-install /dev/sda (en sistemas UEFI, el procedimiento varía configurando el directorio EFI).
  • Actualizar la configuración y los ficheros de arranque detectando los núcleos disponibles: update-grub
  • Salir del entorno chroot escribiendo: exit
  • Desmontar ordenadamente todos los directorios vinculados y reiniciar el equipo de forma segura: 
    sudo umount /mnt/rescate/dev /mnt/rescate/proc /mnt/rescate/sys /mnt/rescate/run
sudo umount /mnt/rescate/boot/efi # Si procede
sudo umount /mnt/rescate
sudo reboot

Verificación:

  • Comprobar que tras retirar el Live USB y reiniciar el equipo, el sistema operativo arranca con normalidad mostrando el menú gráfico de selección de GRUB.
  • Verificar que el acceso al sistema se realiza correctamente introduciendo las credenciales habituales sin errores de montaje de ficheros.

Posibles errores y resolución de problemas:

Si al intentar ejecutar el comando chroot /mnt/rescate el sistema devuelve un error crítico de tipo failed to run command '/bin/bash': Exec format error, se debe a una incompatibilidad de arquitecturas.

  • Solución: Este error ocurre habitualmente si intentas hacer chroot desde un Live USB de 32 bits hacia un sistema instalado de 64 bits (o viceversa). Asegúrate de que el medio de rescate externo coincide exactamente con la arquitectura (x86_64) del sistema operativo averiado.

Alternativa directa: Comprobación rápida de errores en discos

Si el sistema arranca pero entra directamente en un modo de emergencia (Emergency Mode) debido a que una partición secundaria o de datos presenta errores de bloques tras un apagón inesperado, puedes desmontarla y lanzar una reparación automatizada sin necesidad de usar un Live USB externo:

sudo umount /dev/sdX1
sudo fsck -f -y /dev/sdX1

Preguntas de reflexión:

  1. ¿Qué función fundamental cumple el comando chroot al cambiar temporalmente el directorio raíz del sistema operativo durante un proceso de rescate?
  2. ¿Por qué es estrictamente necesario montar los directorios virtuales /dev, /proc y /sys dentro del directorio de rescate antes de entrar mediante chroot?
  3. ¿Qué implicaciones tiene ejecutar el comando fsck sobre un sistema de archivos que se encuentra montado y activo en modo de lectura y escritura?
  4. ¿Qué diferencia principal existe al reinstalar el gestor GRUB en un entorno tradicional basado en MBR frente a un sistema moderno basado en particionamiento UEFI?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué función fundamental cumple el comando chroot al cambiar temporalmente el directorio raíz del sistema operativo durante un proceso de rescate?

Permite cambiar el directorio raíz percibido por los procesos en ejecución y sus hijos, haciendo que el sistema de ficheros de la instalación dañada (montado en /mnt/rescate) pase a ser considerado el nuevo directorio raíz /. Esto permite ejecutar los binarios, gestores de paquetes y herramientas de configuración nativos de ese sistema operativo en lugar de usar los del Live USB.

2. ¿Por qué es estrictamente necesario montar los directorios virtuales /dev, /proc y /sys dentro del directorio de rescate antes de entrar mediante chroot?

Porque dichos directorios no contienen ficheros estáticos en el disco duro, sino interfaces virtuales que el kernel expone para comunicarse con el hardware, los dispositivos de bloques y la información de los procesos en ejecución. Si no se enlazan mediante --bind, herramientas como grub-install no podrán acceder al disco físico ni interactuar con el hardware del equipo.

3. ¿Qué implicaciones tiene ejecutar el comando fsck sobre un sistema de archivos que se encuentra montado y activo en modo de lectura y escritura?

Es una práctica extremadamente peligrosa que puede provocar una corrupción catastrófica e irreversible de los datos. Mientras el sistema operativo está escribiendo y modificando bloques en el disco de forma activa, alterar la estructura de inodos y metadatos desde fuera con fsck creará inconsistencias graves, por lo que siempre debe ejecutarse con el sistema de archivos desmontado o en modo de solo lectura.

4. ¿Qué diferencia principal existe al reinstalar el gestor GRUB en un entorno tradicional basado en MBR frente a un sistema moderno basado en particionamiento UEFI?

En sistemas tradicionales MBR, GRUB se instala escribiendo directamente en los sectores de arranque sin formato del disco físico (primeros 512 bytes). En contraste, en sistemas modernos UEFI, no se escriben sectores de arranque físicos, sino que se copian ficheros binarios ejecutables de arranque dentro de una partición especial con formato FAT32 (partición EFI) y se registran las entradas de arranque en la memoria NVRAM de la placa base mediante la utilidad efibootmgr.