Error «unknown filesystem» en GRUB: causas, casos reales y cómo solucionarlo paso a paso

Si alguna vez has encendido el ordenador y te ha saludado una pantalla negra con el mensaje «error: unknown filesystem. grub rescue», ya sabes lo que se siente: cara de póker, algo de pánico y la sensación de que te has quedado sin sistema. Lo curioso es que este fallo no solo aparece en equipos con Linux, también puede asustar a quien solo ha usado Windows toda la vida y no tiene ni idea de qué es GRUB.

En muchos casos el problema surge tras una actualización de Windows, cambios en particiones o toquetear discos/SSD. Incluso hay usuarios que se lo encuentran sin haber instalado jamás Linux, porque algún fabricante o técnico dejó restos de un gestor de arranque tipo GRUB en el disco. La buena noticia es que, salvo desastres muy serios en el disco, este error suele ser reversible con unos cuantos comandos y algo de paciencia.

Qué significa el mensaje «error: unknown filesystem. grub rescue.»

Cuando ves «error: unknown filesystem» en pantalla, lo que realmente te está diciendo GRUB es que ha intentado leer una partición que ya no reconoce o que no contiene el sistema de archivos que espera. Es decir, el cargador de arranque sabe que debe buscar sus archivos en cierto disco y partición, pero al llegar allí se encuentra algo que no entiende.

Ese mensaje suele ir seguido de la línea «Entering rescue mode… grub rescue>». En ese punto el sistema ya no arranca solo, sino que te deja en un entorno mínimo donde solo tienes algunos comandos básicos de GRUB para intentar localizar a mano la partición correcta y reactivar el arranque.

También se da mucho cuando se borran o se modifican sin cuidado las particiones EFI (FAT32) o las particiones Linux (ext2/ext4) durante reconfiguraciones de discos, migraciones a SSD o intentos de «limpiar» particiones que parecen sobrantes.

Caso típico: error unknown filesystem en un PC con Windows que jamás «tuvo» Linux

Un caso real muy ilustrativo es el de una persona con un PC de sobremesa con Windows 10 Pro que, tras meses funcionando bien, un día lo saca de hibernación y, en lugar de su escritorio de siempre, se encuentra con la pantalla negra de GRUB y el mensaje «error: unknown filesystem. grub rescue».

Lo más desconcertante era que este usuario afirmaba no haber tenido Linux, Ubuntu ni ninguna otra distribución jamás instalada en esa máquina. Lo único que había hecho el día anterior fue reiniciar tras actualizar su antivirus (NOD32), el equipo arrancó sin problemas, lo puso a hibernar… y al volver: desastre.

En situaciones así hay varias posibilidades: que el equipo viniera de fábrica con algún tipo de partición oculta o instalación previa de Linux, que algún técnico hubiese usado una distro en el pasado y dejado el cargador GRUB en el MBR/EFI, o incluso que hubiera habido intentos de clonar discos/particiones en otro momento. El resultado final es que, aunque el usuario «solo vea Windows», el arranque real está controlado por GRUB.

Cuando algo cambia en las particiones (por ejemplo, una actualización que toca la tabla de particiones o reescribe parte del arranque), GRUB puede dejar de encontrar el sistema donde lo esperaba y lanza el temido «unknown filesystem». Esto explica por qué, sin haber tocado conscientemente Linux, puedes acabar en la consola de rescate de GRUB.

En un escenario así, si solo quieres seguir usando Windows, la solución pasa por reparar el arranque de Windows y eliminar GRUB. Pero si realmente existe una instalación Linux (aunque sea antigua o que ya no recuerdes), también puedes optar por reparar GRUB y mantener el dual boot. Si el problema está muy centrado en el rescate de GRUB en un equipo Windows, hay guías específicas sobre cómo arreglar el rescate de GRUB en Windows.

Identificar correctamente las particiones: UEFI, ext4, swap y compañía

Antes de meter mano es fundamental saber qué particiones tienes, qué sistema de archivos usan y cuál es su función. Sin esto, cualquier intento de reparación es ir a ciegas. Para ello, lo más habitual es arrancar con un live USB de Linux (Manjaro, Ubuntu, etc.) y ejecutar herramientas como fdisk -l o lsblk.

En un caso práctico real con un SSD NVMe, la salida de fdisk -l mostraba algo parecido a esto (simplificado para entenderlo):

Disk /dev/nvme0n1: 465.76 GiB, ... 976773168 sectors
Disklabel type: gpt
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 8390655 8388608 4G EFI System
/dev/nvme0n1p3 12584960 548937727 536352768 255.8G Linux filesystem
/dev/nvme0n1p11 730861567 976773134 245911568 117.3G Linux filesystem

Además había otro disco /dev/sda con particiones de tipo Linux y swap, y un USB de arranque con Ventoy, pero centrémonos en el NVMe principal, que es donde residía el sistema.

En este escenario, la partición /dev/nvme0n1p1 se había creado o recreado como partición EFI System (ESP) en FAT32 con unos 4 GB de espacio, mientras que /dev/nvme0n1p3 y /dev/nvme0n1p11 eran particiones Linux (por ejemplo, ext4) donde estaba el sistema real o restos de sistemas antiguos.

El usuario había llegado a tener algo como:

nvme0n1p1 34 4196351 2G ext4 (antes de recrearla)
nvme0n1p3 ... 255.8G ext4
nvme0n1p11 ... 117.3G ext4

y había ido borrando y creando particiones, copiando datos entre ellas y eliminando particiones «de Microsoft», lo que complicó aún más el arranque. De ahí que un asesor le advirtiera que quería copiar manualmente datos de una partición a otra, borrar particiones de Windows y reconstruir todo, y eso «iba a ser un trabajo largo y duro».

La importancia de la partición EFI (ESP) en sistemas UEFI

En equipos modernos con firmware UEFI, el arranque no funciona como en el modo BIOS clásico. Necesitas una partición especial de tipo ESP (EFI System Partition), normalmente de unos cientos de MB (o algo más, como en el ejemplo), formateada en FAT32. Ahí se guardan los cargadores de arranque de los distintos sistemas (Windows, Linux, etc.).

Según las especificaciones UEFI (por ejemplo, la sección UEFI-Specs §12.3 File System Format), esta partición debe usar un sistema de archivos FAT para que el firmware pueda leerlo. Si por error conviertes esa partición a ext4 o la borras, el firmware ya no puede cargar el gestor de arranque correspondiente, lo que suele desembocar en errores de arranque o en que UEFI arranque otro disco cualquiera.

En el caso del NVMe mencionado antes, alguien había terminado con una supuesta «primera partición de arranque» en ext4 en lugar de FAT. Así, desde el punto de vista de UEFI, aquello no era una ESP válida. Lo extraño es que el equipo intentaba arrancar de todos modos, llegando a mostrar la antigua pantalla de carga de Manjaro (aunque mal renderizada), lo que indicaba que quedaban restos antiguos de configuración de arranque UEFI apuntando a un cargador de Manjaro.

La recomendación en ese caso fue muy clara: crear de nuevo /dev/nvme0n1p1 como ESP FAT32, copiar allí los contenidos de todas las antiguas particiones EFI que hubiera en el sistema (si se habían salvado antes) y recomponer después la estructura de arranque (GRUB o el bootloader que se quisiera usar).

Un detalle importante: muchas guías recomiendan tener el directorio /boot/efi montado sobre esa partición ESP. Esto se configura en /etc/fstab usando su UUID, algo como:

UUID=F7CE-D10A /boot/efi vfat umask=0077 0 2

De este modo, cuando el sistema Linux arranca, monta automáticamente la ESP en /boot/efi y los cargadores de arranque se instalan o actualizan ahí.

Plan de reconstrucción de particiones y arranque en un SSD

En un caso avanzado, un usuario que había ido borrando particiones de Windows y repartiendo su SSD NVMe en varios trozos (p1, p3, p11, etc.) recibió un plan bastante metódico para reordenar el disco y dejar un esquema limpio, manteniendo su sistema actual a salvo mientras se rearmaba el arranque.

El planteamiento, resumido, era este:

• Montar temporalmente la partición donde estaba el sistema vigente, por ejemplo /dev/nvme0n1p11, en algún punto como /mnt, para poder manipularlo.
• Ir montando una a una todas las ESP existentes en el SSD (si las hubiera), copiando su contenido en un subdirectorio dentro de esa partición segura (/mnt/efi-backups, por ejemplo), para no perder nada.
• Borrar todas las particiones del SSD excepto la que guarda temporalmente el sistema (en este ejemplo, p11).
• Crear una nueva /dev/nvme0n1p1 marcada como ESP con tamaño suficiente para alojar todo lo copiado (y futuro material de arranque) y formatearla como FAT32.
• Crear una nueva /dev/nvme0n1p2 como partición raíz del sistema (/), por ejemplo en Btrfs (por su facilidad para ampliarse y hacer snapshots) o ext4, a gusto del usuario, donde se migraría el contenido de la partición actual p11.
• Modificar /etc/fstab del sistema nuevo en p2, haciendo que /boot/efi apunte a la nueva p1 y la raíz (/) a p2, manteniendo también la partición /home y la swap si existían.
• Configurar y usar un cargador de arranque sencillo como sd-boot (parte de systemd) sobre la nueva partición EFI, al menos de forma temporal, porque es mucho más fácil de configurar que GRUB en una situación crítica.
• Usar efibootmgr para cambiar las entradas de arranque UEFI y señalar que el firmware debe arrancar desde la nueva /dev/nvme0n1p1 con el cargador recién instalado.
• Chrootear al sistema recién migrado y regenerar el initrd (la imagen de arranque inicial) para adaptarlo a los nuevos discos y particiones, y después instalar y regenerar GRUB si se quería volver a él.
• Probar el arranque desde este nuevo esquema, corregir fallos y, cuando todo funcionara, borrar la vieja p11 y extender p2 para ocupar todo el espacio disponible.

Este tipo de reorganización profunda del disco requiere copia de seguridad previa (lo ideal, de todo el SSD) y bastante cuidado al manipular las particiones, pero permite salir de un estado caótico con múltiples restos de sistemas y ESP desperdigadas, dejando un arranque limpio, coherente y mantenible.

Qué es sd-boot y por qué aparece en las guías de reparación

En varias recomendaciones avanzadas para reparar el arranque en sistemas UEFI aparece la sugerencia de usar sd-boot en lugar de GRUB, al menos de forma provisional. sd-boot es el bootloader ligero que viene integrado en systemd, diseñado específicamente para funcionar en entornos UEFI.

A diferencia de GRUB, sd-boot es muy sencillo: se coloca su binario en la partición EFI, normalmente bajo EFI/systemd/systemd-bootx64.efi o similar, y se configura mediante archivos de texto declarativos muy simples en tipo .conf ubicados en la propia ESP. Es mucho más directo que GRUB, que genera complejos scripts de arranque y requiere regenerar el archivo de configuración con grub-mkconfig o similares.

El motivo de recomendarlo en ese caso es que, mientras el sistema está a medio reconstruir, resulta más fácil asegurar un arranque UEFI estable con sd-boot y, una vez que la estructura de discos y particiones está ya clara y funcionando, se puede volver a instalar GRUB si el usuario lo prefiere.

Ahora bien, si estás arrancando desde un live USB de Manjaro u otra distro, también puedes usar herramientas como manjaro-chroot (o arch-chroot) para entrar en el sistema instalado y reparar directamente GRUB sin pasar por sd-boot, si te manejas bien con ello.

Problemas habituales con efibootmgr e initrd durante la reparación

Otro punto que suele confundir es el uso de efibootmgr, la herramienta que permite ver y modificar las entradas de arranque UEFI desde Linux. Al intentar usarla desde algunos entornos en vivo (especialmente si arrancan en modo BIOS o con ciertas limitaciones), puede aparecer el mensaje:

EFI variables are not supported on this system.

Este mensaje indica que, en ese momento, el entorno en el que estás corriendo Linux no tiene acceso a las variables EFI del firmware, ya sea porque el modo de arranque es BIOS/Legacy, porque el kernel no tiene soporte adecuado o porque el firmware está configurado de una forma peculiar. En ese caso es imposible usar efibootmgr para cambiar el orden de arranque, añadir entradas, etc., y deberías:

• Asegurarte de arrancar el live USB en modo UEFI y no en modo legacy/CSM.
• Comprobar en la BIOS/UEFI que el soporte para EFI no está desactivado.
• Si no hay forma, gestionar las entradas de arranque directamente desde el menú de firmware, creando/seleccionando la entrada adecuada a mano.

Otro concepto que aparece frecuentemente en estas reparaciones es la regeneración del initrd (o initramfs). Esta es la imagen inicial que el kernel carga en memoria para poder montar el sistema real. Cuando cambian las particiones, los módulos de disco o el esquema de arranque, conviene regenerarla:

• En muchas distros basadas en Debian/Ubuntu se usa update-initramfs.
• En sistemas que utilizan dracut (muy típico en Red Hat, Fedora, etc.) se genera con el comando dracut.
• En otras distribuciones se usan herramientas como mkinitcpio, muy común en Arch/Manjaro.

Que al buscar cómo regenerar el initrd te salgan casi solo resultados de Red Hat es normal, porque dracut se popularizó mucho allí, pero lo importante es revisar la documentación de tu distro concreta para usar la orden adecuada.

Uso de la consola de GRUB para salir del modo rescue

En otros escenarios, sin necesidad de grandes cirugías con particiones, el error «unknown filesystem» aparece porque GRUB está apuntando al disco o partición equivocados, pero la instalación de Linux sigue intacta en otra partición. En ese caso, puedes aprovechar la propia consola de GRUB para arrancar manualmente el sistema una vez, y desde ahí reparar su configuración.

Lo típico es que, tras el error, te quedes en un prompt del tipo grub rescue>. Desde ahí se pueden listar las particiones con ls (ls (hd0,1), ls (hd0,msdos6), etc.) hasta localizar una que tenga un sistema de archivos ext2/ext3/ext4 con el directorio /boot/grub. Esa suele ser la partición de tu Linux.

Por ejemplo, una guía muestra un caso donde la partición con el sistema Linux era (hd0,msdos6), y a partir de ahí se ejecutaron estos comandos dentro de GRUB:

set prefix=(hd0,6)/boot/grub
set root=(hd0,6)
insmod normal
normal

Fíjate que en el primer comando se indica a GRUB dónde están sus archivos internos (prefix), y en el segundo se fija la partición raíz donde se encuentra el sistema de arranque. Después se intenta cargar el módulo normal con insmod normal y, si todo va bien, se invoca el modo normal con normal, lo que hace que vuelva el menú de GRUB de siempre.

Este truco permite arrancar de forma provisional, pero mientras no se reinstale o actualice GRUB desde dentro del sistema, el problema volverá en el siguiente reinicio. Por eso, una vez dentro de tu Linux, conviene ejecutar algo como:

donde /dev/sda es el disco (no la partición, sin número al final) donde quieres dejar instalado el cargador. Para comprobar cuál es tu disco principal puedes usar df -lh o lsblk y ver en qué dispositivo cae tu partición raíz /.

Errores adicionales al intentar cargar módulos de GRUB

Durante algunos intentos de rescate, al seguir la estrategia de fijar root y prefix, puede aparecer un nuevo mensaje del estilo:

error: file '/boot/grub/i386-pc/normal.mod' not found.

Este texto indica que, aunque has apuntado a una partición que parece ser la correcta, los módulos de GRUB que se esperan en esa ruta no están donde deberían. Puede suceder porque:

• La instalación de GRUB en esa partición se ha corrompido o está incompleta.
• Estás usando una variante de GRUB (por ejemplo, para BIOS) en un entorno UEFI, o viceversa.
• La ruta configurada en prefix no coincide exactamente con la estructura de directorios real.

En estos casos suele ser más fiable arrancar con un live USB, montar el sistema en disco y en el modo adecuado (BIOS o UEFI), en vez de insistir en levantarlo desde el modo rescue con unos módulos que aparentemente faltan o no corresponden a la arquitectura utilizada.

Es importante, al reinstalar GRUB, asegurarse de que la partición EFI esté correctamente montada (por ejemplo en /boot/efi) y que se está utilizando el comando y paquetes correctos para tu entorno (por ejemplo, grub-efi-amd64 en UEFI de 64 bits, etc.).

Ejemplo de archivo /etc/fstab en un sistema con ESP, raíz, /home y swap

El archivo /etc/fstab es clave para que el sistema monte las particiones adecuadamente en cada arranque. En una de las situaciones comentadas, el contenido de /etc/fstab era algo así:

# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=F7CE-D10A /boot/efi vfat umask=0077 0 2
UUID=b2683235-d9b1-4a6f-b0fb-141a1ced512c / ext4 noatime 0 1
UUID=480d2b75-9789-4800-b8ad-764019c85d26 /home ext4 noatime 0 2
UUID=8a065abc-8719-4231-9f15-03d795b01065 swap swap noatime 0 0
tmpfs /tmp tmpfs noatime,mode=1777 0 0
//192.168.10.90/Media /home/usuario/nas/Media cifs rw,uid=1000,gid=1000,user=usuario,vers=3.0,noauto,noserverino,x-systemd.automount,x-systemd.mount-timeout=30,_netdev,credentials=/home/usuario/nas/smbcred 0 0

Aquí se ve claramente que:

• La partición EFI FAT32 se monta en /boot/efi usando su UUID F7CE-D10A.
• La raíz / apunta a una partición ext4 con otro UUID.
• El /home tiene su propia partición ext4 independiente, lo que facilita reinstalaciones.
• La swap se define también por UUID.
• Se monta además un recurso de red CIFS (Samba) como /home/usuario/nas/Media.

Si la partición EFI se ha recreado, como en el caso del NVMe anterior, es imprescindible actualizar el UUID en /etc/fstab para que apunte al nuevo valor (obtenible con blkid). De lo contrario, el sistema intentará montar una ESP que ya no existe y el arranque puede fallar o quedar en un estado inconsistente.

Una fstab bien configurada garantiza que, una vez arreglado GRUB y la estructura de particiones, el sistema monte todo en su sitio en cada reinicio sin necesidad de intervención manual.