Debian 13 “Dependency failed” al arrancar: encuentra el servicio único que bloquea el inicio (caso nº29)

Qué significa realmente “Dependency failed” en systemd

systemd es un planificador de dependencias. Convierte “iniciar la máquina” en un grafo dirigido de unidades (servicios, puntos de montaje, sockets, dispositivos, targets).
Cuando ves “Dependency failed”, normalmente estás viendo el síntoma hacia abajo, no la causa río arriba.

Ejemplo: remote-fs.target puede fallar porque una sola unidad .mount falló, que puede fallar porque no se encontró un dispositivo,
lo que puede deberse a que un mapeo LUKS no se desbloqueó, lo que puede ser porque un keyfile no estuvo disponible aún. systemd te dirá amablemente
“dependency failed” en cada salto. Es como oír “la reunión está cancelada” e intentar depurar todo el calendario de la empresa.

Tres relaciones entre unidades que importan durante el arranque

• Requires= — dependencia fuerte. Si A Requires=B y B falla, A falla.
• Wants= — dependencia blanda. Si B falla, A aún puede continuar.
• After=/Before= — solo orden. No implica dependencia, pero puede crear cadenas de “espera” que parecen cuelgues.

La mayoría de los bloqueos de arranque que se presentan como “Dependency failed” se reducen a una de estas: un montaje que no puede montarse, un dispositivo que nunca aparece, una espera de network-online,
o una importación de almacenamiento que caduca. Encuentra esa unidad única, y tendrás el hilo que tirar.

Broma #1: systemd no es “lento”; simplemente está extremadamente comprometido a esperar esa única cosa que prometiste que existiría.

Guion de diagnóstico rápido (haz esto primero)

Esta es la secuencia de alta señal cuando tienes una consola (física, IPMI o consola de VM) y necesitas al culpable rápido. Estás cazando
la unidad que está o bien fallando o bien esperando para siempre.

1) Llega a una shell sin perder tiempo

Si estás atascado en una pantalla de arranque, cambia a otro TTY (a menudo Ctrl+Alt+F2). Si estás en modo de emergencia, ya tienes una shell.
Si no puedes iniciar sesión, usa modo de recuperación en GRUB o añade systemd.unit=emergency.target una vez para este arranque.

2) Identifica qué falló en el arranque anterior

Ejecuta journalctl -b -1 -p err (si reiniciaste) o journalctl -b -p err (arranque actual). Quieres el primer error,
no la última queja.

3) Pregunta a systemd qué bloqueó la ruta crítica de arranque

systemd-analyze critical-chain señala la unidad que dominó el tiempo de arranque. Si ves un montaje o un target network-online sentado allí durante 1–2 minutos,
ese es tu bloqueador. Si ves un servicio “esperando”, inspecciona sus dependencias con systemctl list-dependencies.

4) Confirma la unidad única y su causa río arriba

Para esa unidad, ejecuta systemctl status UNIT y luego journalctl -u UNIT -b. Si es un montaje: revisa /etc/fstab.
Si es almacenamiento: comprueba la presencia del dispositivo. Si es network-online: verifica que la pila de red usada realmente sea la correcta.

5) Toma una decisión: arreglar ahora, evitar ahora o aislar

• Arreglar ahora: corrige fstab, desbloquea LUKS, importa el pool, corrige el archivo de unidad.
• Evitar ahora: comenta temporalmente una línea fallida de fstab, añade nofail, o enmascara una unidad no crítica.
• Aislar: arranca en multi-user.target sin el target problemático, o usa modo de emergencia para recuperar el control.

Tu objetivo es la disponibilidad primero, la perfección después. Al sistema no le importa que tu montaje NFS sea “importante” si está impidiendo que SSH se inicie.

Hechos interesantes y contexto histórico (para tu modelo mental)

1. systemd no solo reemplazó a SysV init; reemplazó la filosofía de arranque. En lugar de scripts lineales, el arranque se convirtió en un grafo de dependencias con jobs y timeouts.
2. La frase “Dependency failed” es systemd informando una propagación de fallo de job, no una falla del tipo “kernel panic”. Es de nivel superior y por lo general solucionable sin reinstalar.
3. Debian adoptó systemd por defecto en Debian 8 (Jessie), después de años de debate. El impacto operativo principal: menos “esperas misteriosas” en scripts init, más orden explícito.
4. Targets como network-online.target existen porque “la red está configurada” y “la red es utilizable” son estados diferentes; muchos servicios dependen erróneamente del segundo.
5. remote-fs.target y local-fs.target son puntos de coordinación, no “servicios reales”. Un único mal montaje puede tomarlos como rehén.
6. El manejo de montajes de systemd está estrechamente integrado con /etc/fstab. Un error tipográfico allí puede manifestarse como una falla de unidad, no como un mensaje amigable de mount.
7. LUKS y dm-crypt suelen orquestarse durante el arranque por initramfs y unidades systemd; un keyfile faltante puede convertirse en un “dependency failed” a dos pasos de la causa real.
8. La configuración predeterminada de journald en Debian históricamente equilibró uso de disco vs. forense. Si los registros son solo volátiles, puedes perder la evidencia tras un reinicio forzado.

Una idea fiable para tu modelo: Los resultados de un sistema están determinados mayormente por el sistema, no por esfuerzos heroicos. Eso aplica al arranque también—arregla el sistema de dependencias, no solo la falla de hoy.

El método del “bloqueador único”: aislar la unidad que detiene el arranque

“Dependency failed” es ruidoso pero poco útil. La pregunta útil es: qué unidad es la más temprana en la cadena de fallos y/o qué unidad es la que más tiempo ocupa en la cadena crítica?
A menudo coinciden, pero no siempre.

Dos patrones que verás

Patrón A: una unidad falla rápidamente y otras fallan como consecuencia

Este es el caso limpio. Ejemplo: mnt-data.mount falla porque no existe el UUID. Entonces local-fs.target informa fallo de dependencia,
y caes al modo de emergencia.

Patrón B: una unidad no falla; espera hasta el timeout

Este es el caso de “parece colgado”. Ejemplo: systemd-networkd-wait-online.service espera 2 minutos por un carrier que nunca aparece.
El sistema finalmente arranca, pero tarde, y obtendrás fallos de dependencia si otros servicios exigen “online” en lugar de “configurado”.

Regla operativa: culpa a la primera unidad que falla río arriba, no al target

Cuando un target falla, casi nunca es culpa del target. El target es un buzón. La carta dentro es un montaje fallido, una importación fallida,
una ruta de dispositivo obsoleta, o un servicio con una dependencia fuerte que no debería tener.

La manera más rápida de encontrar “la unidad” es:
(1) listar unidades fallidas,
(2) inspeccionar la cadena crítica,
(3) leer el journal para esa unidad,
(4) mapear el grafo de dependencias lo justo para ver qué falta realmente.

Tareas prácticas (comandos, qué significa la salida, la decisión que tomas)

Estos son comandos de campo que puedes ejecutar en Debian 13. Cada tarea incluye lo que estás observando y la decisión que sigue. Úsalos en orden cuando sea posible.
Cuando el sistema está medio arrancado, prefiere journalctl y systemctl sobre conjeturas.

Task 1 — Lista de unidades fallidas (tu primera lista corta)

cr0x@server:~$ systemctl --failed
  UNIT                              LOAD   ACTIVE SUB    DESCRIPTION
● mnt-data.mount                    loaded failed failed /mnt/data
● systemd-networkd-wait-online.service loaded failed failed Wait for Network to be Configured

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

2 loaded units listed.

Qué significa: Tienes sospechosos concretos. Ignora “targets” salvo que sean lo único listado.
Decisión: elige la unidad que coincida con el síntoma de arranque: el modo de emergencia suele apuntar a montajes; arranques lentos suelen apuntar a wait-online.

Task 2 — Ver qué bloqueó el tiempo de arranque (critical chain)

cr0x@server:~$ systemd-analyze critical-chain
graphical.target @2min 4.112s
└─multi-user.target @2min 4.112s
  └─remote-fs.target @2min 3.900s
    └─mnt-nfs.mount @2min 3.880s +2min
      └─network-online.target @3.870s
        └─systemd-networkd-wait-online.service @1.500s +2.360s
          └─systemd-networkd.service @1.200s +250ms
            └─systemd-udevd.service @900ms +280ms
              └─systemd-tmpfiles-setup-dev.service @650ms +220ms
                └─kmod-static-nodes.service @420ms +200ms
                  └─systemd-journald.socket @380ms
                    └─system.slice @370ms

Qué significa: mnt-nfs.mount consumió 2 minutos. Ese es tu cuello de botella, aunque “Dependency failed” apunte a otra cosa.
Decisión: investiga ese montaje y por qué requiere network-online; decide si debe ser nofail o automontado.

Task 3 — Muestra las líneas de error exactas del arranque actual

cr0x@server:~$ journalctl -b -p err --no-pager
Mar 12 08:41:02 server systemd[1]: mnt-data.mount: Mount process exited, code=exited, status=32/n/a
Mar 12 08:41:02 server systemd[1]: mnt-data.mount: Failed with result 'exit-code'.
Mar 12 08:41:02 server systemd[1]: Failed to mount /mnt/data.
Mar 12 08:41:10 server systemd-networkd-wait-online[412]: Timeout occurred while waiting for network connectivity.

Qué significa: Hay al menos dos problemas independientes: un montaje local fallido y un timeout de espera de red.
Decisión: arregla los montajes locales primero si estás en modo de emergencia; arregla wait-online después si el arranque solo está lento.

Task 4 — Inspecciona el estado de una unidad sospechosa (qué piensa systemd que pasó)

cr0x@server:~$ systemctl status mnt-data.mount --no-pager
× mnt-data.mount - /mnt/data
     Loaded: loaded (/etc/fstab; generated)
     Active: failed (Result: exit-code) since Wed 2025-03-12 08:41:02 UTC; 2min 12s ago
      Where: /mnt/data
       What: UUID=2f2c3a5b-8d5e-4e1b-b4d2-2e1b1f4d2f20
      Tasks: 0 (limit: 9250)
     Memory: 0B
        CPU: 8ms
     Error: 32 (Mount failure)
Mar 12 08:41:02 server systemd[1]: Mounting /mnt/data...
Mar 12 08:41:02 server mount[771]: mount: /mnt/data: special device UUID=2f2c3a5b-8d5e-4e1b-b4d2-2e1b1f4d2f20 does not exist.
Mar 12 08:41:02 server systemd[1]: mnt-data.mount: Mount process exited, code=exited, status=32/n/a
Mar 12 08:41:02 server systemd[1]: mnt-data.mount: Failed with result 'exit-code'.

Qué significa: Es una unidad de montaje generada desde /etc/fstab, y el UUID no está presente.
Decisión: confirma si el disco desapareció, fue renombrado, no está desencriptado, o si el UUID cambió; corrige fstab en consecuencia.

Task 5 — Confirma que el dispositivo existe (no confíes en fstab)

cr0x@server:~$ lsblk -f
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1      vfat   FAT32       9C2B-1A1B                             504.7M     1% /boot/efi
├─sda2      ext4   1.0         6e6a86fb-4d93-4b8b-9b62-6a0c9b99afc2  712.4M    22% /boot
└─sda3      crypto 2           1f7c0a2c-3f9f-4e5a-9d3c-6d7f8e9a1b2c
  └─cryptroot
            ext4   1.0         2b1c4d9a-9d10-4d0a-ae91-5f8b21c4b1a1   38.9G    41% /
sdb
└─sdb1      ext4   1.0   DATA  9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d

Qué significa: El UUID en fstab no coincide con lo que realmente está en disco. El sistema de archivos DATA está presente pero con otro UUID.
Decisión: actualiza /etc/fstab al UUID correcto (o usa LABEL=DATA si tu disciplina de etiquetado es sólida).

Task 6 — Inspecciona /etc/fstab con escepticismo

cr0x@server:~$ sed -n '1,200p' /etc/fstab
# /etc/fstab: static file system information.
UUID=2b1c4d9a-9d10-4d0a-ae91-5f8b21c4b1a1 /         ext4  errors=remount-ro 0 1
UUID=6e6a86fb-4d93-4b8b-9b62-6a0c9b99afc2 /boot     ext4  defaults          0 2
UUID=9C2B-1A1B /boot/efi vfat  umask=0077         0 1
UUID=2f2c3a5b-8d5e-4e1b-b4d2-2e1b1f4d2f20 /mnt/data ext4  defaults          0 2

Qué significa: Una línea referencia un UUID que no existe.
Decisión: si /mnt/data es opcional para el arranque, añade nofail,x-systemd.device-timeout=5s o cambia a automount; si es obligatorio, corrige el UUID y valida la cadena de dispositivos.

Task 7 — Prueba montajes sin reiniciar (captura errores de forma segura)

cr0x@server:~$ mount -a
mount: /mnt/data: can't find UUID=2f2c3a5b-8d5e-4e1b-b4d2-2e1b1f4d2f20.

Qué significa: El problema es reproducible fuera del arranque. Bien—depurar durante el arranque es miserable.
Decisión: corrige la entrada de fstab; luego vuelve a ejecutar mount -a hasta que esté limpio.

Task 8 — Para bloqueos por network-online: ve quién lo pide

cr0x@server:~$ systemctl list-dependencies --reverse network-online.target
network-online.target
● ├─mnt-nfs.mount
● ├─remote-fs.target
● └─docker.service

Qué significa: Tu montaje NFS y Docker están forzando “online”. Eso puede ser innecesario si pueden tolerar “red configurada”.
Decisión: desacopla servicios no críticos de network-online.target, o arregla la conectividad real si realmente debe estar online.

Task 9 — Revisa la configuración de la unidad wait-online (los timeouts son política)

cr0x@server:~$ systemctl cat systemd-networkd-wait-online.service
# /lib/systemd/system/systemd-networkd-wait-online.service
[Unit]
Description=Wait for Network to be Configured
Documentation=man:systemd-networkd-wait-online.service(8)
DefaultDependencies=no
Conflicts=shutdown.target
Before=network-online.target shutdown.target

[Service]
Type=oneshot
ExecStart=/lib/systemd/systemd-networkd-wait-online --timeout=120
RemainAfterExit=yes

[Install]
WantedBy=network-online.target

Qué significa: El timeout por defecto puede ser largo. 120 segundos se siente como un colgado en una incidencia.
Decisión: si tu entorno tiene enlaces intermitentes, establece un timeout más corto o deja de requerir network-online para servicios que pueden reintentar más tarde.

Task 10 — Comprueba si tu pila de red es realmente networkd

cr0x@server:~$ systemctl is-enabled systemd-networkd NetworkManager
enabled
disabled

Qué significa: Estás usando networkd, así que wait-online es relevante. Si NetworkManager estuviera habilitado, querrías la unidad de espera de NM en su lugar.
Decisión: asegúrate de no tener el “wait-online” equivocado para la pila de red que estás usando. Las descoordinaciones llevan a timeouts inútiles.

Task 11 — Construye un grafo de dependencias para la unidad sospechosa (alcance quirúrgico)

cr0x@server:~$ systemctl list-dependencies --all mnt-data.mount
mnt-data.mount
● ├─system.slice
● ├─-.mount
● ├─dev-disk-by\x2duuid-2f2c3a5b\x2d8d5e\x2d4e1b\x2db4d2\x2d2e1b1f4d2f20.device
● └─local-fs-pre.target

Qué significa: Este montaje está esperando directamente a una unidad de dispositivo que no existe.
Decisión: encuentra por qué no se crea la unidad de dispositivo (disco faltante, UUID erróneo, cifrado no abierto, driver faltante).

Task 12 — Valida el descubrimiento de dispositivos (udev y mensajes del kernel)

cr0x@server:~$ dmesg -T | tail -n 30
[Wed Mar 12 08:40:41 2025] sd 1:0:0:0: [sda] 1000215216 512-byte logical blocks: (512 GB/477 GiB)
[Wed Mar 12 08:40:41 2025] sd 2:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[Wed Mar 12 08:40:42 2025] EXT4-fs (sdb1): mounted filesystem 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d ro with ordered data mode
[Wed Mar 12 08:40:42 2025] EXT4-fs (sdb1): re-mounted 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d rw

Qué significa: El disco existe y el UUID del sistema de archivos es visible. El problema es tu configuración, no la detección de hardware.
Decisión: actualiza referencias (UUID/LABEL) y considera añadir salvaguardas (automount, nofail) para montajes no críticos.

Task 13 — Evita temporalmente un montaje no crítico que falla (recupera la máquina)

cr0x@server:~$ cp -a /etc/fstab /etc/fstab.bak
cr0x@server:~$ sed -i 's|^UUID=2f2c3a5b-8d5e-4e1b-b4d2-2e1b1f4d2f20|# UUID=2f2c3a5b-8d5e-4e1b-b4d2-2e1b1f4d2f20|' /etc/fstab
cr0x@server:~$ systemctl daemon-reload

Qué significa: Has deshabilitado el montaje por ahora. Es una movida pragmática, no una falla moral.
Decisión: reinicia para restaurar servicios básicos; luego arregla el montaje correctamente en una ventana controlada.

Task 14 — Haz que el montaje sea resistente en lugar de bloquear el arranque

cr0x@server:~$ grep -n '/mnt/data' /etc/fstab
12:UUID=9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d /mnt/data ext4 nofail,x-systemd.device-timeout=5s,x-systemd.automount 0 2

Qué significa: Este montaje no bloqueará el arranque; se montará al acceder, y si el disco falta no te lanzará al modo de emergencia.
Decisión: aplica esto solo a montajes que no sean necesarios para que el SO funcione. Bases de datos y sistemas críticos no son “material nofail”.

Task 15 — Para modo de emergencia causado por fstab: verifica la vista de systemd de local-fs

cr0x@server:~$ systemctl status local-fs.target --no-pager
× local-fs.target - Local File Systems
     Loaded: loaded (/lib/systemd/system/local-fs.target; static)
     Active: failed (Result: dependency) since Wed 2025-03-12 08:41:02 UTC; 3min ago
       Docs: man:systemd.special(7)
Mar 12 08:41:02 server systemd[1]: local-fs.target: Dependency failed for Local File Systems.

Qué significa: El target es una víctima. La falla real es una unidad .mount bajo él.
Decisión: deja de mirar local-fs.target; vuelve a las unidades .mount fallidas y arréglalas.

Task 16 — Si falta el journal: comprueba la persistencia de journald

cr0x@server:~$ ls -ld /var/log/journal
ls: cannot access '/var/log/journal': No such file or directory

Qué significa: Los registros pueden ser volátiles. Tras un reinicio, la evidencia se ha ido.
Decisión: habilita journaling persistente en servidores donde la forensia de arranque importe (la mayoría). De lo contrario estarás depurando con intuiciones.

Task 17 — Habilita journal persistente (para que la próxima vez sea menos tonta)

cr0x@server:~$ sudo mkdir -p /var/log/journal
cr0x@server:~$ sudo systemd-tmpfiles --create --prefix /var/log/journal
cr0x@server:~$ sudo systemctl restart systemd-journald

Qué significa: Journald empezará a escribir logs persistentes (sujeto a configuración y espacio en disco).
Decisión: confirma la política de uso de disco; en root pequeños, establece límites para evitar llenar /.

Caso #29: una típica cadena de bloqueo en Debian 13

Vamos a precisar cómo se ve en la práctica “identificar la unidad que bloquea el inicio”. El caso #29 es un patrón que veo en hosts Debian
que “hacen un poco de todo”: disco de datos local, algunos montajes remotos, y un servicio que insiste en que la red sea perfecta antes de arrancar.

El conjunto de síntomas

• En la consola: “A start job is running for /mnt/data” o “Dependency failed for Local File Systems.”
• A veces cae al modo de emergencia, a veces arranca después de ~2 minutos.
• Post-arranque: systemctl --failed muestra un montaje con fallo y opcionalmente un fallo de wait-online.

La cadena de causa raíz (cómo sucede)

Alguien cambió un disco, restauró desde backup, o re-creó un sistema de archivos. El UUID cambió. El UUID antiguo quedó en /etc/fstab.
systemd generó una unidad de montaje para esa entrada e intentó satisfacerla durante el arranque. No pudo encontrar el dispositivo; el montaje falló.
Como el montaje se trató como requerido (por defecto), local-fs.target falló y la secuencia de arranque tomó la salida dramática al modo de emergencia.

Por separado, había un montaje NFS que usaba _netdev y systemd tradujo eso a necesitar la red. Una unidad o dos tiraron de
network-online.target, que arrastró systemd-networkd-wait-online.service. En un host sin cable conectado (o con VLAN mal configurada),
wait-online caducó a 120 segundos. Eso no es un “fallo” en sentido humano; es una política que olvidaste que tenías.

Entonces, ¿cuál es “la unidad” que bloquea el inicio?

En este caso, es mnt-data.mount cuando caes al modo de emergencia. La línea “Dependency failed” menciona local-fs.target,
pero el bloqueador es la unidad de montaje generada desde /etc/fstab.

Si no caes al modo de emergencia pero el arranque es lento, la unidad suele ser systemd-networkd-wait-online.service o un montaje remoto
esperando detrás de él.

Tu diagnóstico debe coincidir con el impacto operativo:
paro en el arranque → arregla la dependencia fuerte (normalmente montajes locales);
arranque lento → elimina dependencias innecesarias de online, acorta timeouts, o convierte montajes a automount/nofail.

Broma #2: Nada dice “alta disponibilidad” como un servidor que se niega a arrancar hasta que un recurso remoto que nunca usa sea accesible.

Tres mini-historias corporativas (qué ocurre realmente en empresas)

1) El incidente por una suposición errónea: “Los UUIDs son para siempre”

Una empresa SaaS mediana ejecutaba Debian en una pequeña flota de trabajadores con estado. Tenían un disco de datos montado en /srv/data, referenciado por UUID en /etc/fstab.
El equipo de operaciones prefería UUIDs porque los nombres de dispositivo como /dev/sdb1 son volátiles—el orden de enchufado cambia, los controladores reordenan, caos.

Durante una renovación de hardware, un técnico clonó discos y “limpió” particiones. El sistema de archivos se recreó en lugar de clonarse bit a bit.
Nadie lo notó porque el punto de montaje existía y el directorio parecía bien en el banco de pruebas. El UUID cambió.

El primer reinicio en producción tras una actualización del kernel fue feo. Varios trabajadores cayeron en modo de emergencia con “Dependency failed for Local File Systems.”
El ingeniero on-call inicialmente persiguió lo equivocado: vio local-fs.target fallando y asumió que systemd estaba “roto.”
Intentaron reiniciar targets como si fueran servicios. Es como reiniciar una hoja de cálculo para arreglar un error en la celda B7.

La solución fue simple: actualizar los UUIDs en /etc/fstab. La lección no fue “no uses UUIDs.” La lección fue tratar la identidad de almacenamiento como configuración
que debe validarse después del mantenimiento. Añadieron una comprobación previa al reinicio que comparaba las entradas de fstab con la salida de lsblk -f y se negaba a proceder
cuando faltaba un UUID referenciado.

Nadie fue despedido. Pero todos dejaron de decir “es solo un reinicio.”

2) La optimización que salió mal: “Arrancar servicios lo antes posible”

Otra organización—empresa grande, con cumplimiento estricto, muchas herramientas internas—quiso tiempos de arranque más rápidos para un appliance basado en Debian.
Alguien vio el gráfico de arranque y decidió que la espera de red era “tiempo perdido”. Deshabilitaron la unidad wait-online y eliminaron dependencias de network-online.target.
El arranque fue más rápido. Los benchmarks lucieron bien. Presentación aprobada.

Luego llegó la realidad. El appliance ejecutaba un servicio que requería una IP estable y DNS antes de poder registrarse con un controlador central.
Sin esperar a que la red fuera usable, el servicio arrancó inmediatamente, intentó resolver un nombre, falló y salió. systemd lo reinició diligentemente.
La máquina no estaba “caída”, pero entró en un bucle de reinicio durante varios minutos—a veces más en redes congestionadas.

Lo peor: fue intermitente. Si DHCP era rápido, funcionaba. Si no, no. El equipo disfrutó la clásica experiencia empresarial:
un problema que aparece justo después de declarar la victoria.

Lo revertieron, pero no reactivando una espera de 120 segundos a ciegas. Hicieron la dependencia precisa:
servicios que realmente necesitaban la red online usaron una espera afinada con timeout más corto y mejor selección de interfaz;
servicios que podían reintentar más tarde dejaron de tirar de network-online.

La optimización es un impuesto. Si no lo pagas en diseño, lo pagarás en incidentes.

3) La práctica aburrida pero correcta que salvó el día: logs persistentes + notas de cambio

Un equipo de servicios financieros ejecutaba Debian en bare metal con root cifrado y un par de montajes auxiliares. Tenían una regla antigua:
journaling persistente habilitado por todas partes, y cada cambio relacionado con almacenamiento requería una nota de un renglón en un registro interno de cambios: “qué cambió, cómo deshacer.”
Aburrido. Ligeramente molesto. Perfecto.

Un lunes, un host arrancó en modo de emergencia después de un mantenimiento de fin de semana. La consola mostraba “Dependency failed,” pero el ingeniero no tuvo que adivinar.
Los logs del arranque anterior estaban ahí. El journal señalaba una única unidad de montaje fallando, y la línea de error incluía la ruta exacta del dispositivo que no encontró.

El registro de cambios decía que se había añadido un nuevo LUN iSCSI y una entrada de montaje. La persona que lo hizo también escribió el rollback: “comenta la línea de fstab y reinicia.”
En minutos, el host volvió a estar activo, y el equipo investigó el problema de descubrimiento iSCSI a la luz del día.

La práctica no fue glamorosa. No “escaló operaciones impulsadas por IA.” Hizo algo mejor: abarató el próximo fallo.

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

1) Síntoma: “Dependency failed for Local File Systems” y modo de emergencia

Causa raíz: Un montaje requerido desde /etc/fstab falló (UUID/LABEL equivocado, disco faltante, fallo de fsck, cifrado no desbloqueado).

Solución: Identifica la unidad .mount fallida con systemctl --failed. Arregla fstab. Si es no crítico, añade nofail y un timeout corto de dispositivo.

2) Síntoma: demora de arranque de 90–120 segundos, luego el sistema arranca

Causa raíz: *-wait-online.service caduca, usualmente porque no hay carrier, VLAN equivocada, o espera por una interfaz que no debería contar.

Solución: Comprueba qué unidad wait-online está activa (networkd vs NetworkManager). Reduce el timeout, ajusta interfaces requeridas, o elimina la dependencia innecesaria de network-online.target.

3) Síntoma: “Dependency failed for Remote File Systems”

Causa raíz: Una unidad de montaje remota (NFS/SMB/iSCSI) falló. Podría ser DNS, red, credenciales, o servidor caído.

Solución: Haz montajes remotos con nofail + x-systemd.automount donde corresponda; asegúrate de usar _netdev; valida la resolución de nombres en arranque temprano.

4) Síntoma: “A start job is running for dev-disk-by…” y luego timeout

Causa raíz: systemd espera una unidad de dispositivo que nunca aparece. A menudo un UUID obsoleto, mapeo multipath faltante, o driver de almacenamiento no incluido en initramfs.

Solución: Confirma con lsblk -f y dmesg. Actualiza identificadores. Para almacenamiento de arranque temprano, asegúrate de que initramfs incluya módulos y configs necesarios.

5) Síntoma: el arranque falla después de añadir una nueva entrada de sistema de archivos; el montaje manual funciona después

Causa raíz: Problema de orden: el dispositivo está disponible después de que se intenta montar (ej., iSCSI o udev retrasado). O necesitas x-systemd.requires= en un servicio específico.

Solución: Usa x-systemd.automount o añade dependencias adecuadas; evita hacks de “sleep 10” en unit files.

6) Síntoma: “Lo arreglé”, pero en el siguiente reinicio falla de nuevo

Causa raíz: Editaste estado en tiempo de ejecución o una unidad generada, no la fuente (ej., editaste en /run), o olvidaste daemon-reload, o initramfs aún contiene config antigua.

Solución: Edita /etc/fstab y drop-ins bajo /etc/systemd/system. Ejecuta systemctl daemon-reload. Si hay cifrado/initramfs involucrado, reconstruye initramfs.

7) Síntoma: mensajes “Dependency failed” pero todo parece estar bien

Causa raíz: Unidades opcionales están fallando (ej., un montaje marcado como requerido por defecto), o un servicio one-shot está mal configurado pero no es crítico.

Solución: Decide si la unidad debería ser requerida. Convierte Requires= en Wants= cuando sea seguro. Añade nofail a montajes opcionales. Limpia unidades fallidas para reducir ruido.

Listas de verificación / plan paso a paso

Lista A — Recupera el sistema ahora (los minutos importan)

1. Consigue una shell (modo de emergencia, modo de recuperación, o TTY de consola).
2. Ejecuta systemctl --failed y anota la .mount/.service fallida.
3. Ejecuta journalctl -b -p err --no-pager y encuentra el error relevante más temprano.
4. Si un montaje falla y no es crítico: coméntalo en /etc/fstab, ejecuta systemctl daemon-reload, reinicia.
5. Si un montaje es crítico: confirma presencia del dispositivo con lsblk -f, corrige UUID/LABEL, ejecuta mount -a, y continúa el arranque.

Lista B — Identifica “la unidad” que bloquea el arranque (sé preciso)

1. Ejecuta systemd-analyze critical-chain y anota la unidad con mayor tiempo.
2. Confirma que realmente está bloqueando: verifica si está en la ruta hacia multi-user.target o tu target por defecto.
3. Inspecciónala: systemctl status UNIT.
4. Extrae su journal: journalctl -u UNIT -b --no-pager.
5. Mapea dependencias directas: systemctl list-dependencies --all UNIT y --reverse para el target que retrasa.
6. Detente cuando encuentres el recurso faltante (dispositivo, red, credencial, archivo de configuración). Esa es la causa raíz.

Lista C — Arregla correctamente (para que el próximo reinicio no sea una repetición)

1. Para montajes: usa identificadores estables (UUID/LABEL) y confirma con lsblk -f.
2. Para montajes remotos: prefiere x-systemd.automount y nofail salvo que la máquina realmente no pueda funcionar sin ellos.
3. Para network-online: solo requerirlo cuando el servicio realmente necesite rutas/DNS operativas al inicio.
4. Establece timeouts sensatos: cortos para dependencias opcionales, largos solo donde esté justificado.
5. Habilita journaling persistente en servidores; conserva evidencia de arranque.
6. Prueba con systemd-analyze blame y un reinicio controlado.

Lista D — Prevenir recurrencias (el impuesto SRE que sí vale la pena)

1. Añade un script de validación pre-reinicio: confirma que todos los UUIDs en /etc/fstab existan.
2. Estandariza opciones de montaje para discos de datos opcionales (automount + timeout corto).
3. Usa overrides drop-in en lugar de editar archivos de unidad del proveedor.
4. Documenta pasos de rollback para cambios de almacenamiento y red.
5. Tras cualquier migración de almacenamiento, realiza un ensayo de reinicio en una ventana de mantenimiento.

Preguntas frecuentes

1) ¿Es “Dependency failed” un problema del kernel?

Usualmente no. Es systemd informando que una unidad no pudo iniciarse porque algo que requiere falló. Los problemas del kernel tienden a mostrarse como panics, errores de driver, o dispositivo root faltante.

2) ¿Por qué menciona local-fs.target en vez de la falla real?

Los targets agregan otras unidades. Cuando una unidad requerida falla, el target informa fallo de dependencia. La falla real suele ser una .mount o una .service específica.

3) ¿Cuál es la forma más rápida de encontrar el bloqueador?

Combina systemctl --failed con systemd-analyze critical-chain, y luego lee el journal del sospechoso principal. No empieces editando archivos de unidad al azar.

4) ¿Por qué mi sistema espera 120 segundos por la red?

Ese es el timeout por defecto en muchas unidades wait-online. Es una elección de política, no una ley de la física. Si no necesitas “online”, no dependas de ello; si sí, afínalo.

5) ¿Debería usar nofail en /etc/fstab?

Para montajes opcionales, sí—especialmente volúmenes extraíbles, remotos, o “agradables de tener”. Para montajes obligatorios (root, datos críticos de aplicación), no. Arregla la dependencia en su lugar.

6) ¿Qué me aporta x-systemd.automount?

Difere el montaje hasta el primer acceso. El arranque no se bloquea en él. Si el recurso falta temporalmente, el sistema aún arranca y puedes remediar de forma remota.

7) Mi montaje funciona después del arranque, pero falla durante el arranque. ¿Por qué?

Orden. El dispositivo o la ruta de red no están listos cuando se intenta montar. Automount suele ser la solución más limpia. Si no, añade dependencias correctas—evita hacks de sleep.

8) ¿Cómo sé si uso NetworkManager o networkd?

Comprueba qué servicio está habilitado y activo. Si NetworkManager gestiona interfaces, la espera de networkd puede ser irrelevante y caducará en vano.

9) Arreglé /etc/fstab pero systemd sigue fallando igual. ¿Qué me faltó?

Ejecuta systemctl daemon-reload y vuelve a probar con mount -a. Si la falla involucra initramfs (dispositivos cifrados o de arranque temprano), reconstruye initramfs también.

10) ¿Puedo simplemente enmascarar la unidad que falla?

Puedes, y a veces deberías—temporalmente. Enmascarar es un bypass, no una cura. Es aceptable para unidades no críticas mientras restauras disponibilidad y planificas una solución adecuada.

Siguientes pasos (qué hacer después de recuperar el arranque)

Una vez que el sistema esté arriba, no te quedes en “arranca ahora”. Captura la causa raíz mientras está fresca:
identifica la unidad única que bloqueó el arranque, documenta por qué bloqueó, y decide si debería permitírsele bloquear de nuevo.

1. Registra la unidad culpable y la dependencia que falló (UUID, interfaz, endpoint remoto).
2. Haz opcionales las dependencias que pueden serlo: nofail, automount, timeouts de dispositivo cortos.
3. Haz fiables las dependencias requeridas: identificadores correctos, orden correcto, contenido correcto en initramfs.
4. Habilita journaling persistente si no lo hiciste; el próximo incidente debería ser más barato.
5. Reinicia una vez en una ventana controlada para validar la corrección. La confianza se gana, no se asume.

Debian arranca bien. Tu configuración es lo que lo convierte en un drama judicial. systemd es solo el secretario leyendo las consecuencias.