Qué significa realmente grub rescue>

GRUB tiene múltiples “estados”. El normal lee su configuración, muestra un menú (o arranca de inmediato) y entrega el control al kernel.
grub rescue> es la consola de emergencia reducida. Estás aquí porque la imagen core de GRUB se cargó, pero no puede cargar
lo que necesita a continuación—normalmente módulos y configuración—porque no puede encontrar el sistema de archivos o la ruta que espera.

La falla casi siempre encaja en una de estas categorías:

• Referencia de disco/partición incorrecta (cambió el orden de dispositivos, renumeración NVMe, cambió el orden de arranque en BIOS).
• Falta o movió /boot (redimensionado de partición, partición eliminada, reinstalación, “limpieza”).
• Archivos de GRUB dañados (actualización parcial, corrupción de disco, montaje incorrecto durante una reinstalación).
• Discordancia UEFI vs legacy (se instaló de una forma y ahora el firmware intenta la otra).
• Complejidad por cifrado/LVM/RAID (GRUB no puede leer el volumen sin los módulos o la disposición correctos).

Tu suposición más segura: el sistema operativo sigue en disco, pero los punteros del cargador de arranque están obsoletos. Trata esto como
un mapa roto, no como una ciudad incendiada.

Una verdad operativa: cuando la gente entra en pánico aquí, tiende a empezar a “arreglar” particiones. Ahí es donde conviertes un problema
de arranque en un problema de recuperación de datos. No lo hagas.

Guía de diagnóstico rápido (comprueba primero/segundo/tercero)

Primero: identifica qué tipo de arranque estás usando (UEFI o legacy BIOS)

Esto determina el objetivo correcto de reparación. En UEFI reparas la partición del sistema EFI (ESP) y la entrada NVRAM.
En legacy BIOS reparas el MBR / área de arranque del BIOS y la instalación de GRUB en el disco.

• Si puedes entrar en la configuración del firmware: ¿lista una opción de arranque “ubuntu” como UEFI? Si sí, probablemente es instalación UEFI.
• Desde un USB live: la presencia de /sys/firmware/efi significa que el entorno live arrancó en modo UEFI.

Segundo: encuentra el sistema de archivos raíz real y dónde vive /boot

Tus comandos de reparación deben apuntar al sistema Ubuntu instalado real. Montar mal = reparar con éxito lo equivocado.
Identifica particiones por UUID y tipo de sistema de archivos, no por “normalmente es sda2”.

Tercero: confirma si esto es un problema de punteros o un problema de disco

Si el disco está fallando, reinstalar GRUB es como pintar un barco que se está hundiendo. Revisa SMART por problemas evidentes y escanea
los logs del kernel desde el entorno live por errores de E/S. Si ves fallos de lectura, detente y prioriza los datos.

Fork de decisión (rápido)

• Ves tus particiones Linux y las puedes montar: probablemente reinstalar GRUB / regenerar la configuración lo arreglará.
• No puedes montar el sistema de archivos: primero reparaciones de sistema de archivos y/o diagnósticos de almacenamiento.
• Tienes LUKS + LVM + RAID: abre y ensambla las capas con cuidado, luego reinstala GRUB desde chroot.

Datos interesantes y pequeña historia (porque importa)

1. GRUB significa “GRand Unified Bootloader”, diseñado originalmente para unificar el arranque entre distintos SO y sistemas de archivos cuando aquello era un lío.
2. GRUB2 no es “GRUB versión 2” en el sentido suave; fue una reescritura mayor con semánticas de configuración y carga modular diferentes.
3. La “imagen core” es pequeña por diseño—es lo que carga primero el firmware, y trata de recuperar módulos desde disco. Cuando esa recuperación falla, caes en modo rescue.
4. UEFI cambió la historia del arranque: en lugar de código de arranque en el MBR, el firmware carga un ejecutable EFI desde la ESP. Por eso los pasos de reinstalación difieren.
5. El valor por defecto de Ubuntu ahora asume UEFI en hardware moderno, pero muchas infraestructuras siguen usando legacy BIOS por compatibilidad o inercia.
6. La inestabilidad en nombres de disco es real: los dispositivos NVMe pueden renumerarse según el orden de enumeración; controladores USB/SATA pueden reordenar. Existen los UUID porque a los humanos no les gustan las sorpresas.
7. Históricamente, GRUB fue apreciado por su conocimiento de sistemas de archivos frente a cargadores más antiguos que no podían leer ext* sin ayuda.
8. GRUB moderno puede leer LUKS1 en algunas configuraciones, pero el cifrado de disco completo con defaults nuevos (LUKS2, ajustes PBKDF) puede complicar el arranque temprano.
9. “Unknown filesystem” en GRUB a menudo significa “módulo faltante”, no necesariamente que el sistema de archivos haya desaparecido—GRUB es modular y el modo rescue carga menos módulos.

Una idea para tener en la cabeza (y en tu checklist de incidentes): la esperanza no es una estrategia. — atribuido en círculos de operaciones a John C. Maxwell.
Sea cual sea el origen, es exacto: mide primero, luego cambia cosas.

Tareas prácticas: comandos, salidas, decisiones (lo sustancioso)

Estas tareas asumen que trabajas desde un USB live de Ubuntu (la misma versión mayor ayuda, pero no es obligatorio), y tu objetivo es
el cambio mínimo. Cada tarea incluye: comando, qué significa la salida y qué decides después.

Task 1: Confirma si el entorno live arrancó en UEFI

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"
UEFI mode

Significado: Si ves “UEFI mode,” debes reparar la ruta de arranque EFI y usar grub-install --target=x86_64-efi.
Si “Legacy BIOS mode,” instalas GRUB en el MBR del disco con --target=i386-pc.
Decisión: Si esto no coincide con cómo se instaló el SO, reinicia el USB live y selecciona el modo de arranque correcto en el firmware.

Task 2: Enumera dispositivos de bloque y sistemas de archivos

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS
NAME         SIZE TYPE FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
nvme0n1    953.9G disk
├─nvme0n1p1   512M part vfat   FAT32       3C21-1A7B
├─nvme0n1p2     2G part ext4   1.0         2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b
└─nvme0n1p3 951.4G part crypto_LUKS 2     9d8d5b6a-8f1c-4a44-9b3c-3b2c9a1f0caa

Significado: Buscas: ESP (vfat ~100–1024MB), quizá un /boot separado (ext4),
y el filesystem raíz (ext4/xfs/btrfs) o un contenedor cifrado.
Decisión: Anota los nombres de dispositivos y UUIDs. No empieces a “arreglar” hasta saber cuál partición es cuál.

Task 3: Si está cifrado, abre LUKS correctamente (no improvises)

cr0x@server:~$ sudo cryptsetup luksOpen /dev/nvme0n1p3 cryptroot
Enter passphrase for /dev/nvme0n1p3:

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS /dev/mapper/cryptroot
NAME      TYPE FSTYPE      MOUNTPOINTS
cryptroot crypt LVM2_member

Significado: El dispositivo descifrado es un PV de LVM (diseño común en Ubuntu).
Decisión: Activa LVM a continuación. Si cryptsetup falla, detente y verifica que estás en la partición correcta y que el disco está sano.

Task 4: Activa volúmenes LVM y encuentra la raíz

cr0x@server:~$ sudo vgscan --mknodes
  Found volume group "ubuntu-vg" using metadata type lvm2

cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "ubuntu-vg" now active

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS | grep -E "ubuntu--vg|lv|root|swap" || true
├─ubuntu--vg-root  200G ext4
└─ubuntu--vg-swap    8G swap

Significado: Ahora tienes visibles los volúmenes lógicos. La raíz probablemente sea ubuntu--vg-root.
Decisión: Monta la raíz, luego monta /boot y la ESP según sea necesario.

Task 5: Monta el sistema instalado correctamente (root, boot, ESP)

cr0x@server:~$ sudo mount /dev/mapper/ubuntu--vg-root /mnt

cr0x@server:~$ sudo mkdir -p /mnt/boot /mnt/boot/efi

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot

cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi

cr0x@server:~$ findmnt -R /mnt
TARGET         SOURCE                     FSTYPE OPTIONS
/mnt           /dev/mapper/ubuntu--vg-root ext4   rw,relatime
/mnt/boot      /dev/nvme0n1p2             ext4   rw,relatime
/mnt/boot/efi  /dev/nvme0n1p1             vfat   rw,relatime,fmask=0022,dmask=0022

Significado: findmnt es tu comprobación de cordura. Si montas cosas equivocadas, la reparación puede “tener éxito”
y aún así no arrancar.
Decisión: Si falta /mnt/boot/efi en una instalación UEFI, no estás listo para reinstalar GRUB.

Task 6: Revisa problemas de disco o sistema de archivos antes de escribir datos de arranque

cr0x@server:~$ sudo dmesg -T | tail -n 30
[Mon Dec 30 09:14:12 2025] nvme nvme0: I/O 17 QID 6 timeout, aborting
[Mon Dec 30 09:14:12 2025] blk_update_request: I/O error, dev nvme0n1, sector 123456789 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Significado: Errores de lectura o timeouts significan que deberías pausar. La reparación de arranque escribe datos; si el disco falla estás
apostando con la recuperación.
Decisión: Si ves errores de E/S, prioriza imágenes/respaldos. Si los logs están limpios, procede.

Task 7: Identifica cómo el sistema instalado espera montar discos (comprobación de UUID)

cr0x@server:~$ sudo cat /mnt/etc/fstab
UUID=2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b /boot ext4 defaults 0 2
UUID=3C21-1A7B /boot/efi vfat umask=0077 0 1
/dev/mapper/ubuntu--vg-root / ext4 defaults 0 1

Significado: Si fstab referencia UUIDs que ya no existen, el arranque puede fallar más tarde incluso después de arreglar GRUB.
Decisión: Si hay mismatches de UUID, corrígelos ahora (con cuidado). Pero no inventes UUIDs—usa blkid.

Task 8: Observa la configuración de GRUB instalada e identifica el target

cr0x@server:~$ sudo ls -l /mnt/boot/grub
total 12
-rw-r--r-- 1 root root  144 Dec 29 18:12 grub.cfg
drwxr-xr-x 2 root root 4096 Dec 29 18:12 x86_64-efi
drwxr-xr-x 2 root root 4096 Dec 29 18:12 fonts

Significado: La presencia de x86_64-efi sugiere una instalación UEFI. Las instalaciones legacy típicamente tendrán i386-pc.
Decisión: Ajusta tu grub-install --target a esta realidad, no a tu suposición.

Task 9: Bind-mount de directorios del sistema y chroot (la forma correcta)

cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done

cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/#

Significado: Ahora estás operando “dentro” del sistema instalado, que es donde las herramientas de GRUB esperan ejecutarse.
Decisión: Si chroot falla o faltan herramientas, puede que hayas montado la raíz equivocada o la instalación esté incompleta.

Task 10: Reinstalar GRUB en UEFI (ruta preferida para Ubuntu 24.04 en hardware moderno)

cr0x@server:~$ grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

Significado: El binario EFI de GRUB y archivos de soporte se instalaron en la ESP, y las entradas NVRAM pueden actualizarse.
Decisión: Si esto da error con “cannot find EFI directory,” tu ESP no está montada en /boot/efi.
Corrige los montajes y vuelve a ejecutar.

Task 11: Reinstalar GRUB en legacy BIOS (cuando realmente estás en modo BIOS)

cr0x@server:~$ grub-install --target=i386-pc --recheck /dev/nvme0n1
Installing for i386-pc platform.
Installation finished. No error reported.

Significado: El código de arranque de GRUB se escribió en el área de arranque del disco. Esto no apunta a una partición como /dev/nvme0n1p2.
Decisión: Si no estás seguro de qué disco arranca el firmware, detente y confirma. Instalar en el disco equivocado es un auto-sabotaje clásico.

Task 12: Regenerar configuración de GRUB e initramfs (porque las configuraciones obsoletas son un villano recurrente)

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Significado: Esto reconstruye initramfs (importante para LUKS/LVM/RAID) y asegura que las entradas del menú de GRUB apunten a kernels reales.
Decisión: Si update-grub no encuentra kernels, tu montaje de /boot es incorrecto o está vacío.

Task 13: Verifica entradas de arranque UEFI (cuando el firmware “olvida” ubuntu)

cr0x@server:~$ efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* UEFI: Built-in EFI Shell
Boot0002* ubuntu HD(1,GPT,2f3a...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Significado: Tienes una entrada ubuntu apuntando a shimx64.efi (común cuando Secure Boot está involucrado).
Decisión: Si no existe entrada ubuntu, créala o reinstala GRUB asegurando que --bootloader-id esté establecido.

Task 14: Si estás atascado en grub rescue> sin USB live, haz un arranque temporal

Esto no es “la solución.” Es “llévame a un sistema real para que pueda arreglarlo correctamente.” En grub rescue> tienes comandos limitados.
Tu objetivo es encontrar la partición con /boot/grub, establecer root y prefix, cargar normal y arrancar.

cr0x@server:~$ ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)

cr0x@server:~$ ls (hd0,gpt2)/
lost+found/ boot/ vmlinuz initrd.img

cr0x@server:~$ set root=(hd0,gpt2)

cr0x@server:~$ set prefix=(hd0,gpt2)/boot/grub

cr0x@server:~$ insmod normal

cr0x@server:~$ normal

Significado: Señalaste manualmente a GRUB el lugar correcto. Si funciona, obtendrás el menú normal de GRUB.
Decisión: Arranca el sistema y luego reinstala GRUB de forma permanente desde Ubuntu (o desde un USB live) para que esto no vuelva a ocurrir.

Task 15: Confirma que el sistema instalado ve los discos de forma consistente (UUIDs y by-id)

cr0x@server:~$ ls -l /dev/disk/by-uuid | head
total 0
lrwxrwxrwx 1 root root 15 Dec 30 09:22 2b3f3d4a-2c5b-4a79-a51e-4f2f2b0d6c4b -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Dec 30 09:22 3C21-1A7B -> ../../nvme0n1p1

Significado: Existen mapeos UUID. Esto es en lo que confía el arranque estable.
Decisión: Si tu configuración de GRUB o fstab usa nombres de dispositivo crudos (p. ej., /dev/nvme0n1p2), considera cambiar a UUIDs.

Task 16: Sal con cuidado y reinicia (evita dejar montajes)

cr0x@server:~$ exit
exit

cr0x@server:~$ for i in /run /sys /proc /dev/pts /dev; do sudo umount -l /mnt$i; done

cr0x@server:~$ sudo umount -l /mnt/boot/efi /mnt/boot /mnt

cr0x@server:~$ sudo reboot

Significado: Desmontaste en orden inverso. Esto reduce la posibilidad de estados sucios, especialmente con capas LUKS/LVM.
Decisión: Si al reiniciar aún cae en rescue, pasa a la tabla de errores y verifica modo de arranque + objetivo de disco correcto.

Chiste #1: GRUB rescue es como una alerta de pager—no la recibes porque todo está bien, pero sí significa que el sistema todavía te está hablando.

Tres microhistorias corporativas (cómo falla esto en la vida real)

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa tenía una pequeña flota de servidores Ubuntu en hardware idéntico. El modelo mental era reconfortante: mismo modelo, mismas opciones de BIOS,
mismo diseño de disco, todo igual. Alguien reemplazó un NVMe fallido en un nodo, lo reimaginó y siguió con su día.

El siguiente reinicio cayó en grub rescue>. El responsable supuso que “era lo mismo que la vez anterior” y ejecutó inmediatamente
un grub-install en modo BIOS desde un USB live. “Funcionó” en el sentido de que escribió código de arranque.
No funcionó en el sentido de que el servidor seguía sin arrancar.

El problema real: ese nodo estaba instalado como UEFI, pero el USB live había arrancado en modo legacy, y el firmware había cambiado silenciosamente
su orden de arranque tras el reemplazo. Estaban reparando la capa equivocada. Unos cuantos ciclos de esto y tenían un disco
con artefactos de ambos estilos de arranque, además de una lista de entradas del firmware confundida.

La solución fue aburrida: arrancar el USB live en modo UEFI, montar la ESP en /boot/efi, reinstalar GRUB con el target UEFI,
y luego usar efibootmgr para confirmar una entrada de arranque sensata. La lección no fue “UEFI es difícil.” La lección fue: el entorno
de reparación debe coincidir con el modo de arranque instalado, o tu “arreglo” es solo escribir código de arranque aleatorio con confianza.

Microhistoria 2: La optimización que salió mal

Otra organización tenía la costumbre de optimizar micro layouts de disco. Alguien decidió que particiones separadas de /boot eran “legado”
y consolidó /boot dentro del filesystem raíz durante una renovación de almacenamiento. También habilitaron cifrado de disco completo
con defaults más modernos. Parecía limpio. Menos particiones, menos montajes, menos cosas que fallar. ¿Verdad?

Entonces llegó una actualización y un subconjunto de máquinas empezó a caer en GRUB rescue. El problema subyacente no fue la actualización del kernel.
Fue que el entorno temprano del cargador de arranque se volvió menos capaz: GRUB no podía leer de forma fiable el layout de raíz cifrado
en esa configuración, y no había un /boot sin cifrar que actuara como zona de preparación simple.

La primera reacción del equipo fue tratarlo como “GRUB está roto.” Reinstalaron GRUB, regeneraron configuraciones, incluso recrearon
entradas EFI. Algunos nodos se recuperaron, otros no, y la variación fue lo peor—porque la variación genera escalada.

La solución a largo plazo fue estandarizar: mantener un pequeño /boot sin cifrar (y por supuesto una ESP para UEFI) para esta clase
de servidores, documentado y probado. La “optimización” quitó un margen de seguridad. En sistemas de producción, los márgenes de seguridad no son desorden.
Son tu tiempo libre futuro.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un tercer equipo tenía una costumbre que sonaba tediosa: cada vez que tocaban particiones o reemplazaban un disco, capturaban una línea base:
lsblk -f, blkid, efibootmgr -v (en UEFI), además de una copia de /etc/fstab y
/boot/grub/grub.cfg. Lo almacenaban junto al registro de cambio. No era glamoroso. Muy efectivo.

Cuando un servidor cayó en grub rescue> tras una ventana de mantenimiento, el responsable no tuvo que adivinar si la caja era
UEFI o legacy, si /boot era separado, o qué UUID pertenecía a la ESP. Compararon la salida actual con la línea base
y vieron de inmediato que el UUID de la ESP había cambiado tras un intercambio de disco, pero fstab aún referenciaba el antiguo.

La reparación llevó minutos: montar la ESP correcta, actualizar fstab para que coincida, reinstalar GRUB, regenerar la configuración, reiniciar.
Ninguna herramienta de particionado se abrió. Ninguna heroicidad nocturna. Nadie aprendió una nueva habilidad de recuperación de archivos.

Chiste #2: La mejor respuesta a incidentes es aquella en la que mayormente ejecutas cat y miras con ligera decepción.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: error: unknown filesystem en GRUB rescue

• Causa raíz: GRUB apunta a la partición equivocada, o no puede cargar el módulo del sistema de archivos en modo rescue.
• Solución: En grub rescue>, usa ls para encontrar la partición que contiene /boot/grub.
  Establece root y prefix, insmod normal, y luego arranca; después reinstala GRUB desde el SO.

2) Síntoma: error: file '/boot/grub/i386-pc/normal.mod' not found

• Causa raíz: GRUB en modo legacy/BIOS espera módulos i386-pc pero no están presentes (o en realidad usas UEFI).
• Solución: Verifica el modo de arranque y reinstala GRUB con el target correcto. En UEFI, espera x86_64-efi.

3) Síntoma: El sistema arranca a rescue tras reemplazar disco, pero las particiones parecen bien

• Causa raíz: Cambió el orden de arranque del firmware; la entrada NVRAM UEFI falta o apunta al disco equivocado.
• Solución: Arranca el USB live en modo UEFI, monta la ESP, ejecuta grub-install en UEFI, luego verifica con efibootmgr -v.

4) Síntoma: Reinstalación de GRUB “tiene éxito” pero nada cambia

• Causa raíz: Montaste el sistema raíz equivocado (común cuando hay múltiples discos) o no montaste /boot//boot/efi.
• Solución: Usa findmnt -R /mnt y valida el contenido esperado bajo /mnt/boot y /mnt/boot/efi antes de chrootear.

5) Síntoma: Tras la reparación, el kernel arranca pero cae al prompt de initramfs

• Causa raíz: Mismatch de UUID de raíz, módulos LVM/crypt faltantes en initramfs, o crypttab/fstab incorrectos.
• Solución: Desde chroot, ejecuta update-initramfs -u -k all, verifica /etc/crypttab y /etc/fstab con los UUIDs actuales.

6) Síntoma: Solo falla cuando Secure Boot está habilitado

• Causa raíz: Binario EFI equivocado elegido (GRUB vs shim), o componentes sin firmar en la cadena.
• Solución: Reinstala GRUB con la ruta shim por defecto de Ubuntu y confirma que efibootmgr apunte a \EFI\ubuntu\shimx64.efi.
  Como diagnóstico temporal, deshabilita Secure Boot para confirmar la hipótesis.

7) Síntoma: Rescue aparece tras redimensionar/mover partición

• Causa raíz: Desajuste en la localización/pontero embebido de GRUB (especialmente en BIOS legacy) o el filesystem se movió sin reinstalar GRUB.
• Solución: Reinstala GRUB en el disco correcto y regenera la configuración. Evita redimensionar repetidamente sin reinicio/validación.

8) Síntoma: Rescue tras convertir MBR↔GPT o cambiar ajustes del firmware

• Causa raíz: Discordancia en el método de arranque (UEFI espera GPT+ESP; BIOS espera código de arranque en otros lugares).
• Solución: Decide un método. Para Ubuntu 24.04 moderno, elige UEFI+GPT+ESP salvo que tengas una razón para no hacerlo.

Listas de verificación / plan paso a paso (menor daño)

Fase 0: Seguridad primero (tarda 2 minutos, ahorra horas)

• No uses editores de particiones a menos que puedas describir el problema con precisión.
• Toma fotos/capturas de las opciones de arranque del firmware y la lista de discos si puedes.
• Si el sistema contiene datos críticos y ves errores de E/S, detente y pasa a protección de datos primero.

Fase 1: Identifica modo de arranque y diseño de almacenamiento

1. Arranca un USB live en el modo previsto (UEFI o legacy). Confirma con [ -d /sys/firmware/efi ].
2. Ejecuta lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS y mapea ESP, /boot, raíz y cualquier capa crypto/LVM/RAID.
3. Monta la raíz en /mnt. Monta /boot y /boot/efi si existen.
4. Verifica montajes con findmnt -R /mnt. Confirma que /mnt/etc y /mnt/boot contienen archivos reales.

Fase 2: Reparar desde chroot (mínimo, determinista)

1. Bind-mount /dev, /proc, /sys, /run dentro de /mnt.
2. chroot /mnt.
3. Reinstala GRUB:
   • UEFI: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
   • BIOS: grub-install --target=i386-pc --recheck /dev/<disk>
4. Ejecuta update-initramfs -u -k all y update-grub.
5. Si UEFI: ejecuta efibootmgr -v y confirma que la entrada apunte a la ruta correcta.

Fase 3: Validar y reiniciar limpiamente

1. Salir del chroot, desmontar en orden inverso.
2. Reiniciar y confirmar arranque normal.
3. Tras el arranque: ejecuta journalctl -b -0 -p warning para detectar problemas de disco o montajes persistentes.

Cuándo dejar de “reparar” y escalar a recuperación de almacenamiento

• SMART muestra sectores realocados/pending en SATA, o NVMe informa errores de medio.
• dmesg muestra errores de E/S repetidos durante lecturas.
• El sistema de archivos no se monta ni siquiera en modo solo-lectura, o fsck reporta corrupción severa.

Los cargadores de arranque no merecen que te juegues todo por ellos. Si el disco está muriendo, tu prioridad es los datos y luego reconstruir.

Preguntas frecuentes

1) ¿Significa grub rescue> que mis datos se han ido?

Normalmente no. Lo más frecuente es que GRUB no pueda encontrar sus módulos o configuración. Tu filesystem raíz con frecuencia está intacto.
Confírmalo montando particiones desde un USB live.

2) ¿Cuál es la diferencia entre arreglar desde grub rescue> y desde un USB live?

Desde grub rescue> a veces puedes arrancar una vez estableciendo root y prefix, pero es frágil.
Un USB live te permite montar el sistema instalado y reinstalar GRUB correctamente.

3) Reinstalé GRUB y sigue arrancando a rescue. ¿Cuál es el error más probable?

Modo de arranque equivocado (UEFI vs BIOS) o montajes incorrectos. La reparación “funcionó” pero apuntó al lugar equivocado.
Verifica con findmnt y comprueba si montaste la ESP en /boot/efi.

4) ¿Debería usar Boot-Repair u otras herramientas automáticas?

En un apuro, la automatización puede ayudar, pero también oculta decisiones y puede escribir cambios que no querías.
Para el menor daño en sistemas de producción, realiza los pasos manuales montar → chroot → reinstalar y mantenlo determinista.

5) ¿Puede Secure Boot causar grub rescue>?

Sí, de forma indirecta. Si la cadena espera shim y componentes firmados y algo apunta al binario EFI equivocado, el firmware puede negarse
a cargar la siguiente etapa y quedas en una mala situación. Confirma que la entrada de arranque referencia shimx64.efi en Ubuntu.

6) Tengo LVM y cifrado. ¿Necesito reinstalar GRUB de forma diferente?

Los comandos de reinstalación son similares, pero los pasos previos cambian: debes abrir LUKS, activar LVM y montar la raíz//boot//boot/efi correctos.
Además, reconstruye initramfs para que el entorno temprano sepa cómo desbloquear y ensamblar los volúmenes.

7) ¿Puedo arreglar esto sin chroot?

A veces sí, pero es más fácil equivocarse. Chroot hace que las herramientas de GRUB e initramfs operen con las rutas y la configuración del sistema instalado.
Eso reduce los accidentes de “reparé el USB live”.

8) ¿Qué hago si efibootmgr no muestra entrada ubuntu?

Reinstala GRUB en modo UEFI con la ESP montada en /boot/efi. Si aún no añade una entrada, puedes crearla manualmente,
pero primero confirma que el archivo exista en /boot/efi/EFI/ubuntu/shimx64.efi o grubx64.efi.

9) Mi servidor tiene múltiples discos. ¿En cuál instalo GRUB?

Instala en el disco desde el que arranca el firmware. En UEFI se trata principalmente de qué ESP y entrada de arranque se usan.
En BIOS, instalar en el MBR del disco equivocado es una forma muy eficiente de seguir roto.

10) Después de arreglar GRUB, ¿por qué caí en initramfs en lugar de obtener el prompt de login?

GRUB entregó correctamente al kernel, pero el kernel no puede montar la raíz (mismatch de UUID, módulos crypt/LVM faltantes, fstab/crypttab incorrectos).
Revisa los UUIDs y regenera initramfs desde chroot.

Conclusión: pasos siguientes para evitar que se repita

Recuperarse de grub rescue> se trata sobre todo de capas disciplinadas: modo de firmware, diseño de discos, montajes y luego reinstalar.
La ruta de menor daño también es la más aburrida: medir, montar correctamente, chrootear, reinstalar GRUB con el target adecuado, regenerar initramfs y la configuración.

Pasos prácticos que deberías hacer realmente después de que el sistema arranque:

• Captura una línea base: lsblk -f, blkid, efibootmgr -v (UEFI), además de /etc/fstab y /etc/crypttab.
• Decide y documenta: UEFI o legacy BIOS. Hazlo cumplir en las opciones del firmware en toda la flota.
• Haz consistente la disposición de /boot y la ESP. La consistencia es una característica de disponibilidad.
• Ejecuta chequeos periódicos de salud de disco y alerta sobre errores de E/S. Los cargadores fallan en voz alta, los discos fallan creativamente.

Si tratas el arranque como plomería de producción—trazable, repetible y no dependiente de la tradición oral—no verás grub rescue> con frecuencia.
Y cuando lo veas, lo arreglarás con cara seria.