Cómo solucionar un error de arranque de /etc/fstab con journalctl
Nivel: Principiante / Intermedio
Tiempo estimado: ~15 minutos
Objetivo: Analizar los registros del sistema con journalctl para identificar y corregir un error en /etc/fstab que impide el arranque del sistema.
Introducción
Un simple error de sintaxis en /etc/fstab puede impedir que un servidor arranque y dejarle en un shell de mantenimiento de emergencia. Para recuperarlo es necesario analizar los registros del sistema y localizar el punto exacto del fallo. En este tutorial usaremos journalctl para consultar el journal de systemd y ver los registros del sistema que Linux genera durante el arranque. Comprender los registros de systemd es una habilidad clave de la gestión de registros en Linux, que garantiza una recuperación rápida y una alta disponibilidad de sus servicios. Es necesario conocer los comandos de journalctl básicos para localizar el punto de montaje que causó el fallo.
Gestión de registros en Linux y la pila de registro
Antes de pasar a la recuperación, conviene entender los componentes implicados. Systemd (el sistema de inicio y gestor de servicios de Linux) utiliza Systemd-journald (el servicio del sistema que recopila y almacena datos de registro). Este servicio reúne cada registro (log) (un registro de los eventos que ocurren en el sistema) en el Journal (los datos de registro en formato binario almacenados por Systemd-journald). Entre ellos se incluyen los registros del sistema (registros de eventos y cambios de estado a nivel de sistema), los registros de arranque (registros del proceso de inicio del sistema) y los registros del kernel (mensajes generados por el núcleo del sistema operativo).
Según su configuración, pueden ser registros volátiles (registros almacenados en memoria que se pierden al reiniciar) o registros persistentes (registros que sobreviven a los reinicios, normalmente almacenados en disco). El journal crece continuamente, por lo que systemd gestiona de forma automática la rotación de registros (el proceso de archivar y gestionar los archivos de registro antiguos para ahorrar espacio en disco).
Requisitos previos
Antes de empezar, asegúrese de cumplir las siguientes condiciones:
- Sistema operativo: Probado en Ubuntu 22.04/24.04 LTS, Debian 12/13, AlmaLinux/Rocky 9/10
- Acceso: Acceso directo a la consola (IPMI, VNC o consola física) para llegar al shell de emergencia
- Conocimientos necesarios: Manejo seguro de la línea de comandos de Linux y edición básica de texto
En las instalaciones predeterminadas de Ubuntu y Debian, la cuenta root está bloqueada. Establezca de antemano una contraseña de root con sudo passwd root; de lo contrario, no podrá iniciar sesión en el modo de emergencia.
Las instancias VPS suelen entregarse con el usuario root habilitado de forma predeterminada.
Paso 1: Identificar el fallo de arranque
Un error de sintaxis, una errata o un dispositivo ausente en /etc/fstab activará el modo de emergencia, detendrá el proceso de arranque y mostrará un mensaje como el siguiente:
Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode. Give root password for maintenance (or press Control-D to continue):
Introduzca la contraseña de root para acceder al prompt. En esta fase, es posible que algunos sistemas de archivos no estén montados o estén montados en modo de solo lectura.
Paso 2: Usar journalctl para ver y analizar los registros del sistema que genera Linux
Para identificar la causa del fallo, debemos revisar los registros del arranque actual.
Ejecute el siguiente comando:
sudo journalctl -xb
Aquí usamos Journalctl (una utilidad de línea de comandos para consultar el journal de systemd). Es uno de los comandos de journalctl más esenciales. Indica a la herramienta que muestre los registros del arranque actual (-b) e incluya texto explicativo adicional (-x).
La salida puede ser enorme. Necesitamos aplicar un filtrado de registros (el proceso de acotar la salida de los registros según criterios específicos) para encontrar el error.
Para buscar dentro del paginador (que utiliza less), escriba /fstab o /mount y pulse Intro.
Fragmento de la salida esperada:
-- Subject: A start job for unit mnt-data.mount has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- A start job for unit mnt-data.mount has finished with a failure. -- -- The job identifier is 123 and the job result is failed.
Esto indica que ha fallado una unidad (unit) (un archivo de configuración que describe cómo gestionar un recurso en systemd) responsable de montar /mnt/data. En concreto, no se pudo iniciar la unidad de montaje (un archivo de configuración de unidad que codifica información sobre un proceso gestionado por systemd).
Puede usar la barra espaciadora para avanzar una página y q para salir del visor de registros.
Paso 3: Filtrar los registros de systemd para encontrar errores concretos
Si desplazarse por todo el registro de arranque resulta demasiado lento, podemos analizar los registros con journalctl mediante filtros específicos.
Ejecute el siguiente comando para ver solo los errores de alta prioridad:
sudo journalctl -p err -b
Salida esperada:
May 23 10:00:01 server systemd[1]: Failed to mount mnt-data.mount - /mnt/data. May 23 10:00:01 server systemd[1]: Dependency failed for Local File Systems.
El mensaje Dependency failed for Local File Systems aparece solo durante el arranque, no al ejecutar manualmente systemctl start.
Con el filtrado de registros con journalctl por prioridad (-p err), eliminamos los mensajes meramente informativos.
También podemos consultar los registros de un servicio directamente si conocemos la unidad exacta que falló. Ejecute:
sudo journalctl -u mnt-data.mount
Cuando analiza los registros con journalctl a nivel de unidad, aísla el problema de configuración exacto. Otro método de filtrado con journalctl es especificar un intervalo de tiempo, pero para problemas de arranque, filtrar por unidad es el enfoque más eficiente.
Paso 4: Corregir el error de /etc/fstab
Ahora que el journal de systemd ha confirmado que el problema es el punto de montaje /mnt/data, debemos corregir el archivo de configuración.
En primer lugar, intente editar el archivo. Si al guardar aparece el error Read-only file system, debe volver a montar el sistema de archivos raíz en modo lectura y escritura, ya que el modo de emergencia suele montarlo en solo lectura:
sudo mount -o remount,rw /
A continuación, haga una copia de seguridad del archivo de configuración antes de modificarlo:
sudo cp /etc/fstab /etc/fstab.bak
Después, abra el archivo (en sistemas basados en RPM como AlmaLinux, Rocky o RHEL, es posible que nano no esté instalado de forma predeterminada, así que instálelo primero con sudo dnf install -y nano):
sudo nano /etc/fstab
Busque la línea que hace referencia a /mnt/data (puede obtener la UUID correcta con blkid):
UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defualts 0 2
Observe la errata: defualts en lugar de defaults. Corrija la errata:
UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defaults 0 2
Guarde el archivo y salga. Después, recargue la configuración del gestor de systemd para que systemd conozca los cambios realizados en /etc/fstab:
sudo systemctl daemon-reload
Verifique siempre las UUID y la sintaxis en /etc/fstab. Una entrada incorrecta hará que el sistema vuelva al shell de emergencia en el siguiente arranque.
Verificación
Antes de reiniciar, verifique la sintaxis de su /etc/fstab con findmnt:
findmnt --verify
Si no se informa de ningún error, compruebe a continuación que el punto de montaje funciona:
Ejecute:
sudo mount -a
Si el comando no produce ninguna salida, la sintaxis es correcta y el montaje se ha realizado con éxito. Si sigue habiendo un error, el comando mostrará un mensaje de error. En Debian 13 y AlmaLinux 10, el mensaje puede indicar el motivo exacto (p. ej., Unknown parameter 'defualts'), pero en Ubuntu 24.04 la salida suele ser genérica (wrong fs type, bad option). En Ubuntu, ejecute sudo dmesg | tail para obtener más detalles.
Una vez verificado, salga del shell de emergencia para continuar con el arranque o reinicie el sistema:
sudo systemctl reboot
Tras reiniciar, puede consultar de nuevo los registros del servicio con comandos de journalctl para comprobar que el montaje se realizó correctamente durante el arranque normal:
sudo journalctl -u mnt-data.mount -b
Solución de problemas
- No se puede acceder al shell de emergencia: Si la cuenta root está bloqueada y no puede acceder al shell de emergencia, debe arrancar el servidor con un Live USB o un entorno de recuperación, montar la partición raíz y editar
/etc/fstabdirectamente desde allí. - La UUID ha cambiado: Si ha formateado una partición o sustituido un disco, la UUID cambiará. Use
sudo blkidpara encontrar la nueva UUID y actualice/etc/fstaben consecuencia. - Evitar fallos de arranque por discos no esenciales: Para volúmenes que no sean raíz ni del sistema (como unidades de copia de seguridad o de datos), añada la opción de montaje
nofaila la entrada de/etc/fstab(p. ej.,ext4 defaults,nofail 0 2). Esto indica a systemd que continúe el arranque aunque el dispositivo no se monte.
Reversión
Si el servidor arrancó correctamente pero la línea modificada de /mnt/data provoca un comportamiento inesperado en las aplicaciones, puede revertir el montaje comentando la línea en /etc/fstab:
sudo sed -i 's|^UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|#UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|' /etc/fstab
Después, desmonte el volumen para restaurar el estado anterior:
sudo umount /mnt/data
Conclusión
Una gestión de registros en Linux eficaz depende en gran medida de saber moverse por los registros de systemd. Con journalctl puede ver los registros del sistema que genera Linux para analizarlos eficazmente y recuperarse de fallos críticos de arranque, como las configuraciones erróneas de /etc/fstab. Dominar estas herramientas le permite mantener la disponibilidad y diagnosticar problemas complejos en toda su infraestructura.
Versión del documento: 1.0
Última actualización: mayo de 2026
Responsable: Equipo de documentación técnica
