Debian 13: un error en fstab impide el arranque — la solución más rápida en modo rescate

Qué se rompe realmente cuando /etc/fstab impide el arranque

/etc/fstab es engañosamente simple: un único archivo que asocia “qué montar” con “dónde y cómo”. Un error pequeño puede detener el arranque porque la canalización de arranque temprana asume que los sistemas de archivos centrales se montan correctamente.

Qué hace Debian 13 bajo el capó

Debian 13 arranca con systemd orquestando unidades de montaje derivadas de fstab. Esos montajes participan en objetivos como local-fs.target (sistemas de archivos locales montados) y multi-user.target (servicios normales). Si un montaje requerido falla, systemd puede:

• lanzarte a modo de emergencia (shell root, servicios mínimos),
• o a modo de rescate (algo más de servicios),
• o quedarse esperando un dispositivo que nunca aparece, según opciones como nofail, x-systemd.device-timeout= y si el montaje está marcado como requerido.

En la práctica, los modos de fallo se concentran en unas pocas causas:

• Desajuste de identificador: UUID/LABEL/PARTUUID incorrecto, dispositivo renombrado, disco reemplazado o clonado.
• Desajuste de punto de montaje: error tipográfico en el directorio de montaje, tipo de sistema de archivos incorrecto, directorio faltante.
• Cadena de dependencias: un montaje es requerido por otro montaje (p. ej., /var necesario antes de los servicios), o por unidades systemd que asumen que está presente.
• Problemas del sistema de archivos: journal sucio, superbloque dañado, o un apagado no limpio forzado a un montaje estricto.
• Sorpresa con montajes de red: entrada NFS/CIFS sin _netdev / dependencias de red en systemd, provocando bloqueo en el arranque temprano.

He aquí el punto operativo clave: no “arregles” fstab adivinando. Recopila pruebas. Confirma identificadores. Confirma el tipo de sistema de archivos. Confirma la visión de systemd sobre el fallo. Luego edita una sola vez.

Un chiste corto, como mecanismo de afrontamiento: /etc/fstab es el único archivo donde un espacio que falta puede dejar fuera de servicio a todo un servidor y aún sentirse ofendido personalmente.

Guion de diagnóstico rápido (comprueba primero/segundo/tercero)

Esta es la secuencia “tengo cinco minutos antes de que alguien declare incidente”. Está optimizada para velocidad y alta señal.

Primero: identifica el montaje exacto que falla y por qué a systemd le importa

• En la shell de emergencia del sistema roto, encuentra las unidades fallidas: systemctl --failed.
• Inspecciona los registros de la unidad de montaje: journalctl -xb y busca “mount” / “Dependency failed” / “timed out”.
• Decide: ¿es un montaje local requerido (bloquea el arranque) o algo agradable de tener (debería ser nofail)?

Segundo: verifica la identidad del dispositivo, no el nombre del dispositivo

• Lista los dispositivos de bloque con UUIDs y sistemas de archivos: lsblk -f y blkid.
• Decide: ¿fstab referencia un UUID que no existe? Si es así, corrige con el UUID correcto o cambia a LABEL si controlas las etiquetas.

Tercero: determina si el sistema de archivos es montable o necesita reparación

• Intenta montar en modo solo lectura en rescate para probar: mount -o ro.
• Si falla por corrupción o errores de journal: ejecuta el fsck apropiado para ext*, o revisa la semántica de xfs/btrfs (xfs usa xfs_repair).
• Decide: ¿puedes montar en solo lectura y arreglar la configuración, o necesitas reparación antes de cualquier otra cosa?

Cuarto (solo si es necesario): evita el bloqueo para arrancar y arreglar desde un userspace real

• Añade temporalmente nofail y un timeout corto para montajes no críticos.
• O comenta la línea problemática para llegar a multi-user, y luego arregla correctamente con todas las herramientas.
• Decide: ¿necesitas el montaje para la corrección, o necesitas primero el host en línea?

Datos interesantes y contexto histórico (porque ayuda)

Saber por qué las cosas son como son hace que la depuración sea más rápida. Aquí hay algunos datos concretos que importan cuando estás hasta el codo en una shell de rescate.

1. fstab precede a Linux. La idea de una tabla de sistemas de archivos estática viene del Unix tradicional, mucho antes de que el almacenamiento hotplug fuera habitual.
2. Los nombres de dispositivo no son estables. /dev/sda puede convertirse en /dev/sdb tras cambios de controlador; los UUIDs existen en gran parte porque los administradores se cansaron de ese juego.
3. systemd convierte las líneas de fstab en unidades. Cada entrada se vuelve una unidad .mount, participando en grafos de dependencias. Un solo montaje fallido puede bloquear objetivos.
4. nofail cambió la cultura. Los scripts de arranque antiguos a menudo continuaban; systemd es más estricto por defecto a menos que se le indique lo contrario.
5. Initramfs es un pequeño sistema operativo. Cuando caes en initramfs, estás en un entorno minimal donde algunas herramientas pueden faltar y los drivers están limitados a lo que se compiló.
6. Los UUIDs viven en los metadatos del sistema de archivos. Clonar discos puede duplicar UUIDs, creando montajes “correctos a la vista” pero equivocados si ambos están presentes.
7. Los montajes de red solían manejarse tarde. El paralelismo de arranque moderno significa que las entradas NFS/CIFS en fstab necesitan dependencias de red explícitas o compiten con la red.
8. /etc/fstab sigue siendo relevante con automounting. Incluso con udev y automounts de escritorio, los servidores dependen de montajes previsibles durante el arranque para servicios y logs.
9. Las opciones de montaje pueden ser políticas operativas. Opciones como errors=remount-ro, noatime y timeouts de systemd tratan más de fiabilidad que de micro-rendimiento.

Una cita, y seré breve. Parafraseando a Gene Kim: La fiabilidad viene de diseñar sistemas que fallen de formas previsibles y recuperables, no de heroísmos.

La solución más rápida en modo rescate (paso a paso, con decisiones)

El objetivo es editar el /etc/fstab real, no el del entorno de rescate. Suena obvio hasta que editas el archivo equivocado y te preguntas por qué nada cambió.

Paso 0: elige tu entorno de rescate

Usa el que te proporcione una shell con herramientas básicas de disco:

• GRUB “Advanced options” → recovery mode (a menudo suficiente).
• Initramfs emergency shell (funciona, pero las herramientas pueden ser escasas).
• Instalador de Debian en modo rescate, o un live ISO (mejor tooling).

Si ya llegas a la shell de emergencia del sistema, puede que no necesites medios externos. Pero si te faltan herramientas como lsblk o nano, deja de sufrir y arranca un ISO de rescate.

Paso 1: identifica el sistema raíz y móntalo en un lugar predecible

En modo rescate, / puede ser el sistema de rescate, no tu disco. Encuentra tu partición root real y móntala bajo /mnt.

Paso 2: si usas /boot separado, /boot/efi, /var, móntalos también

Monta solo root suele ser suficiente para editar fstab. Pero si planeas reconstruir initramfs o tocar configuraciones del cargador, monta /boot y EFI también.

Paso 3: edita fstab como si desactivarás una bomba

Específicamente:

• Corrige UUID/LABEL/PARTUUID erróneos.
• Corrige tipos de sistema de archivos (ext4 vs xfs vs btrfs).
• Para montajes no críticos (discos de backup, scratch, NFS), añade nofail y un timeout razonable.
• No “arregles” cambiando a /dev/sdX salvo que disfrutes de la ruleta.

Paso 4: valida el cambio antes de reiniciar

Prueba a montar todo desde la raíz instalada usando mount -a en un chroot o usando mount --fake si procede. Si da error, no has terminado.

Paso 5: reinicia una vez, observa y verifica

Tras el reinicio, confirma los montajes con findmnt y verifica que el arranque alcanzó el objetivo previsto.

Segundo chiste corto, porque todos hemos pasado por eso: Cada vez que reinicias para “ver si funcionó”, un ingeniero de almacenamiento pierde un poco de fe en la humanidad.

Tareas prácticas: comandos, salidas y qué decides

Estas son las tareas de nivel on-call que yo realmente ejecuto. Cada una incluye: el comando, una salida de ejemplo, qué significa y la decisión que tomas. Ejecútalas en orden, o salta a la que responda tu pregunta actual.

Task 1: See what systemd thinks failed (from emergency/rescue shell)

cr0x@server:~$ systemctl --failed
  UNIT                       LOAD   ACTIVE SUB    DESCRIPTION
● mnt-data.mount             loaded failed failed  /mnt/data
● local-fs.target            loaded failed failed  Local File Systems

LOAD   = Reflects whether the unit definition was loaded properly.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

2 loaded units listed.

Qué significa: una unidad de montaje falló y arrastró local-fs.target. Por eso se detuvo el arranque.

Decisión: inspecciona mnt-data.mount y la línea correspondiente en fstab. Determina si debe ser requerida u opcional (nofail).

Task 2: Pull the exact error from the journal

cr0x@server:~$ journalctl -xb --no-pager | tail -n 30
Dec 29 09:18:12 server systemd[1]: Mounting /mnt/data...
Dec 29 09:18:12 server mount[512]: mount: /mnt/data: special device UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999 does not exist.
Dec 29 09:18:12 server systemd[1]: mnt-data.mount: Mount process exited, code=exited, status=32/n/a
Dec 29 09:18:12 server systemd[1]: mnt-data.mount: Failed with result 'exit-code'.
Dec 29 09:18:12 server systemd[1]: Failed to mount /mnt/data.
Dec 29 09:18:12 server systemd[1]: Dependency failed for Local File Systems.
Dec 29 09:18:12 server systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.

Qué significa: el UUID referenciado en fstab no está presente. Esto no es un problema de corrupción del sistema de archivos; es un problema de identidad.

Decisión: encuentra el UUID correcto (o decide marcar el montaje como opcional) y corrige fstab.

Task 3: List all block devices with filesystem metadata

cr0x@server:~$ lsblk -f
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32 EFI    7A1B-2C3D                             498M     1% /boot/efi
├─nvme0n1p2 ext4   1.0   boot   0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d  712M    18% /boot
└─nvme0n1p3 ext4   1.0   root   4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f   38G    42% /
sda
└─sda1      ext4   1.0   data   9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a

Qué significa: puedes ver el UUID real del disco de datos (9c2b8d...). El que aparece en el journal (2b1c2c...) es incorrecto.

Decisión: actualiza /etc/fstab para usar el UUID correcto o una etiqueta.

Task 4: Double-check with blkid (more direct, sometimes clearer)

cr0x@server:~$ blkid
/dev/nvme0n1p1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="7A1B-2C3D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8f9d0b0a-01"
/dev/nvme0n1p2: LABEL="boot" UUID="0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8f9d0b0a-02"
/dev/nvme0n1p3: LABEL="root" UUID="4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8f9d0b0a-03"
/dev/sda1: LABEL="data" UUID="9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c2b9c3a1-01"

Qué significa: mapeo autoritativo de dispositivo a UUID/LABEL del sistema de archivos.

Decisión: prefiere UUID= o LABEL= en fstab. Evita /dev/sda1 salvo que estés en un entorno controlado y entiendas el riesgo.

Task 5: Mount the installed system’s root from a rescue ISO

cr0x@server:~$ mount /dev/nvme0n1p3 /mnt
cr0x@server:~$ ls /mnt
bin  boot  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Qué significa: montaste el sistema raíz real en /mnt.

Decisión: edita /mnt/etc/fstab, no /etc/fstab del sistema de rescate.

Task 6: Inspect the broken fstab line

cr0x@server:~$ sed -n '1,200p' /mnt/etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f /     ext4  defaults,errors=remount-ro 0 1
UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4  defaults                  0 2
UUID=7A1B-2C3D                            /boot/efi vfat umask=0077              0 1
UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999 /mnt/data ext4 defaults                0 2

Qué significa: el montaje de datos referencia un UUID que no está presente en la máquina.

Decisión: sustituye ese UUID por el correcto, o comenta la línea y añade una versión más segura.

Task 7: Fix fstab quickly and safely (use a real editor, but here’s a minimal patch)

cr0x@server:~$ cp -a /mnt/etc/fstab /mnt/etc/fstab.bak.$(date +%s)
cr0x@server:~$ sed -i 's/UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999/UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a/' /mnt/etc/fstab
cr0x@server:~$ tail -n 5 /mnt/etc/fstab
UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f /     ext4  defaults,errors=remount-ro 0 1
UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4  defaults                  0 2
UUID=7A1B-2C3D                            /boot/efi vfat umask=0077              0 1
UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults                0 2

Qué significa: parcheaste el UUID incorrecto por el correcto y hiciste una copia de seguridad primero (bien).

Decisión: valida intentando montar antes de reiniciar.

Task 8: Create mountpoint if the typo was “directory doesn’t exist”

cr0x@server:~$ mkdir -p /mnt/mnt/data
cr0x@server:~$ ls -ld /mnt/mnt/data
drwxr-xr-x 2 root root 4096 Dec 29 09:27 /mnt/mnt/data

Qué significa: el punto de montaje ahora existe dentro del root del sistema instalado.

Decisión: si el único fallo era “el punto de montaje no existe”, esto por sí solo puede arreglar el arranque. Aun así valida con una prueba de montaje.

Task 9: Test mounts against the installed system’s fstab (without chroot)

cr0x@server:~$ mount -a -T /mnt/etc/fstab -R /mnt
cr0x@server:~$ findmnt -R /mnt | tail -n 8
/mnt                 /dev/nvme0n1p3 ext4   rw,relatime,errors=remount-ro
/mnt/boot            /dev/nvme0n1p2 ext4   rw,relatime
/mnt/boot/efi        /dev/nvme0n1p1 vfat   rw,relatime,fmask=0077,dmask=0077
/mnt/mnt/data        /dev/sda1      ext4   rw,relatime

Qué significa: todos los sistemas de archivos listados se montaron con éxito bajo /mnt usando el fstab instalado.

Decisión: puedes reiniciar con alta confianza. Si este paso falla, no reinicies—corrige el error ahora.

Task 10: If you need chroot (for initramfs rebuilds or systemctl checks)

cr0x@server:~$ mount --bind /dev  /mnt/dev
cr0x@server:~$ mount --bind /proc /mnt/proc
cr0x@server:~$ mount --bind /sys  /mnt/sys
cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# systemctl --failed
0 loaded units listed.

Qué significa: estás operando dentro del sistema instalado. Las fallas de unidad vistas antes deberían haber desaparecido si el problema del montaje era el único bloqueador.

Decisión: si cambiaste algo que afecta al arranque temprano (crypto, LVM, drivers), reconstruye initramfs. Si no, mantenlo simple.

Task 11: Rebuild initramfs (only when it’s actually relevant)

cr0x@server:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Qué significa: initramfs se regeneró. Esto importa si cambió el descubrimiento de root, hooks de crypto o drivers—no por un typo simple en fstab, pero a veces arreglas varias cosas a la vez.

Decisión: si tocaste configuraciones del stack de disco, hazlo. Si solo corregiste un montaje opcional, puedes omitirlo para reducir riesgo.

Task 12: Verify fstab syntax and spot tabs/spaces issues before reboot

cr0x@server:/# awk 'NF && $1 !~ /^#/ {print NR ": " $0}' /etc/fstab
2: UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f / ext4 defaults,errors=remount-ro 0 1
3: UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4 defaults 0 2
4: UUID=7A1B-2C3D /boot/efi vfat umask=0077 0 1
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults 0 2

Qué significa: cada línea activa tiene campos; no hay truncamiento obvio. Esto no detectará todos los errores semánticos, pero sí atrapa “accidentalmente borré la mitad de una línea”.

Decisión: si alguna línea parece malformada, arréglala ahora. Un fstab sintácticamente roto es una de las pocas formas de convertir un problema trivial en algo indebidamente emocionante.

Task 13: If the mount is non-critical, make boot resilient

cr0x@server:/# cp -a /etc/fstab /etc/fstab.bak.$(date +%s)
cr0x@server:/# grep -n '/mnt/data' /etc/fstab
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults 0 2
cr0x@server:/# sed -i 's|/mnt/data ext4 defaults|/mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s|' /etc/fstab
cr0x@server:/# grep -n '/mnt/data' /etc/fstab
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

Qué significa: si el disco desaparece más tarde, el arranque no se bloqueará para siempre. Eso es operativamente sensato para montajes que no son requeridos para que el OS funcione.

Decisión: haz esto para volúmenes de backup, espacio temporal o NFS “agradable de tener”. No lo hagas para /, /var o cualquier cosa que tus servicios requieran—omitirlos silenciosamente solo produce fallos raros.

Task 14: Exit, unmount cleanly, and reboot

cr0x@server:/# exit
cr0x@server:~$ umount -R /mnt
cr0x@server:~$ reboot

Qué significa: dejas el sistema en un estado consistente. Desmontar reduce el riesgo de un journal sucio por el entorno de rescate.

Decisión: si umount -R se queja de montajes ocupados, busca shells aún en /mnt y ciérralas. No cortes la energía a lo bruto a menos que quieras añadir reparación de sistemas de archivos a tu día.

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

Esta sección es directa a propósito. La mayoría de las fallas de arranque por fstab son reincidentes.

1) Arranque cae en modo de emergencia: “special device UUID=… does not exist”

Síntoma: el journal muestra UUID faltante; la unidad de montaje falla; local-fs.target falla.

Causa raíz: UUID incorrecto en fstab (typo, disco reemplazado, clonado o el sistema de archivos fue reformateado).

Solución: encuentra el UUID correcto con lsblk -f/blkid, actualiza /etc/fstab, valida con mount -a -T ... -R .... Si el montaje es opcional, añade nofail y un corto x-systemd.device-timeout.

2) Se cuelga durante 90 segundos (o más): “Timed out waiting for device”

Síntoma: arranque lento, luego emergencia; los logs de systemd muestran timeout de dispositivo.

Causa raíz: systemd esperó por un dispositivo de bloque que no está presente o aparece tarde (USB/SAN/iSCSI), y el timeout es por defecto/largo.

Solución: decide si el montaje es requerido. Si no, usa nofail,x-systemd.device-timeout=10s. Si es requerido, arregla el descubrimiento del dispositivo subyacente (multipath, iSCSI ordering, drivers, hooks en initramfs).

3) “mount point does not exist”

Síntoma: el montaje falla instantáneamente; el journal indica directorio faltante.

Causa raíz: error tipográfico en el punto de montaje o directorio eliminado (a menudo durante limpieza o por un rm -rf accidental).

Solución: crea el directorio en el root del sistema: mkdir -p /mnt/<mountpoint> (o en chroot). Confirma permisos si el directorio lo usa algún servicio.

4) “wrong fs type, bad option, bad superblock”

Síntoma: mount informa problemas de superbloque; puede caer en emergencia.

Causa raíz: tipo de filesystem incorrecto en fstab, o corrupción real del sistema de archivos, o tratar de montar la partición equivocada en el punto equivocado.

Solución: confirma el tipo real con blkid. Si es ext4: ejecuta fsck -f desde rescate (desmontado). Si es xfs: usa xfs_repair (comprende el riesgo). Si es btrfs: usa btrfs check con cuidado. Si apuntaste la partición equivocada, corrige la línea de fstab para usar el UUID correcto.

5) Línea NFS/CIFS bloquea el arranque

Síntoma: arranque se detiene o se demora mucho; los logs mencionan fallos de montaje remoto.

Causa raíz: red no lista cuando systemd intenta montar; falta _netdev o enfoque de automount.

Solución: añade _netdev,nofail,x-systemd.automount para shares no críticos; o asegura dependencias systemd correctas. Si es crítico, quieres orden explícita y timeouts, no esperanza.

6) “Arreglé fstab, pero todavía no arranca”

Síntoma: mismo fallo tras reiniciar; estás seguro de que lo editaste.

Causa raíz: editaste el /etc/fstab del sistema de rescate, no el instalado; o montaste la raíz equivocada; o tienes raíces múltiples (LVM, snapshots).

Solución: verifica que montaste la raíz instalada en /mnt y editaste /mnt/etc/fstab. Confirma con cat /mnt/etc/debian_version y ls /mnt conteniendo directorios esperados y archivos específicos del host.

Tres micro-historias corporativas de la vida real (anonimizadas)

Micro-historia 1: El incidente causado por una suposición equivocada

Migraron un servicio interno de tamaño medio a hardware nuevo: mismo Debian, misma pila de apps, “solo discos más rápidos”. El plan era rsync del root, adjuntar un disco secundario para datos y replicar el layout de montajes antiguo. Simple.

La suposición equivocada fue sutil: “Los UUID serán distintos, pero los arreglamos después.” El equipo corrigió los obvios: root y boot. Fallaron en una sola línea para /var/lib/app que referenciaba el UUID de la partición de datos del servidor anterior. Ese directorio existía también en root, así que nadie lo notó en las comprobaciones previas. Montaba “bien” — con la identidad del servidor antiguo, que por supuesto no existía en la máquina nueva.

En el primer arranque, systemd intentó montarlo, falló y cayó en modo de emergencia. La ventana de migración se estaba consumiendo. La gente empezó a debatir si el controlador RAID estaba roto. Alguien sugirió re-imagar. El movimiento clásico: tratar un problema de configuración como si fuera hardware porque el hardware se siente más “real”.

La solución tardó cuatro minutos una vez que alguien silenció el ruido. En modo rescate ejecutaron systemctl --failed, vieron la unidad de montaje exacta, hicieron lsblk -f para identificar el UUID real de la partición de datos y parchearon fstab. Luego añadieron x-systemd.device-timeout=10s para evitar que futuros arranques de staging se cuelguen cuando el equipo de almacenamiento “temporalmente” quite un LUN.

La lección fue aburrida: no copies fstab entre máquinas sin un paso explícito de reconciliación. Los UUID no son adorno. Son la verdad de la que depende el arranque.

Micro-historia 2: La optimización que salió mal

Otra compañía tenía una flota de servidores Debian que escribían muchos logs y métricas. Alguien decidió optimizar I/O montando un gran volumen “scratch” con opciones agresivas y separando /var en su propia partición. La idea era buena: aislar churn, evitar que root se llene y reducir backups.

El problema vino de un despliegue a medias. Añadieron el nuevo montaje de /var a fstab usando rutas /dev/disk/by-id/… que eran estables en la máquina de prueba. En producción, los IDs de disco diferían porque compras diferentes modelos a mitad de trimestre. El dispositivo simplemente no existía en un subconjunto de nodos.

Esos nodos no fallaron de forma elegante. Algunos arrancaron lentamente porque systemd esperaba. Otros cayeron en modo emergencia porque /var era requerido y no estaba marcado nofail (ni debería haberlo estado). Mientras tanto el equipo intentaba reducir el tiempo de arranque acortando timeouts de servicios no relacionados. La depuración se volvió un carnaval de arreglos parciales.

Recuperaron rápido con un enfoque consistente: ISO de rescate, montar root, verificar dispositivos reales con lsblk -f, reemplazar la referencia by-id por UUIDs del sistema de archivos y luego probar mount -a bajo el root instalado antes de reiniciar. Más tarde mejoraron el despliegue etiquetando sistemas de archivos con un esquema consistente y usando LABEL= para las particiones que la gente razona manualmente.

La lección: una “optimización” que aumenta la variabilidad entre hardware no es optimización. Es deuda técnica con un nombre bonito.

Micro-historia 3: La práctica tediosa pero correcta que salvó el día

Un entorno financiero tenía una política que parecía molesta: cualquier cambio a /etc/fstab requería una comprobación previa y una posterior. La pre-comprobación era: verificar que el objetivo existe (blkid), verificar que el directorio de montaje existe y hacer una prueba de montaje en seco en una shell de mantenimiento. La post-comprobación era: confirmar con findmnt y asegurar que los objetivos de arranque estaban limpios.

Una noche, un cambio de almacenamiento quitó un volumen secundario de un lote de servidores por un error de zonificación río arriba. No fue malicia; fue una persona con una hoja de cálculo y un día largo. Los servidores se reiniciaron como parte del parche rutinario.

Sin precauciones, esas máquinas habrían quedado atascadas en modo de emergencia. Pero esos montajes secundarios estaban intencionalmente marcados nofail con un corto x-systemd.device-timeout, porque eran para exports usados por un trabajo analítico no crítico. Los sistemas arrancaron, los servicios núcleo se levantaron y la monitorización alertó del sistema de archivos faltante como una advertencia a nivel de aplicación en lugar de una caída total.

Lo que los salvó no fue genialidad. Fue clasificación: montajes críticos estrictos; montajes no críticos resilientes. Y el proceso de cambio tenía suficiente fricción para obligar al ingeniero a pensar, “Si falta este disco, ¿debe detenerse el arranque?”

La lección: la mejor técnica de fiabilidad es a menudo un bien ubicado “esto es opcional” combinado con validación de que realmente lo es.

Listas de verificación / planes paso a paso para usar bajo estrés

Lista A: Camino más rápido si ya tienes una shell de emergencia en el host

1. Ejecuta systemctl --failed para identificar el nombre de la unidad de montaje.
2. Ejecuta journalctl -xb y lee la línea del fallo de montaje. No la leas por encima.
3. Ejecuta lsblk -f y confirma que el UUID/LABEL correcto existe.
4. Edita /etc/fstab (haz primero una copia de seguridad).
5. Si el montaje es no crítico: añade nofail,x-systemd.device-timeout=10s.
6. Ejecuta mount -a. Si da error, no has terminado.
7. Ejecuta systemctl daemon-reload (no siempre necesario, pero aclara confusión cuando iteras).
8. Reinicia una vez.

Lista B: Camino más seguro usando un ISO de rescate (recomendado)

1. Arranca un ISO de rescate / entorno live.
2. lsblk -f para identificar la partición root instalada.
3. mount /dev/<root> /mnt.
4. Si hay particiones separadas: móntalas bajo /mnt (p. ej., /boot, /boot/efi).
5. Haz copia de seguridad de /mnt/etc/fstab.
6. Edita /mnt/etc/fstab con UUIDs correctos y opciones sensatas.
7. Valida con mount -a -T /mnt/etc/fstab -R /mnt.
8. Si hace falta: bind-mount /dev, /proc, /sys, luego chroot /mnt.
9. Sal del chroot, umount -R /mnt, reinicia.

Lista C: Cuando debes arrancar ya y arreglar después (modo triage)

1. En el entorno de rescate, comenta la(s) línea(s) que fallan en fstab o márcalas nofail.
2. Asegura que los montajes esenciales sigan estrictos (/, /var, /boot si se usa).
3. Valida con mount -a.
4. Arranca a multi-user y arregla correctamente con control de cambios: corrige UUIDs, verifica dependencias de aplicación y programa un remount/restart controlado.

Lista D: Verificación post-recuperación (no la omitas)

1. findmnt y confirma que cada montaje requerido está presente y correcto.
2. systemctl --failed está vacío (o solo muestra fallos no críticos esperados).
3. journalctl -b -p warning no muestra reintentos de montaje ni timeouts.
4. Confirma identidad de discos: lsblk -f coincide con fstab.
5. Si cambiaste comportamiento de montajes opcionales, confirma que la app maneja la ausencia correctamente (y que alarmas sobre ello).

Preguntas frecuentes (FAQ)

1) ¿Debo usar UUID, LABEL, PARTUUID o /dev/sdX en fstab?

Usa UUID para la mayoría de los sistemas de archivos. Usa LABEL si tienes una convención estricta de etiquetado y quieres legibilidad humana. Evita /dev/sdX en cualquier cosa que importe; la enumeración de dispositivos cambia tras cambios de hardware o firmware. PARTUUID es útil cuando quieres apuntar a la identidad de una partición incluso antes de que exista un sistema de archivos, pero para montajes normales UUID es la elección habitual.

2) Mi sistema cae a initramfs. ¿sigue siendo un problema de fstab?

A veces. Si no puede montarse root, aterrizas en initramfs antes de que systemd siquiera ejecute. Eso por lo general no es fstab (root está controlado por cmdline del kernel e initramfs), pero puedes tener problemas de fstab más tarde que te lleven a emergency mode. Primero determina dónde estás: prompt de initramfs vs shell de emergencia de systemd.

3) ¿Es seguro comentar la línea defectuosa en fstab para arrancar?

Seguro para montajes no críticos. Peligroso para montajes que las aplicaciones esperan por corrección (bases de datos, /var, colas persistentes). Si comentas un montaje requerido, el host arrancará en un estado “funciona hasta que no funciona” donde los servicios escriben datos en el lugar equivocado.

4) ¿Cuál es la diferencia entre modo rescate y modo emergencia?

Emergency mode es la shell root mínima con muy pocos servicios; rescue mode levanta más del sistema (como montajes básicos y a veces red, según configuración). Ambos están pensados para recuperación, pero emergency mode es lo que obtienes cuando systemd considera que el arranque normal es inseguro.

5) ¿Por qué systemd bloqueó el arranque por un montaje que no es tan importante?

Porque se lo dijiste. La suposición por defecto para entradas en fstab es que son sistemas de archivos locales requeridos. Si el montaje es opcional, añade nofail y considera x-systemd.device-timeout=. Si es un montaje de red, añade _netdev y considera x-systemd.automount para evitar bloqueo en tiempo de arranque.

6) ¿Cómo valido fstab sin reiniciar?

En un sistema en ejecución: mount -a intentará montar todo lo que no esté montado. Desde un ISO de rescate: monta el root instalado bajo /mnt y usa mount -a -T /mnt/etc/fstab -R /mnt para probar contra el fstab instalado sin necesidad de chroot.

7) Cambié UUIDs al reformatear un sistema de archivos. ¿Ahora qué?

Actualiza fstab para referenciar el nuevo UUID y valida con lsblk -f/blkid. Si era un sistema de archivos de datos usado por aplicaciones, confirma propietarios/permisos y que el punto de montaje es correcto — de lo contrario el servicio puede crear un árbol vacío en root y empezar a escribir ahí silenciosamente.

8) Mi montaje funciona manualmente pero falla al arrancar. ¿Por qué?

El contexto en tiempo de arranque es distinto. Razones comunes: punto de montaje faltante temprano, red no lista para NFS/CIFS, dependencias no expresadas (_netdev), volúmenes encriptados/LVM no activados a tiempo, o timeouts de systemd. Revisa journalctl -b por el error de arranque y compáralo con tu comando manual de montaje.

9) ¿Debo ejecutar fsck automáticamente cuando falla el arranque?

Solo cuando el error apunta a corrupción de sistema de archivos o journal no limpio. Si el log dice “device does not exist”, fsck es inútil. Si dice “bad superblock” o “needs journal recovery”, entonces sí—ejecuta la herramienta correcta para el filesystem, y siempre sobre un sistema de archivos desmontado.

10) ¿Puedo prevenir completamente esta clase de incidente?

Puedes reducirlo mucho: usa identificadores estables (UUID/LABEL), clasifica montajes como requeridos vs opcionales, establece timeouts sensatos y valida cambios de fstab con mount -a antes de reiniciar. Además, no despliegues ediciones de fstab sin una ruta de reversión y un plan de acceso por consola.

Conclusión: pasos siguientes para evitar que se repita

Arreglar una caída de arranque causada por fstab rara vez es difícil. Es solo implacable. El camino más rápido siempre es el mismo: lee el error, verifica la identidad, edita el archivo correcto, prueba montajes, reinicia una vez.

Haz lo siguiente:

• Clasifica montajes en tu infraestructura: requeridos vs opcionales. Usa nofail solo donde la ausencia sea realmente aceptable.
• Estandariza identificadores: UUID para la mayoría, etiquetas donde la legibilidad humana importe y controles de nombre estén bajo tu control.
• Añade resiliencia en tiempo de montaje para dispositivos opcionales: timeouts cortos, evitar bloqueo en arranque y alarmar en capa de servicio.
• Disciplina de cambios: cada edición de fstab lleva un cp -a de backup y luego validación con mount -a antes de reiniciar.
• Mantén una ruta de rescate: acceso IPMI/consola, un ISO de rescate conocido y un runbook que no asuma que la red estará disponible para salvarte.

Si tratas a /etc/fstab como código—revisado, validado y desplegado con intención—deja de ser una lotería de arranque y vuelve a ser lo que siempre quiso ser: una aburrida tabla de montajes.