Cuando el arranque cae en el modo grub rescue, el problema suele ser más de rutas y módulos que de pérdida real del sistema. En este artículo explico qué significa ese aviso, por qué aparece, cómo intentar recuperar el inicio desde la propia consola y cuándo merece la pena pasar a un USB de reparación. También verás qué errores suelen empeorar la situación y cómo evitar que vuelva a pasar después de arreglarlo.
Lo esencial para recuperar el arranque sin dar palos de ciego
- El prompt de rescate suele indicar que GRUB no encuentra `grub.cfg`, `prefix` o los módulos básicos.
- Antes de tocar nada, conviene revisar `ls` y `set` para localizar la partición correcta.
- Si consigues cargar `normal` o `configfile`, muchas veces puedes arrancar sin reinstalar nada.
- Si el fallo llega después de particiones, Windows o un clon de disco, revisa el orden de arranque y los UUID.
- Cuando la consola no avanza, un Live USB y una reinstalación de GRUB suelen resolver más que seguir probando al azar.
Qué está diciendo realmente la consola de rescate de GRUB
Yo suelo leer ese prompt como una advertencia muy concreta: el cargador sigue vivo, pero ha perdido la pista de la instalación que debía arrancar. En la práctica, GRUB no ha podido cargar su menú completo porque no encuentra la carpeta adecuada, el archivo `grub.cfg` o los módulos que le permiten pasar a su modo normal. Eso no implica automáticamente que Linux se haya borrado; muchas veces el sistema sigue intacto y solo hay que corregir la ruta.
La clave es entender que el terminal de rescate es limitado, pero no inútil. Con pocos comandos puedes inspeccionar discos, fijar `root` y `prefix`, cargar módulos y continuar el arranque. Cuando yo trabajo este tipo de fallo, lo primero no es improvisar, sino averiguar qué parte del mapa de discos se ha descolocado.
| Señal en pantalla | Lectura práctica | Qué hago yo primero |
|---|---|---|
grub rescue> |
GRUB no ha podido cargar su menú ni sus módulos básicos. | Revisar discos con ls y variables con set. |
unknown filesystem |
La partición elegida no es la correcta o no se puede leer. | Probar otro identificador de disco o partición. |
file not found |
La ruta a prefix, grub.cfg o un módulo no cuadra. |
Corregir la ruta y volver a cargar módulos. |
Con ese diagnóstico base, lo siguiente es identificar qué pudo romperse detrás del aviso.
Por qué aparece y cuáles son las causas más comunes
En la mayoría de los casos, el problema no nace en GRUB sino en lo que ha cambiado alrededor de él. Un redimensionado de particiones, una instalación de Windows, un clonado de disco, un cambio de orden en la BIOS o UEFI o una actualización fallida pueden dejar obsoleta la ruta que GRUB guardaba para arrancar. Si el cargador esperaba encontrar `prefix` en una partición y esa partición ya no existe donde la recordaba, cae directamente en la consola de rescate.
| Causa | Qué suele romper | Pista habitual | Mi lectura |
|---|---|---|---|
| Cambio de particiones | La posición real de `/boot` o de la raíz. | El fallo aparece tras mover, borrar o reducir particiones. | GRUB sigue apuntando a una ruta vieja. |
| Instalación o reparación de Windows | El orden de arranque o la entrada de GRUB. | El equipo entra en Windows o deja de mostrar el menú. | La firmware prioriza otra entrada o el cargador quedó sobrescrito. |
| Clonado de disco o cambio de SSD | UUID y referencias internas. | El problema aparece justo después de migrar el sistema. | La copia existe, pero las referencias ya no coinciden. |
| Daño en `/boot` o en `grub.cfg` | El menú y los módulos que GRUB necesita. |
file not found, módulos ausentes o menú incompleto. |
Falta parte de la configuración o está corrupta. |
| Cambio de firmware o modo UEFI/BIOS | La ruta de arranque que veía el equipo. | El disco sigue ahí, pero el ordenador ya no entra por donde antes. | La entrada de arranque ya no coincide con la realidad. |
Cuando el fallo llega después de tocar particiones o cambiar discos, yo desconfío menos de una avería grave y más de una ruta desactualizada. Por eso el siguiente paso consiste en apuntar a la partición correcta, no en reinstalar nada a ciegas.
Cómo salir de ahí y arrancar el sistema paso a paso
Este es el bloque que suele resolver el atasco cuando el disco todavía es legible. La idea es sencilla: localizar la partición correcta, decirle a GRUB dónde está su carpeta y cargar el menú o el kernel manualmente.
- Escribe
lspara ver los discos y particiones disponibles. En la nomenclatura de GRUB, el primer disco suele serhd0y la primera partición1. - Prueba a inspeccionar el contenido de cada partición con comandos como
ls (hd0,1)/,ls (hd0,2)/ols (hd1,1)/hasta encontrar la que contiene carpetas comoboot,grubo tu sistema Linux. - Fija la ubicación correcta con
set root=(hd0,5)yset prefix=(hd0,5)/boot/grub. Cambia los valores según tu equipo; si usas un disco NVMe, el nombre de la partición puede parecerse más a/dev/nvme0n1pXcuando llegues al arranque del kernel. - Prueba
insmod normaly despuésnormal. Si el módulo no carga, puede que el camino deprefixsiga mal; en ese caso, intentaconfigfile /boot/grub/grub.cfgsi sabes dónde está el archivo. - Si el menú no aparece, puedes arrancar a mano con
insmod linux,linux /vmlinuz root=/dev/sdXY ro,initrd /initrd.imgyboot. Si no existen los enlaces simbólicos, usa la ruta completa dentro de/boot.
Si consigues entrar al sistema, no cierres el tema ahí: la reparación correcta viene después, desde el propio Linux. Lo normal es regenerar la configuración y comprobar que el arranque ya apunta a la partición real.
Cuándo conviene reparar desde un Live USB
Si la consola no encuentra los módulos, el sistema de archivos está dañado o la configuración es demasiado compleja, yo paso a un Live USB sin perder más tiempo. Ahí puedes montar la instalación, revisar la partición raíz y rehacer GRUB desde fuera, que es más seguro cuando el arranque actual no te deja avanzar.
| Escenario | Qué reviso | Resultado esperado |
|---|---|---|
| BIOS o MBR | El disco correcto y la reinstalación del cargador. | El arranque vuelve a escribirse en el disco adecuado. |
| UEFI | La partición EFI y la entrada de arranque. | Se recupera la ruta hacia el fichero `.efi` correcto. |
| Instalación compleja | RAID, LVM, cifrado o una combinación de varios factores. | La reparación manual da más control que una solución automática. |
En Ubuntu y sus derivadas, Boot-Repair es una salida práctica cuando quieres ahorrar pasos; yo lo veo como una ayuda para salir del atasco, no como sustituto de entender qué se rompió. Si trabajas con RAID, LVM o cifrado, la reparación manual desde Live USB sigue siendo la opción más controlable, aunque lleve algo más de tiempo. En sistemas basados en Debian o Ubuntu, el cierre típico suele pasar por reinstalar GRUB y regenerar la configuración con su equivalente de `update-grub`.
Cómo reducir la probabilidad de volver a verlo
La prevención aquí es bastante poco glamourosa, pero funciona. Si vas a tocar particiones, cambiar discos o instalar otro sistema, haz una comprobación previa del mapa de arranque y guarda un USB de rescate preparado. Yo también revisaría el orden de arranque después de cada cambio importante, porque a veces el problema no está en Linux, sino en que la firmware decide arrancar otra entrada.
- Haz copia antes de redimensionar particiones o mover `/boot`.
- Tras instalar Windows, verifica si GRUB sigue siendo la primera entrada de arranque.
- Si clonas discos, comprueba UUID y montajes antes del siguiente reinicio.
- No asumas que BIOS y UEFI tratan igual la misma instalación.
- Ten a mano un Live USB o un disco de recuperación funcional.
- En equipos con SSD NVMe, cifrado o LVM, documenta la topología antes de hacer cambios.
Ese pequeño hábito ahorra muchas horas cuando el aviso reaparece meses después. Y, sobre todo, evita que una reparación rápida termine convertida en una reinstalación innecesaria.
Lo que yo revisaría antes de dar el caso por cerrado
Una vez recuperado el arranque, revisa desde dentro del sistema que la configuración generada por GRUB apunte a la partición correcta y que no haya quedado una entrada antigua en la firmware. Si el fallo vino después de un cambio de disco, confirma también que los UUID coinciden con los montajes reales; ese detalle es la causa de muchos sustos que parecen aleatorios.
Mi criterio práctico es simple: si la consola te deja explorar discos y cargar módulos, todavía hay una salida elegante desde el propio prompt; si no, cambia de estrategia y repara desde un Live USB. Esa decisión suele marcar la diferencia entre una recuperación limpia y una tarde entera probando a ciegas.
