Cómo arreglar un problema de arranque por mala configuración de fstab desde GRUB

Cuando un sistema GNU/Linux deja de arrancar o tarda una eternidad en hacerlo, muchas personas piensan directamente en reinstalar la distribución. Sin embargo, en un altísimo porcentaje de casos el problema tiene nombre y apellidos: errores en /etc/fstab o en el cargador de arranque GRUB. La buena noticia es que, con un poco de calma y siguiendo una serie de pasos, es posible recuperar el sistema sin perder datos.

A lo largo de esta guía vamos a ver, de forma práctica, cómo detectar y arreglar un problema de arranque causado por una mala configuración de fstab desde GRUB, partiendo de ejemplos reales (equipos físicos, VMs en Google Cloud y Azure, e incluso dual boot con Windows). También repasaremos otros fallos típicos de arranque en Linux y cómo afrontarlos sin volverse loco.

Qué es fstab y por qué puede dejar tu Linux sin arrancar

El archivo /etc/fstab es una tabla de configuración donde se define qué sistemas de archivos se montan al inicio, en qué punto de montaje, con qué opciones y en qué orden. Es un fichero estático que el sistema lee durante el arranque; si algo está mal ahí, el núcleo y systemd pueden quedarse bloqueados esperando dispositivos que no existen o no responden.

Un error muy típico es que, tras formatear o desconectar un disco, fstab siga apuntando a una partición o un UUID inexistente. El resultado es un mensaje del estilo:

Timed out waiting for device dev-incorrect.device
Dependency failed for /data
Dependency failed for Local File Systems
Welcome to emergency mode!

En máquinas virtuales (Google Cloud, Azure, etc.) el síntoma es casi calcado: el kernel intenta montar un sistema de archivos definido en fstab para un punto como /data o /distribution, no lo encuentra, se agota el tiempo de espera y el sistema entra en modo de emergencia pidiéndote la contraseña de root o dejándote tirado en GRUB.

Además, una simple opción mal escrita puede bloquearte el inicio. Por ejemplo, en lugar de usar errors=remount-ro (que monta la raíz en solo lectura si hay errores), alguien escribe errors=remount-rw. Esa opción no es válida y puede provocar comportamientos raros, desde fallos al montar hasta sistemas que arrancan de forma intermitente o se quedan congelados en el proceso de boot.

Ejemplos reales de fallos de arranque causados por fstab y GRUB

Para entender bien el problema, viene genial repasar varios casos reales que condensan casi todo lo que puede ir mal con fstab y GRUB en un Linux de escritorio o servidor.

En un primer caso, un usuario instala Linux Mint en un HDD de 1 TB, luego se da cuenta de que quiere el sistema en el SSD, reinstala en el SSD y formatea el viejo HDD. El sistema empieza a tardar unos dos minutos en arrancar, se queda colgado después de GRUB y del logo de Mint, salta un texto de modo de emergencia y luego finalmente arranca. Tras investigar descubre que en su fstab hay una línea:

UUID=745C-ACA6 /boot/efi vfat umask=0077 0 1

El problema es que ese UUID ya no existe y la partición /dev/sda2 desapareció al reconfigurar discos, pero la entrada permanece. El sistema intenta montar la partición EFI que ya no está, espera, falla la dependencia y de ahí el retraso y el modo de emergencia.

En otro caso, alguien conecta un disco externo, deja que una herramienta gráfica actualice fstab para montarlo automáticamente y después lo desconecta o lo reformatea. En el siguiente reinicio, el sistema se queda bloqueado porque fstab contiene una entrada apuntando a un dispositivo USB que ya no está, sin la opción adecuada para permitir arrancar si falla.

Además, esta misma persona se encuentra con la raíz montada con la opción errors=remount-rw en lugar de errors=remount-ro. Tras cambiar a mano a «ro» consigue arrancar, pero cada vez que se toca el disco externo y se actualiza fstab, regresa el lío: la entrada nueva se añade, el sistema no monta bien, fstab se queda en solo lectura y no puede guardar los cambios sin remapear el sistema de archivos como lectura-escritura.

En entornos cloud como Google Cloud o Azure, el patrón se repite: se añade un disco de datos extra, se define en /etc/fstab con un dispositivo o UUID, se borra o se desconecta el disco, y en el próximo arranque la VM cae en modo de emergencia con un mensaje de dependencia fallida para /data, /distribution o similar. Aquí, la diferencia es que se suele corregir el problema usando consola serie, modo usuario único o incluso herramientas automáticas de reparación (como Azure Linux Auto Repair, ALAR).

Síntomas típicos de un fstab roto y cómo identificarlos desde GRUB

Cuando la culpa es de fstab, casi siempre verás alguno de estos síntomas durante el arranque:

• Parada larga tras GRUB, con la pantalla mostrando mensajes del kernel y systemd probando a montar sistemas de archivos.
• Mensajes del tipo «Timed out waiting for device…» y «Dependency failed for /data», «Dependency failed for Local File Systems».
• Entrada en modo de emergencia, que pide la contraseña de root o te ofrece comandos como journalctl -xb, systemctl reboot o systemctl default.
• En algunas distros, posibilidad de pulsar Ctrl+D para continuar y que el sistema termine arrancando, pero con algunos sistemas de archivos sin montar.

Si solo ves el logo de la distro o una animación de arranque, es muy recomendable activar el modo verbose. Para ello puedes editar temporalmente una entrada de GRUB en el propio menú, o bien modificar el fichero /etc/default/grub cuando tengas acceso:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" → GRUB_CMDLINE_LINUX_DEFAULT=""

Después ejecutas update-grub. En el siguiente arranque, el sistema mostrará todas las líneas del boot, facilitando ver exactamente en qué punto se atasca y qué dispositivo está causando el problema.

Además, para hacer una autopsia más a fondo, tienes varios ficheros de log muy útiles: /var/log/boot.log (mensajes de arranque), /var/log/messages (registro general), dmesg (mensajes del kernel) y journalctl. Si el sistema ya no arranca, puedes arrancar con un Live CD o una distro Live, montar el disco del sistema y revisar esos ficheros desde allí y aplicar técnicas de perfilado del arranque.

Cómo corregir fstab desde el modo de emergencia o modo usuario único

En muchas distribuciones de servidor y en VMs, cuando fstab falla el sistema entra directamente en emergency mode. Desde ahí, si tienes contraseña de root, puedes iniciar sesión y corregir el archivo sin necesidad de Live CD.

Los pasos generales serían:

1. Entrar en la consola (serie en cloud o pantalla local) y autenticarse como root cuando lo pida.
2. Editar /etc/fstab con tu editor favorito: por ejemplo, vi /etc/fstab o nano /etc/fstab.
3. Localizar la entrada problemática (la que hace referencia al dispositivo o punto de montaje que aparece en el mensaje de error), y comentarla o corregirla. Comentar es tan sencillo como poner un # al inicio de la línea.
4. Guardar los cambios y salir del editor. En vi, por ejemplo, ESC + :wq!.
5. Ejecutar mount -a para comprobar si hay errores de sintaxis o de montaje. Si no devuelve nada raro, la configuración es razonable.
6. Reiniciar con reboot y comprobar si el sistema arranca con normalidad.

Si no tienes contraseña de root (caso habitual en imágenes cloud) puedes forzar el modo usuario único desde GRUB o desde el gestor de arranque de la VM. El truco está en editar la línea del kernel en GRUB y añadir un parámetro extra:

• En sistemas tipo RHEL, CentOS, Oracle Linux o SUSE, añadir rd.break.
• En Ubuntu 18.04, 20.04, 22.04, añadir systemd.unit=rescue.target para entrar en modo de rescate.

Una vez en ese entorno limitado, hay que remontar la raíz en modo lectura/escritura (por defecto puede estar solo lectura). Después, de nuevo, editas /etc/fstab, revisas las entradas, guardas y reinicias. El patrón es siempre el mismo: corregir la tabla, comprobar con mount -a y reiniciar.

Buenas prácticas al editar /etc/fstab: UUID, nofail y errores=remount-ro

Antes de lanzarse a hacer cambios a lo loco, conviene tener claras unas cuantas normas básicas sobre fstab que te ahorrarán muchos disgustos en el futuro.

La primera es que, siempre que sea posible, montes tus sistemas de archivos por UUID, no por nombres de dispositivo tradicionales tipo /dev/sda1. El motivo es que el orden de los discos puede cambiar (añades o quitas unidades, cambias puertos, etc.) y de repente lo que era sda1 pasa a ser sdb1. El UUID, en cambio, es un identificador único que se mantiene mientras no reformatees la partición.

Para ver los UUIDs de tus particiones puedes usar blkid o lsblk -f. Una entrada típica en fstab con UUID se vería así:

UUID=<UUID_aquí> /data xfs defaults,nofail 0 0

La segunda recomendación fundamental es usar la opción nofail para todos los sistemas de archivos que no son estrictamente necesarios para arrancar (por ejemplo, discos de datos, unidades externas, etc.). Con nofail, si un disco está desconectado, dañado o simplemente tarda en aparecer, el sistema no se quedará colgado en el arranque: simplemente no montará ese punto, pero seguirá adelante.

Por último, revisa siempre la opción errors= en la raíz. Lo correcto en ext4 es usar errors=remount-ro, que hace que, si se detectan errores, el sistema de archivos se remonte en solo lectura para proteger los datos. Poner algo inventado como errors=remount-rw es una mala idea: no es una opción válida y puede provocar justamente lo contrario a lo que quieres, además de impedir que el sistema responda adecuadamente ante fallos.

Cuando GRUB también se rompe: reparar el gestor de arranque paso a paso

No todos los problemas de arranque vienen de fstab. Muy a menudo, el propio GRUB se ve dañado o mal instalado: por ejemplo, tras agrandar, mover o borrar particiones, o después de instalar Windows sobre un Linux ya instalado (Windows suele machacar el MBR/EFI sin preguntar).

Un caso bastante típico es ver en pantalla un mensaje como «Grub Loading stage 1.5 – Error 5» y quedarse sin poder iniciar ni Linux ni Windows, o mensajes tipo No bootable device. Esto puede deberse a que GRUB intente cargar su segunda etapa desde un sector o disco que ya no coincide con la realidad (se ha movido o cambiado la tabla de particiones, se ha tocado el orden de los discos SATA, etc.).

La solución clásica, que funciona en la mayoría de distros basadas en Debian (Ubuntu, Mint, Debian, Kali, etc.), consiste en reinstalar GRUB desde un LiveCD o LiveUSB montando primero el sistema dañado y usando chroot. De forma muy resumida, la receta sería:

• Arrancar con un LiveCD/LiveUSB compatible con tu arquitectura (amd64, i386, etc.).
• Identificar qué partición es la raíz de tu Linux y, si existe, la partición /boot, con sudo fdisk -l o lsblk.
• Montar la raíz en /mnt, y la boot (si la hay) en /mnt/boot.
• Montar también /dev, /dev/pts, /proc y /sys dentro de /mnt usando mount --bind.
• Ejecutar sudo chroot /mnt para «entrar» en el sistema como si hubieras arrancado desde él.
• Reinstalar GRUB apuntando al disco correcto (no a la partición, al disco: /dev/sda, por ejemplo) con grub-install --boot-directory=/boot/ --recheck /dev/sda.
• Regenerar la configuración con grub-mkconfig -o /boot/grub/grub.cfg.
• Salir de chroot con exit y reiniciar con sudo reboot.

Si todo ha ido bien, en el siguiente arranque deberías volver a ver el menú de GRUB con tus sistemas operativos y poder iniciar de nuevo tu distribución GNU/Linux, e incluso Windows si estás en dual boot.

Otros problemas frecuentes de arranque en Linux (más allá de fstab)

Aunque fstab y GRUB se llevan buena parte de la culpa, hay otros factores que pueden dejar tu Linux KO en el arranque. Tenerlos en mente ayuda a no obsesionarse solo con un archivo cuando el fallo viene de otra parte.

Entre los motivos más frecuentes están:

• Partición de arranque dañada o mal configurada: partición /boot o ESP corrupta, sin el flag correcto o con archivos de arranque incompletos.
• Actualización del kernel fallida o incompatible: el nuevo núcleo no funciona bien con tu hardware, o la instalación se queda a medias.
• Parche o actualización del sistema que rompe servicios clave: systemd no puede levantar todos los demonios necesarios y el sistema se queda colgado.
• Drivers problemáticos: sobre todo controladores privativos de GPU o hardware peculiar instalados a mano.
• MBR/EFI sobrescrito por Windows en configuraciones de dual boot.
• Inicio rápido de Windows que mantiene la partición NTFS semihibernada e impide que Linux la toque.
• Configuración UEFI/Secure Boot conflictiva: la BIOS/UEFI no apunta al disco correcto o la distro no es compatible con Secure Boot.
• Problemas de hardware: RAM defectuosa, disco duro a punto de morir, fuente inestable, etc.

Antes de volverte loco con configuraciones, suele ser buena idea comprobar que la BIOS/UEFI detecta correctamente el disco donde está instalado Linux, que el orden de arranque es coherente y que no hay ninguna protección del MBR activada por el chipset que impida escribir el gestor de arranque.

También es recomendable pasar MemTest86+ desde GRUB para verificar la RAM (dejándolo varias pasadas) y usar herramientas de SMART (por ejemplo smartmontools desde un LiveCD) para revisar el estado de los discos. Valores como Reallocated_Sector_Ct o Current_Pending_Sector_Ct mayores que cero son mala señal y pueden indicar que el disco está en las últimas.

Herramientas de rescate: modo recovery, Boot-Repair, fsck y fdisk

Si al menos consigues llegar a GRUB y ver las «opciones avanzadas» de tu distro, tienes a tu disposición varios modos de rescate muy útiles. La mayoría de distribuciones ofrecen un Recovery Mode para cada kernel instalado que permite:

• Ejecutar fsck sobre la partición raíz y otras, corrigiendo errores del sistema de archivos.
• Lanzar clean para liberar espacio que se usa de forma innecesaria.
• Usar dpkg para reparar paquetes rotos o instalaciones incompletas.
• Actualizar GRUB desde el propio menú de recuperación.

En otros escenarios, especialmente después de haber tocado particiones, las herramientas clásicas fdisk y fsck siguen siendo imprescindibles. Desde un LiveCD, puedes hacer:

• Listar particiones con fdisk -l para localizar dónde está instalado tu Linux (a menudo /dev/sda1, /dev/sda2, etc.).
• Revisar y reparar una partición con sudo fsck /dev/sda1 (cambiando sda1 por la que corresponda).

Eso sí, hay que tener muy presente que fsck y fdisk pueden destruir datos si se usan mal. Siempre conviene hacer copia de seguridad antes de tocar nada crítico, y si no la tienes, actuar con mucha prudencia.

En el terreno de la automatización, servicios en la nube como Azure ofrecen mecanismos como Azure Linux Auto Repair (ALAR), que pueden corregir automáticamente problemas de fstab sin que tengas que entrar tú mano a mano: montan el disco del sistema en una VM de reparación, hacen copia del fstab, comentan las entradas conflictivas (especialmente las de datos sin nofail) y devuelven el disco reparado a la VM original.

Qué hacer cuando la única salida parece reinstalar Linux

Si después de pelearte con fstab, GRUB, recovery modes y otras herramientas sigues sin conseguir que el sistema arranque de forma fiable, puede que haya llegado el momento de plantearse reinstalar la distribución. No es el escenario ideal, pero, bien hecho, no tiene por qué implicar pérdida de datos.

Muchas distros modernas (Ubuntu, por ejemplo) permiten reinstalar el sistema manteniendo los datos del usuario e incluso muchas de las aplicaciones. El instalador detecta la instalación existente y ofrece la opción de volver a instalar sin tocar la carpeta personal. Aun así, siempre es muy recomendable hacer copia de seguridad previa de documentos importantes, por si acaso algo sale mal.

En equipos de sobremesa o portátiles donde tú controlas el particionado, tiene mucho sentido separar desde el principio tres particiones: una para /boot, otra para el sistema (/) y otra para los datos (/home o una partición de datos independiente). De este modo, si un día hay que reinstalar, basta con formatear solo las de arranque y sistema, dejando intacta la de datos.

En máquinas virtuales, algo parecido se puede conseguir montando los datos en discos separados y usando correctamente UUID y nofail en fstab, de forma que el sistema arranque aunque uno de esos discos esté ausente temporalmente.

Consejos para que el problema no se repita

Después de haber pasado por el mal trago de un Linux que no arranca, merece la pena tomar algunas precauciones para no volver a quedarte tirado a la mínima operación de mantenimiento.

Una de las más importantes es tener especial cuidado al editar archivos de configuración críticos como /etc/fstab o los ficheros de GRUB y la UEFI. Antes de tocar nada, haz una copia del archivo original, por ejemplo renombrándolo a fstab.bak. Si la lías, siempre podrás restaurar la versión antigua desde un LiveCD o un entorno de rescate.

Otra buena práctica es evitar depender de discos externos o USB en fstab salvo que realmente sea necesario. Si tienes que montarlos automáticamente, usa siempre UUID, la opción nofail y, si el sistema de archivos no es imprescindible, piensa si no te basta con montarlo «bajo demanda» desde el gestor de archivos o con un script manual.

A nivel de sistema, mantener Linux y su kernel actualizados ayuda a corregir fallos, bugs y problemas de compatibilidad que pueden derivar en errores de arranque. Eso sí, conviene no actualizar a lo loco en entornos de producción y tener siempre algún kernel anterior instalado en GRUB para poder arrancar si la versión nueva no se lleva bien con tu hardware.

Finalmente, ningún mecanismo técnico sustituye a unas buenas copias de seguridad. Tanto si usas tu equipo como sobremesa doméstico, como si trabajas con VMs en la nube, tener un plan de backup claro (a otra partición, a otro disco, a la nube) es la diferencia entre un susto de un rato y un desastre total el día que el disco decida morir o el sistema se corrompa sin vuelta atrás.

Dominar cómo funciona fstab, GRUB y las herramientas de rescate de Linux convierte un error de arranque de algo dramático a un simple contratiempo que puedes resolver en unos minutos, y te permite tener mucho más control sobre tu sistema, tanto en tu PC personal como en servidores físicos o virtuales.