Objetivo:
Comprender y dominar los procedimientos críticos de recuperación de un sistema Linux que ha quedado completamente inoperativo tras una actualización fallida, aprendiendo a restaurar el gestor de arranque GRUB, reparar el sistema de archivos y verificar la integridad de los paquetes mediante un entorno Live USB de rescate.
Escenario:
- Herramientas: Medio de rescate Live USB, terminal Linux, comandos
chroot,grub-install,update-grub,fscky herramientas de gestión APT. - Conceptos analizados: Arquitectura de arranque UEFI/BIOS, reescrescritura del sector de arranque o partición EFI, consistencia de sistemas de archivos ext4 y reparación de dependencias rotas del sistema operativo.
- Proceso clave: Arranque externo, comprobación y reparación de bloques con
fsck, montaje y vinculación de directorios virtuales, cambio de raíz mediantechroot, reinstalación del gestor GRUB y reconfiguración del sistema de paquetes.
Escenario Real: Servidor bloqueado con pantalla negra tras actualizar el kernel
Un administrador aplicó una actualización masiva del sistema que incluyó el núcleo de Linux y el gestor de arranque. Durante el proceso, la actualización se interrumpió, dejando al servidor incapaz de arrancar y mostrando un error de GRUB o una pantalla en negro permanente. Como administrador de sistemas, debes utilizar un entorno de rescate externo para reparar el almacenamiento, reinstalar el gestor de arranque y devolver la operatividad al servidor.
chroot es la competencia definitiva para solventar este tipo de colapsos.NOTA: Para realizar esta práctica con total seguridad, asegúrate de utilizar una máquina virtual de prácticas o un medio Live USB compatible con el modo de arranque (BIOS o UEFI) de tu sistema dañado.
Instrucciones:
Fase 1: Arranque externo (Live USB) y verificación del almacenamiento:
- Arrancar el equipo utilizando un medio de rescate externo (Live USB) y abrir una terminal.
- Listar los discos y particiones para localizar la partición raíz (ej.
/dev/sda2) y la partición EFI si procede (ej./dev/sda1):lsblk - Asegurarse de que la partición raíz no está montada y ejecutar una comprobación y reparación de bloques dañados:
sudo fsck -f -y /dev/sda2
Fase 2: Montaje de particiones y vinculación de directorios virtuales:
- Crear el directorio temporal de rescate y montar en él la partición raíz reparada:
sudo mkdir -p /mnt/rescate sudo mount /dev/sda2 /mnt/rescate - Si el sistema utiliza arranque UEFI, montar la partición EFI en su ruta correspondiente dentro del directorio de rescate:
sudo mount /dev/sda1 /mnt/rescate/boot/efi - Vincular los sistemas de archivos virtuales del kernel para compartirlos con el entorno 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
Fase 3: Cambio de raíz (chroot) y reparación de paquetes rotos:
- Acceder al interior del sistema dañado mediante el comando de cambio de raíz:
sudo chroot /mnt/rescate - Copiar el fichero de resolución DNS si necesitas acceso a la red:
cp /etc/resolv.conf /etc/resolv.conf(dentro de chroot) - Forzar la configuración de paquetes pendientes y corregir posibles dependencias interrumpidas por la actualización fallida:
dpkg --configure -a apt --fix-broken install
Fase 4: Reinstalación y actualización del gestor de arranque (GRUB):
- Reinstalar GRUB en el disco principal (ej.
/dev/sdapara sistemas BIOS o el directorio EFI correspondiente para sistemas UEFI):grub-install /dev/sda # En entornos BIOS tradicionales # O bien: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck # En entornos UEFI - Actualizar la configuración de GRUB para detectar todos los núcleos y sistemas operativos instalados:
update-grub - Salir del entorno chroot, desmontar ordenadamente todos los recursos y reiniciar el equipo:
exit 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 medio externo, el equipo muestra el menú de GRUB con normalidad y permite seleccionar y arrancar el sistema operativo.
- Verificar que el sistema inicia sesión correctamente y que los paquetes del kernel se encuentran estables.
Posibles errores y resolución de problemas:
Si al ejecutar el comando grub-install dentro del entorno chroot el sistema devuelve un error crítico indicando que EFI variables are not supported on this system, significa que has iniciado el Live USB en modo BIOS tradicional mientras que el sistema operativo instalado utiliza particionado UEFI.
Solución: Reinicia el equipo físico, accede al menú de arranque de la BIOS/UEFI y asegúrate de iniciar el medio Live USB en modo UEFI antes de volver a montar las particiones y ejecutar el cambio de raíz (chroot).
Alternativa directa: Actualización rápida de GRUB desde un sistema operativo accesible
Si el sistema arranca pero no detecta un segundo sistema operativo o un nuevo núcleo instalado, puedes actualizar el archivo de configuración de GRUB de forma directa sin necesidad de entrar en modo rescate ejecutando:
sudo update-grub
Preguntas de reflexión:
- ¿Por qué es indispensable vincular los directorios virtuales del kernel (como
/dev,/procy/sys) antes de ejecutar el comandochrooten el sistema de rescate? - ¿Qué diferencia técnica existe a la hora de reinstalar GRUB entre un sistema con particionado tradicional MBR y un sistema moderno basado en UEFI?
- ¿Qué función cumple exactamente el comando
update-grubtras reinstalar el gestor de arranque en el disco duro? - ¿Por qué una interrupción abrupta durante la actualización del núcleo de Linux suele invalidar el arranque del equipo?
Haz clic aquí para ver las soluciones y explicaciones
1. ¿Por qué es indispensable vincular los directorios virtuales del kernel (como /dev, /proc y /sys) antes de ejecutar el comando chroot en el sistema de rescate?
Porque el entorno chroot cambia la raíz lógica del sistema, pero los comandos avanzados de reparación (como grub-install o el gestor APT) necesitan interactuar directamente con los dispositivos de hardware (/dev), la información del núcleo en ejecución (/proc) y los parámetros del sistema (/sys). Sin estos puntos montados mediante bind, los programas no podrán acceder al disco físico ni configurar el cargador.
2. ¿Qué diferencia técnica existe a la hora de reinstalar GRUB entre un sistema con particionado tradicional MBR y un sistema moderno basado en UEFI?
En sistemas MBR tradicionales, GRUB se instala directamente en el sector de arranque maestro (MBR) o en los primeros bloques de sectores ocultos del disco duro físico (ej. /dev/sda). En cambio, en sistemas UEFI no se escribe código en el sector de arranque, sino que se copian los ficheros binarios correspondientes dentro de la partición EFI montada en /boot/efi y se registra la ruta de arranque en la NVRAM de la placa base mediante variables UEFI.
3. ¿Qué función cumple exactamente el comando update-grub tras reinstalar el gestor de arranque en el disco duro?
Escanea el directorio /boot en busca de las imágenes de núcleos de Linux y ficheros initramfs disponibles, y genera un fichero de configuración actualizado (/boot/grub/grub.cfg), asegurando que el menú de arranque refleje correctamente las versiones vigentes del sistema operativo.
4. ¿Por qué una interrupción abrupta durante la actualización del núcleo de Linux suele invalidar el arranque del equipo?
Porque durante la actualización de un kernel se descargan los ficheros de imagen, se generan los discos virtuales temporales (initramfs) y se actualizan los enlaces del gestor de arranque de forma secuencial. Si el proceso se corta a mitad, los ficheros de arranque pueden quedar incompletos, corruptos o desincronizados, impidiendo que GRUB localice y cargue correctamente el núcleo del sistema operativo.