Restaurar GRUB2 tras un cambio UEFI/BIOS y la pérdida de la configuración del cargador de arranque

La palabra clave focal „RESTaurar GRUB2“ es central cuando un sistema deja de arrancar tras un cambio de UEFI/BIOS o por pérdida de la configuración del cargador de arranque. En este artículo, administradores, ingenieros de sistemas y operadores encontrarán una guía práctica y paso a paso para el diagnóstico, la reparación y la verificación —incluyendo causas típicas, riesgos y estrategias de retroceso.

¿Por qué ocurre la pérdida de arranque? Causas explicadas brevemente

Antes de entrar en la práctica: conviene conocer las causas frecuentes para que la reparación sea dirigida. Las tres categorías principales son cambios de firmware, problemas de particionado/ESP y errores de initramfs/descifrado.

1. Cambio de modo UEFI/BIOS

UEFI (Unified Extensible Firmware Interface) es la interfaz de firmware moderna; BIOS o Legacy designa el procedimiento de arranque más antiguo basado en MBR. Un cambio de UEFI a Legacy o viceversa puede invalidar las entradas de arranque en el firmware (NVRAM), porque los sistemas UEFI dependen de una EFI System Partition (ESP) con archivos .efi, mientras que el GRUB en modo Legacy espera el MBR o una partición de arranque BIOS.

2. Partición EFI System (ESP) dañada o incorrecta

La ESP es una pequeña partición FAT32 con el tipo EFI System (GPT ef00). Si ha sido eliminada, sobrescrita con Windows o montada de forma incorrecta, faltarán los binarios GRUB‑EFI (/EFI/<Vendor>/grubx64.efi) y el sistema no arrancará.

3. Initramfs, root cifrado o incompatibilidad de kernel

GRUB carga el kernel y el initramfs (Initial RAM Filesystem). Si el initramfs no contiene los módulos adecuados para LVM/LUKS o los sistemas de archivos, el arranque falla después de GRUB. Del mismo modo, una actualización del kernel sin regenerar el initramfs en volúmenes root cifrados conduce a sistemas no descifrables.

Preparación: requisitos, riesgos y herramientas necesarias

Antes de intervenir, verifique: ¿dispone de un entorno de rescate (Live‑USB), acceso a la configuración del firmware, copias de seguridad de la ESP y, si procede, de los encabezados LUKS? Herramientas: una distribución Live actual con grub-install/grub‑efi, efibootmgr, lsblk, blkid, parted o gdisk, mount, chroot, y para entornos RHEL/CentOS, dracut.

Riesgos importantes:

• Sobrescribir adicionalmente la ESP, lo que puede inutilizar otros sistemas operativos (Windows).
• Ausencia de copias de seguridad del encabezado LUKS en root cifrados — entonces la RESTauración es considerablemente más compleja.
• Seleccionar el dispositivo de destino incorrecto al ejecutar grub-install (p. ej. una partición en lugar del disco completo) puede dañar el dispositivo de arranque.

Diagnóstico: comprobar el estado del sistema (Live‑USB)

Arranque desde un Live‑USB (preferiblemente la misma arquitectura: x86_64). Monte los discos en modo solo lectura para el primer análisis.

Comandos de comprobación importantes y su significado

Resumen de particiones y dispositivos:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,LABEL

Tipos de partición y códigos GPT:

sudo parted -l

Marcado EFI/ESP y UUID:

sudo blkid | grep -i efi
# oder gezielt
sudo lsblk -f /dev/nvme0n1p1

Entradas EFI en el firmware (NVRAM):

sudo efibootmgr -v

Si efibootmgr falla: es posible que el firmware se haya iniciado en modo BIOS/Legacy o que efivarfs no esté montado. Compruebe /sys/firmware/efi/exists — si ese directorio existe, el entorno Live ya se está ejecutando en modo UEFI.

[ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy/BIOS mode"

Escenarios de RESTauración: paso a paso

Diferenciamos los tres casos prácticos más comunes y ejecutamos los pasos necesarios para cada uno: (A) UEFI: reinstalar GRUB‑EFI, (B) BIOS/Legacy: instalar GRUB en el MBR, (C) cambio UEFI↔Legacy o NVRAM defectuoso: fallback removable.

A. UEFI: reinstalar GRUB2 (caso estándar)

Objetivo: escribir los binarios EFI en la ESP, crear o corregir la entrada NVRAM, generar grub.cfg.

1. Active el entorno live en modo UEFI (importante para efibootmgr).
2. Monte root, /boot y la ESP. Reemplace /dev/sdXn por sus dispositivos.

sudo mount /dev/sdX2 /mnt            # root-Partition
sudo mount /dev/sdX1 /mnt/boot/efi    # EFI System Partition, FAT32
# Falls /boot eine eigene Partition hat:
# sudo mount /dev/sdX3 /mnt/boot
# Bind-Mounts für chroot
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run

Chroot para que grub-install se ejecute en el contexto del sistema (importante para rutas específicas de la distribución).

sudo chroot /mnt /bin/bash
# innerhalb des chroots prüfen
mount | grep efi

Instale GRUB para UEFI:

# Beispiel für x86_64-UEFI auf Debian/Ubuntu/Fedora
grub-install --target=x86_64-efi --efi-directory=/boot/efi 
  --bootloader-id=GRUB --recheck --no-nvram
# --no-nvram verhindert Änderungen am NVRAM; nutzen Sie es nur bei Bedarf

Por qué funciona: grub-install genera el binario .efi en la ESP (p. ej. /boot/efi/EFI/GRUB/grubx64.efi) y opcionalmente crea una entrada NVRAM. Puede fallar si el paquete grub‑efi no está instalado o la arquitectura no coincide (i386 frente a x86_64).

Genere la configuración:

# Debian/Ubuntu
update-grub
# RedHat/CentOS
grub2-mkconfig -o /boot/grub2/grub.cfg

Si efibootmgr no puede escribir la entrada de arranque, coloque el archivo de emergencia como „removable“ (bootx64.efi):

cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
# BIOS/UEFI-Fallback für viele Firmware-Implementierungen

Salga del chroot y desmonte de forma limpia:

exit
sudo umount -l /mnt/dev /mnt/proc /mnt/sys /mnt/run
sudo umount /mnt/boot/efi
sudo umount /mnt

B. Legacy BIOS: GRUB en MBR installieren

Si el sistema debe arrancar en modo Legacy (p. ej. hardware antigua), debe escribir GRUB clásicamente en el MBR.

# Vorbereitungen wie oben: mount /mnt, chroot
# Install GRUB to MBR (example /dev/sda)
grub-install --target=i386-pc /dev/sda --recheck
grub-mkconfig -o /boot/grub/grub.cfg

Tenga en cuenta: las tablas de particiones GPT modernas pueden requerir una pequeña partición BIOS‑Boot (tipo ef02 en gdisk) para GRUB‑Stage2. Sin esta partición, grub-install fallará en discos GPT si se desea arrancar en modo BIOS.

C. Cambio UEFI↔Legacy, NVRAM defectuoso o menú de firmware limitado

Algunas firmwares no permiten ya entradas NVRAM (demasiadas o defectuosas). En esos casos, la ruta de arranque removable es adecuada: el binario EFI instalado en /EFI/BOOT/BOOTX64.EFI. Es robusto, pero puede sobrescribir los cargadores de arranque de otros sistemas operativos.

# innerhalb des chroot
mkdir -p /boot/efi/EFI/BOOT
cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

Casos especiales y resolución de problemas

Restaurar GRUB2 con root cifrado (LUKS)

En caso de root cifrado con LUKS (LUKS es el Linux Unified Key Setup) debe abrir el volumen LUKS desde el chroot para que /mnt contenga realmente el root correcto. Importante: ¿Ha respaldado el header de LUKS? Sin el header, la RESTauración es muy laboriosa.

# LUKS-Container öffnen (im Live-System, vor dem Mounten)
sudo cryptsetup luksOpen /dev/sdX2 cryptroot
sudo mount /dev/mapper/cryptroot /mnt

Después de la instalación de grub, regenere el initramfs (Initramfs es el sistema de archivos en RAM inicial que proporciona los módulos para LVM/LUKS):

# Debian/Ubuntu
update-initramfs -u -k all
# RedHat/CentOS
dracut -f

Si está instalada una combinación incorrecta de kernel e initramfs (p. ej. un kernel antiguo), el arranque tras GRUB puede fallar en la fase de initramfs.

Error: grub-install informa „cannot find EFI directory“ o „secure boot“

Causas y soluciones:

• La partición EFI no es FAT32 o no está montada: móntela en /boot/efi.
• Secure Boot activo: o bien desactive temporalmente Secure Boot o utilice binarios firmados (shim). Shim es un pequeño programa firmado que puede cargar grubx64.efi no firmado si está habilitado en el MOK‑Store (Machine Owner Key).
• Paquete faltante: en Debian/Ubuntu necesita grub‑efi‑amd64 y efibootmgr; en sistemas basados en RHEL, grub2‑efi‑x64.

efibootmgr no escribe en NVRAM o las entradas desaparecen

Muchas causas: errores de firmware, protección contra escritura del NVRAM o saturación. Compruebe si el firmware elimina entradas. Como alternativa: use la ruta removable o ajuste manualmente el orden de arranque del firmware en la configuración UEFI.

Validación: Así comprueba si la RESTauración fue exitosa

Reinicie el sistema y utilice la selección de arranque del firmware para probar la nueva entrada. Para verificar en el sistema en ejecución:

# prüft ob System im UEFI-Modus gebootet hat
[ -d /sys/firmware/efi ] && echo "UEFI boot" || echo "Legacy boot"
# efibootmgr zeigt aktive Eintraege
sudo efibootmgr -v
# prüft gültige grub.cfg
sudo test -f /boot/grub/grub.cfg && echo "grub.cfg vorhanden"

Monitoree los mensajes del sistema en el primer arranque (journalctl -b) y atienda a pasos que fallen al descifrar el root o al montar volúmenes LVM.

Lista de verificación práctica: Playbook rápido de recuperación

1. Prepare un Live‑USB con la arquitectura adecuada (tenga en cuenta el modo UEFI/BIOS).
2. Backups importantes: snapshot de la ESP, header de LUKS, y la configuración de Grub.
3. Diagnóstico: lsblk, parted, blkid, efibootmgr; compruebe si la ESP está presente y es FAT32.
4. Montar, chroot e instalación de grub según el modo objetivo (UEFI/BIOS).
5. Regenerar initramfs tras cambios en LUKS/LVM/kernel.
6. Si efibootmgr no funciona: escriba la EFI removable (BOOTX64.EFI).
7. Reiniciar y validar: menú de arranque del firmware, journalctl -b, comprobar estado de LVM/LUKS.

Errores típicos y cómo evitarlos

Error 1: Montaje de la partición equivocada (Windows ESP en lugar de Linux ESP). Evite esto usando UUIDs en lugar de nombres de dispositivo (blkid proporciona UUIDs). Error 2: Arquitectura incorrecta del archivo .efi (i386 vs x86_64). Evite: utilice la imagen Live de la arquitectura objetivo. Error 3: NVRAM llena o inestable. Evite: tenga preparado un fallback removable.

Estrategia de rollback y prevención

Realice una copia de seguridad antes de cualquier cambio:

# ESP als Image sichern
sudo dd if=/dev/sdX1 of=esp-backup-$(date +%F).img bs=4M status=progress
# LUKS-Header sichern
sudo cryptsetup luksHeaderBackup /dev/sdX2 --header-backup-file luks-header-$(date +%F).bin

Acceso de emergencia: Mantenga una consola de rescate y una opción de arranque alternativa (p. ej., network boot, PXE, o KVM física) disponible. Documente las salidas originales de efibootmgr para poder reconstruir las entradas si es necesario.

Cuándo no ayuda reinstalar el cargador de arranque

Hay casos en que la recuperación de GRUB por sí sola no es suficiente: fallos de hardware en el medio de arranque, cabeceras LUKS ausentes, o sistema de archivos raíz corrupto. Si existen errores de disco, ejecute primero pruebas SMART y comprobaciones del sistema de archivos; solo cuando la integridad física esté garantizada, proceda con las reparaciones del cargador de arranque.

# SMART-Test
sudo smartctl -a /dev/sda
# Dateisystemcheck ext4 (nur ungemountet)
sudo fsck.ext4 -f /dev/sdX2

Breves notas sobre diferencias entre distribuciones

Las distribuciones nombran las rutas de forma diferente: Debian/Ubuntu usa /boot/grub, RedHat/CentOS /boot/grub2 y comandos distintos para generar la configuración (update-grub vs grub2-mkconfig). Al trabajar en un chroot, preste atención a las rutas específicas de la distro y a los paquetes instalados.

Restaurar GRUB2: script de recuperación automatizado y auditoría

En entornos de mayor envergadura se recomienda un script de recuperación verificable e idempotente que solo realice diagnóstico y preparación de montajes — la instalación real de grub debe ejecutarse manualmente o liberarse mediante ticketing. El ejemplo siguiente muestra un bloque de comprobación seguro que detecta la ESP y el modo y genera mensajes para el ticketing.

#!/bin/bash
set -euo pipefail
# Simple pre-checks before manual recovery actions
if [ -d /sys/firmware/efi ]; then
  echo "System already booted in UEFI mode"
else
  echo "Live-Umgebung ist Legacy/BIOS-mode"
fi
ESP=$(blkid -t PARTLABEL="EFI System" -o device || true)
if [ -z "$ESP" ]; then
  echo "Keine ESP gefunden: blkid output:"; blkid | sed -n '1,200p'
  exit 2
fi
UUID=$(blkid -s UUID -o value "$ESP")
echo "ESP device: $ESP UUID: $UUID"
# create a small audit file for ticketing
mkdir -p /var/log/grub-recovery-audit
echo "$(date -Iseconds) - ESP:$ESP UUID:$UUID UEFI:$( [ -d /sys/firmware/efi ] && echo yes || echo no)" 
  >> /var/log/grub-recovery-audit/recovery.log

Por qué es útil: el script no modifica el sistema, genera datos de diagnóstico reproducibles y obliga a los administradores a autorizar manualmente los sensibles pasos de instalación de grub.

Secure Boot, shim y flujo de trabajo MOK

Si Secure Boot está activo, grub-efi solo puede ejecutarse si los binarios .efi están firmados o se utiliza shim. Shim es un pequeño cargador de arranque que la firmware reconoce y que posteriormente carga binarios GRUB sin firmar una vez que se ha registrado un Machine Owner Key (MOK) en el almacén de firmware.

# MOK importieren (im installierten System oder chroot)
sudo mokutil --import /path/to/public_key.der
# reboot and enroll the key in the MOK manager during boot

Si necesita firmar los binarios usted mismo, utilice sbsign o sign-file (Kernel/GRUB). Tenga en cuenta: un flujo de trabajo MOK defectuoso puede dejar el sistema sin posibilidad de arrancar; pruebe los cambios siempre primero en una VM.

Pruebas y despliegue en entornos empresariales

Establezca líneas de prueba: una ejecución de validación automatizada con qemu/kvm comprueba si una imagen ESP recién generada y un grubx64.efi arrancan en la simulación de firmware. Esto reduce el riesgo durante el despliegue en varios servidores.

# Beispiel: schnelles Boot-Test-Image mit qemu
qemu-system-x86_64 -m 1024 -bios /usr/share/ovmf/OVMF.fd -hda test-disk.img -boot d

En instalaciones grandes, los cambios de recuperación deberían gestionarse mediante gestión de configuración y control de cambios (p. ej., Ansible Playbooks que solo ejecuten comprobaciones de validación). Mantenga una ventana de reversión definida por si las diferencias de firmware tras la actualización provocan efectos imprevistos.

Monitorización, alertas y prevención

Automatice las alertas tempranas: supervise el último tiempo de arranque exitoso con un agente, verifique tras las actualizaciones del kernel si la regeneración del initramfs fue exitosa y valide las entradas de arranque después de actualizaciones de firmware. Un repositorio con snapshots del ESP facilita la recuperación rápida.

Conclusión: sistemático, seguro y documentado

Restaurar GRUB2 tiene éxito de forma fiable si procede de manera estructurada: primero diagnóstico, luego reparación dirigida para UEFI o BIOS, regeneración del initramfs en root cifrado y, finalmente, validación. Asegure snapshots del ESP y los encabezados LUKS antes de cualquier intervención. Para entornos productivos se recomienda un playbook de recuperación definido, automatización de pruebas y comprobaciones periódicas de la política de firmware.

Si elabora documentación interna: registre las UUID de los dispositivos con precisión, la versión de firmware y el orden exacto de los pasos realizados. Esta información ahorra tiempo en incidentes recurrentes y ayuda en el análisis de causa raíz.

Enlaces internos adicionales (ejemplos): Enlace aquí a las directrices sobre copias de seguridad de discos cifrados, políticas de actualización del kernel o el playbook de recuperación ante desastres de su organización, para garantizar un flujo operativo completo.

Para este tema también son importantes Restauración del cargador de arranque UEFI y Guía de grub-install. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que centrarse en el día a día.