Proxmox systemd “Dependency failed”: Detectar el servicio que rompe el arranque

enero 24, 2026 • febrero 3, 2026 • Lectura: 27 min • Views: 9

¿Te fue útil?

Reinicias un nodo Proxmox y vuelve con esa línea gris presumida:
Dependency failed for …. La interfaz web está muerta, las máquinas virtuales caídas y miras una consola que viene a decir,
“Algo más no ocurrió, así que yo tampoco ocurrió.”

La trampa es que la unidad que aparece en pantalla suele ser la víctima, no la culpable. systemd informa qué no pudo iniciarse,
no qué inició la reacción en cadena. Esta guía explica cómo encontrar el primer dominó—rápido, repetible y sin adivinar.

El modelo mental: qué significa realmente “Dependency failed”

systemd es un motor de dependencias con tendencia a registrar hechos. Inicia unidades (servicios, montajes, dispositivos, targets) basándose en relaciones declaradas
(Requires=, Wants=, After=, Before=, además de enlaces implícitos desde las unidades .mount, las unidades de dispositivo
y los generators).

Un mensaje “Dependency failed” para la unidad X significa que una de las dependencias requeridas de X entró en estado fallido
(o nunca apareció dentro de un timeout). Eso puede ser:

Un servicio que falló (código de salida distinto de cero, timeout, watchdog, configuración faltante).
Un montaje que no se montó (sistema de archivos dañado, dispositivo faltante, UUID incorrecto, ZFS/LVM no importados).
Una unidad de dispositivo que nunca apareció (disco ausente, firmware del HBA haciendo maniobras).
Un target que no puede alcanzarse porque algo necesario para alcanzarlo falló.

La línea que ves en la consola casi siempre es aguas abajo. Tu trabajo es caminar río arriba hasta encontrar la primera unidad que falló y luego
preguntar: ¿esto es una falla real (dañado), o un problema de ordenamiento (dependencias incorrectas)?

Una cita útil para tener en la cabeza, atribuida a John Gall (idea parafraseada): Los sistemas complejos que funcionan suelen evolucionar a partir de sistemas más simples que funcionaban.
Si tu arranque es complejo, depúralo como una evolución: encuentra la falla más temprana, no el último síntoma.

Guía rápida de diagnóstico (primeras/segundas/terceras comprobaciones)

Si esto es producción y te sangran los minutos, haz esto en orden. El objetivo es identificar la primera unidad que falla y
si es almacenamiento, red, clúster o un simple error de configuración.

Primero: lista las fallas e inspecciona la más temprana

cr0x@server:~$ systemctl --failed
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● pve-cluster.service          loaded failed failed The Proxmox VE cluster filesystem
● zfs-import-cache.service     loaded failed failed Import ZFS pools by cache file

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

Decisión: si solo hay una o dos unidades fallidas, comienza con la que parece más “fundacional” (importación de almacenamiento, montaje,
network-online). Si hay muchas, la “fundacional” casi siempre es la primera falla.

Segundo: lee los logs del arranque previo, no tu sesión de shell actual

cr0x@server:~$ journalctl -b -0 -p err..alert --no-pager | head -n 50
Dec 26 09:14:03 server systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.
Dec 26 09:14:03 server systemd[1]: Failed to start Import ZFS pools by cache file.
Dec 26 09:14:03 server systemd[1]: Dependency failed for ZFS Mount.
Dec 26 09:14:03 server systemd[1]: Dependency failed for Proxmox VE firewall.

Decisión: prioriza la línea primera “Failed to start …”. Las entradas posteriores “Dependency failed for …” son aguas abajo.

Tercero: dibuja la cadena de dependencias para la unidad víctima

cr0x@server:~$ systemctl list-dependencies --reverse pve-firewall.service
pve-firewall.service
● pve-container.service
● pve-guests.service
● multi-user.target

Decisión: si la víctima es un servicio “hoja” (firewall, UI, gestión de invitados), deja de culparlo. Sube hasta la dependencia que
realmente falló (importación de almacenamiento, montaje, network-online).

Heurística que ahorra tiempo: almacenamiento antes que clúster antes que red antes que “servicio aleatorio”

En nodos Proxmox, los bloqueadores de arranque se agrupan en cuatro cubos:
importaciones de almacenamiento (ZFS/LVM), montajes (incluyendo /var/lib/vz),
filesystem de clúster (pve-cluster, corosync), y preparación de red.
Los servicios a nivel de aplicación tienden a fallar porque uno de esos no lo hizo.

Broma #1: systemd es como un bibliotecario muy estricto—si susurras “After=network-online.target” sin arreglarlo bien, callará tu arranque.

Hechos interesantes y contexto histórico (para mejores instintos)

systemd reemplazó a SysV init en la mayoría de las distribuciones Linux a principios de los 2010, trayendo arranque en paralelo y grafos de dependencias explícitos en lugar del orden por scripts de shell.
“After=” no es un requisito. Solo ordena el momento de inicio. La gente aún lo confunde con Requires=, y de esa confusión nacen fallas de arranque.
Los montajes son unidades de primera clase. systemd genera unidades .mount desde /etc/fstab, y esas se convierten en dependencias para servicios que las necesitan.
Las unidades de dispositivo aparecen dinámicamente. Un disco faltante no “falla”; simplemente nunca aparece. Las unidades aguas abajo agotan el tiempo y entonces parece un fallo de servicio.
ZFS en Linux usa servicios de importación (zfs-import-cache / zfs-import-scan) para poner los pools en línea durante el arranque; archivos de caché faltantes o pools renombrados pueden detener todo lo que dependa de montajes.
Proxmox depende de /etc/pve, un filesystem de clúster respaldado por pmxcfs. Si pmxcfs no se monta, gran parte de la pila de gestión no puede leer la configuración.
“Red online” es polémico. Diferentes distros incluyen diferentes servicios wait-online. Habilitar el equivocado puede añadir retrasos de arranque o crear bloqueos cuando hay bridges/VLANs.
Los cambios en initramfs son sutiles. Un módulo faltante en initramfs puede convertir un disco root aparentemente correcto en “no encontrado”, y el mensaje de fallo de arranque parecerá no relacionado.
systemd puede mostrar la ruta crítica de tiempos desde hace años. Es una de las formas más rápidas de detectar un cuello de botella de arranque que no necesariamente “falla”.

Tareas prácticas: comandos, salida esperada, decisiones

Estas son comprobaciones probadas en campo. Cada una incluye un comando, qué significa la salida y qué hacer a continuación.
No ejecutes todo a ciegas; elige las que coincidan con el dominio de falla que ves.

Tarea 1: Listar unidades fallidas (el punto de partida obvio)

cr0x@server:~$ systemctl --failed --no-pager
  UNIT                     LOAD   ACTIVE SUB    DESCRIPTION
● zfs-mount.service        loaded failed failed Mount ZFS filesystems
● pveproxy.service         loaded failed failed PVE API Proxy Server

2 loaded units listed.

Significado: pveproxy probablemente es daño colateral. zfs-mount es fundamental.
Decisión: inspecciona zfs-mount primero, no el proxy.

Tarea 2: Inspeccionar la unidad que falló (status incluye últimos logs)

cr0x@server:~$ systemctl status zfs-mount.service --no-pager -l
× zfs-mount.service - Mount ZFS filesystems
     Loaded: loaded (/lib/systemd/system/zfs-mount.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-26 09:14:03 UTC; 1min 2s ago
    Process: 812 ExecStart=/sbin/zfs mount -a (code=exited, status=1/FAILURE)
   Main PID: 812 (code=exited, status=1/FAILURE)

Dec 26 09:14:03 server zfs[812]: cannot mount 'rpool/data': failed to create mountpoint: /rpool/data
Dec 26 09:14:03 server systemd[1]: zfs-mount.service: Failed with result 'exit-code'.

Significado: la acción que falla está explícita: ZFS no puede crear un punto de montaje.
Decisión: comprueba si el punto de montaje es de solo lectura, falta el montaje root, o hay un conflicto de directorio/archivo.

Tarea 3: Identificar la primera falla en la línea de tiempo de arranque

cr0x@server:~$ journalctl -b -0 --no-pager | grep -E "Failed to start|Dependency failed" | head -n 30
Dec 26 09:14:02 server systemd[1]: Failed to start Import ZFS pools by cache file.
Dec 26 09:14:03 server systemd[1]: Dependency failed for ZFS Mount.
Dec 26 09:14:03 server systemd[1]: Failed to start Mount ZFS filesystems.
Dec 26 09:14:03 server systemd[1]: Dependency failed for Proxmox VE cluster filesystem.

Significado: zfs-import-cache falló primero. Todo lo demás es cascada.
Decisión: inspecciona los logs de zfs-import-cache.service a continuación.

Tarea 4: Profundizar en los logs de una unidad con journalctl

cr0x@server:~$ journalctl -u zfs-import-cache.service -b -0 --no-pager -l
Dec 26 09:14:02 server systemd[1]: Starting Import ZFS pools by cache file...
Dec 26 09:14:02 server zpool[771]: cannot open '/etc/zfs/zpool.cache': No such file or directory
Dec 26 09:14:02 server systemd[1]: zfs-import-cache.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:14:02 server systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.

Significado: falta el archivo de caché. No siempre es fatal si zfs-import-scan existe, pero tu grafo de dependencias puede forzar la importación por caché.
Decisión: confirma si la importación por scan está habilitada, o regenera la caché desde una importación funcional.

Tarea 5: Comprobar si los pools ZFS son importables

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        rpool        ONLINE
          mirror-0   ONLINE
            sda3     ONLINE
            sdb3     ONLINE

Significado: el pool existe y está sano, pero no importado.
Decisión: intenta una importación manual (solo lectura primero si sospechas daño), luego corrige la configuración de importación en el arranque.

Tarea 6: Importación manual (con cuidado, pero efectiva para diagnóstico)

cr0x@server:~$ sudo zpool import -N rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda3    ONLINE       0     0     0
            sdb3    ONLINE       0     0     0

errors: No known data errors

Significado: la importación funciona. La falla de arranque probablemente sea configuración/ordenamiento (archivo de caché, habilitación de servicio), no discos muertos.
Decisión: reconstruye /etc/zfs/zpool.cache y asegúrate de que la unidad de importación correcta esté habilitada.

Tarea 7: Verificar wait-online/bloqueadores de red

cr0x@server:~$ systemd-analyze blame | head -n 15
        1min 32.104s systemd-networkd-wait-online.service
             8.771s pve-cluster.service
             4.210s zfs-mount.service
             2.018s networking.service

Significado: el arranque no está “fallando” tanto como colgándose en “network online.”
Decisión: confirma si tu nodo realmente necesita “online” (a menudo no). Si los servicios de Proxmox lo requieren incorrectamente, corrige dependencias o configuración.

Tarea 8: Mostrar la cadena crítica de arranque para un target específico

cr0x@server:~$ systemd-analyze critical-chain multi-user.target
multi-user.target @1min 42.909s
└─pve-guests.service @1min 42.870s +37ms
  └─pve-cluster.service @1min 33.982s +8.884s
    └─network-online.target @1min 32.111s
      └─systemd-networkd-wait-online.service @0min 0.008s +1min 32.104s

Significado: la “cadena crítica” muestra qué fue lo que realmente demoró alcanzar el target.
Decisión: ajusta el servicio wait-online o elimina el requerimiento si no es necesario para el éxito del arranque.

Tarea 9: Inspeccionar dependencias de la unidad mostrada como “Dependency failed”

cr0x@server:~$ systemctl show -p Requires -p Wants -p After -p Before pve-cluster.service
Requires=system.slice basic.target
Wants=corosync.service
After=network.target syslog.target corosync.service
Before=

Significado: pve-cluster quiere corosync y se inicia después de él, pero aquí no requiere explícitamente network-online.
Tu retardo puede estar en otra parte, o alguna otra unidad introduce network-online.
Decisión: sigue la cadena real con systemd-analyze critical-chain y revisa los drop-ins.

Tarea 10: Encontrar drop-ins que sobrescriben (donde se esconden los cambios “útiles”)

cr0x@server:~$ systemctl cat pve-cluster.service
# /lib/systemd/system/pve-cluster.service
[Unit]
Description=The Proxmox VE cluster filesystem
After=network.target corosync.service
Wants=corosync.service

[Service]
Type=forking
ExecStart=/usr/bin/pmxcfs -l
ExecStop=/usr/bin/killall -TERM pmxcfs
Restart=on-failure

# /etc/systemd/system/pve-cluster.service.d/override.conf
[Unit]
After=network-online.target
Wants=network-online.target

Significado: alguien añadió un drop-in que hace que pve-cluster espere por “online.”
Decisión: decide si eso está justificado. En la mayoría de instalaciones Proxmox no lo está; prefiere network.target a menos que realmente necesites conectividad enrutada durante el arranque.

Tarea 11: Confirmar qué es realmente “network-online” en tu máquina

cr0x@server:~$ systemctl status network-online.target --no-pager -l
● network-online.target - Network is Online
     Loaded: loaded (/lib/systemd/system/network-online.target; static)
     Active: active since Thu 2025-12-26 09:14:00 UTC; 4min ago
       Docs: man:systemd.special(7)

Dec 26 09:14:00 server systemd[1]: Reached target Network is Online.

Significado: el target se satisface cuando se satisface su servicio wait. Qué servicio wait depende de tu stack de red.
Decisión: comprueba si usas systemd-networkd, NetworkManager o ifupdown, y deshabilita la unidad wait-online equivocada.

Tarea 12: Validar montajes de almacenamiento ligados a Proxmox (fstab y unidades de montaje)

cr0x@server:~$ findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS /var/lib/vz
/var/lib/vz rpool/data/subvol-100-disk-0 zfs rw,xattr,noacl

Significado: las rutas de almacenamiento de Proxmox existen y están respaldadas por el sistema de archivos esperado.
Decisión: si esto falta o está mal, arregla la importación/montaje de ZFS/LVM antes de tocar servicios de Proxmox.

Tarea 13: Revisar fstab por bloqueadores de arranque (UUIDs malos, montajes obsoletos)

cr0x@server:~$ grep -vE '^\s*#|^\s*$' /etc/fstab
UUID=2f1f9e2d-aaaa-bbbb-cccc-5f9b9d1d2e3f / ext4 defaults 0 1
UUID=deadbeef-1111-2222-3333-444444444444 /mnt/backup ext4 defaults 0 2

Significado: un montaje como /mnt/backup puede bloquear el arranque si el disco desapareció.
Decisión: si no es crítico, añade nofail y un x-systemd.device-timeout= sensato. O elimínalo por completo.

Tarea 14: Confirmar si el dispositivo faltante existe

cr0x@server:~$ lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINT
NAME   SIZE FSTYPE UUID                                 MOUNTPOINT
sda   447.1G
├─sda1  512M vfat   8A1B-2C3D                            /boot/efi
├─sda2    1G ext4   0b7c9c2f-1234-5678-90ab-7e1f2c3d4e5f /boot
└─sda3 445.6G zfs_member
sdb   447.1G
└─sdb3 445.6G zfs_member

Significado: si el UUID del fstab no aparece aquí, el montaje fallará.
Decisión: corrige el UUID, arregla cableado/HBA, o marca el montaje nofail si es opcional.

Tarea 15: Comprobar pmxcfs y la salud de /etc/pve (específico de Proxmox)

cr0x@server:~$ mount | grep -E "/etc/pve|pmxcfs"
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

Significado: si /etc/pve no está montado, la configuración de Proxmox no está disponible; muchos servicios fallan “misteriosamente.”
Decisión: arregla pve-cluster.service antes de perseguir errores de pveproxy/pvedaemon.

Tarea 16: Confirmar el estado de corosync sin adivinar

cr0x@server:~$ systemctl status corosync.service --no-pager -l
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Thu 2025-12-26 09:14:01 UTC; 6min ago

Significado: si corosync está abajo, pve-cluster puede colgar o fallar según la configuración.
Decisión: inspecciona los logs de corosync y la red (multicast/unicast, interfaces de ring), pero no “reinicies todo” al azar.

Tarea 17: Encontrar qué unidad trajo un target (quién lo “quiso”)

cr0x@server:~$ systemctl list-dependencies --reverse network-online.target
network-online.target
● pve-cluster.service
● pvescheduler.service
● zfs-import.target

Significado: estas unidades están forzando la semántica “online”.
Decisión: revisa si cada una realmente lo necesita; elimina drop-ins que añadan esperas innecesarias.

Tarea 18: Verificar la salida del generator (traducción fstab→unidad)

cr0x@server:~$ systemctl status mnt-backup.mount --no-pager -l
× mnt-backup.mount - /mnt/backup
     Loaded: loaded (/run/systemd/generator/mnt-backup.mount; generated)
     Active: failed (Result: exit-code) since Thu 2025-12-26 09:14:05 UTC; 2min ago
      Where: /mnt/backup
       What: /dev/disk/by-uuid/deadbeef-1111-2222-3333-444444444444

Dec 26 09:14:05 server mount[901]: mount: /mnt/backup: special device /dev/disk/by-uuid/deadbeef-1111-2222-3333-444444444444 does not exist.

Significado: la unidad de montaje se genera desde fstab y falla porque el dispositivo falta.
Decisión: restaura la ruta/UUID del dispositivo, o haz el montaje opcional (nofail más timeout).

Tarea 19: Revisar initramfs y reconocimiento del dispositivo root (cuando el arranque está realmente roto)

cr0x@server:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E "zfs|dm_mod|nvme" | head
usr/lib/modules/6.8.12-4-pve/kernel/drivers/md/dm-mod.ko
usr/lib/modules/6.8.12-4-pve/kernel/drivers/nvme/host/nvme.ko
usr/lib/modules/6.8.12-4-pve/updates/dkms/zfs.ko

Significado: módulos críticos aparecen en initramfs. Si no están, el kernel no puede encontrar discos temprano.
Decisión: reconstruye initramfs y verifica los módulos DKMS, especialmente después de actualizaciones de kernel.

Tarea 20: Reconstruir initramfs (solo después de saber qué falta)

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_12.bin for module i915

Significado: las advertencias sobre firmware GPU suelen ser irrelevantes en servidores; el firmware faltante de almacenamiento/HBA no lo es.
Decisión: si ves firmware faltante para almacenamiento/red, arréglalo antes del siguiente reinicio. De lo contrario procede.

De dónde suelen venir las fallas de arranque en Proxmox

Cuando Proxmox “no arranca”, probablemente el kernel arrancó bien. systemd está arriba. La falla es que el sistema no alcanzó el target que
incluye tus servicios de gestión. Proxmox añade algunos puntos de presión especiales:

1) Importación de almacenamiento y montajes

Los nodos Proxmox casi siempre dependen de que el almacenamiento local esté arriba temprano: pools ZFS, grupos LVM, o ambos. Si el almacenamiento no se importa,
las unidades de montaje fallan, y entonces los servicios que leen configuración o almacenan estado fallan. La caída de la UI es un síntoma, no una causa.

Observa:

Fallos de importación ZFS por falta de /etc/zfs/zpool.cache, pools renombrados, o cambios en rutas de dispositivo.
Fallos LVM por PVs faltantes o problemas de activación de VG.
Entradas fstab para discos externos de backup que son “opcionales” hasta que no lo son.

2) /etc/pve y pmxcfs

/etc/pve no es un directorio normal. Es un filesystem fuse provisto por pmxcfs, controlado por pve-cluster.service.
Si pmxcfs no está montado, muchas herramientas de Proxmox actúan como si la configuración hubiera desaparecido.

La consola te dirá felizmente “Dependency failed for Proxmox VE API Proxy Server.”
Eso es cierto, pero poco útil. El proxy depende de la configuración y certificados. Sin /etc/pve, no hay fiesta.

3) Suposiciones de corosync

En un clúster, corosync es cómo los nodos acuerdan la membresía. Un nodo puede funcionar en modo mononodo, pero la presencia de configuración de clúster cambia el comportamiento de arranque.
Interfaces de ring mal configuradas, un nombre de NIC nuevo tras un cambio de hardware, o una dependencia “network-online” demasiado estricta pueden detener unidades relacionadas con el clúster.

4) network-online target y ordenamiento “útil” del arranque

El stack de red tiene capas: el enlace sube, se aplican direcciones, aparecen rutas, DNS tal vez funciona, y solo entonces tienes “online”.
network.target de systemd normalmente significa “red básica configurada”, no “internet alcanzable”.

Si alguien fuerza a los servicios de Proxmox a requerir network-online.target, puedes crear un deadlock de arranque donde el servicio de espera de red
espera por un bridge/VLAN que es creado por un servicio que está esperando por network-online. Enhorabuena, inventaste una dependencia circular.

Broma #2: Un bucle de dependencias es la única vez en que tu servidor modela con éxito los organigramas corporativos.

Caza de la unidad raíz: cadenas, ordenamiento y por qué tus ojos engañan

El error operativo más común en estos incidentes es tratar el mensaje en pantalla como la causa raíz. systemd imprime “Dependency failed for X”
porque X fue puesto en cola y luego cancelado. Es como un gestor de proyecto diciéndote “la demo está cancelada” sin mencionar el corte de energía.

Empieza por “unidades fallidas”, pero no te quedes ahí

systemctl --failed es necesario pero no suficiente. Muestra qué terminó en estado fallido. Pero la unidad que importa podría ser:

Una unidad .mount generada desde fstab (something.mount).
Una unidad de dispositivo que nunca apareció (sin estado explícito “failed”; en su lugar algo agota el tiempo).
Una unidad one-shot que falló temprano y quedó enterrada en los logs.

Prefiere “critical-chain” a “blame” cuando sospeches de ordenamiento

systemd-analyze blame lista la duración que pasaron las unidades, útil para arranques lentos. Pero puede engañarte si una unidad pasó tiempo esperando
a otra unidad. La cadena crítica te muestra la ruta de dependencia real hacia un target.

Si estás atascado en el arranque y algo espera para siempre, pregúntate:

¿Qué target intento alcanzar? Normalmente multi-user.target en servidores.
¿Qué unidad es la última en la cadena crítica?
¿Qué espera esa unidad? (status + journal)

Entiende los tres ejes de dependencia: requisito, orden y relación

systemd tiene relaciones que suenan similar pero se comportan distinto:

Requires=: si la unidad requerida falla, esta unidad falla.
Wants=: dependencia débil; la atrae pero no hace fallar al dependiente si ella falla.
After=/Before=: solo orden. No requisito.

Muchos incidentes “dependency failed” vienen de administradores que añaden After= sin Wants= o Requires=, esperando
que systemd inicie algo automáticamente. No lo hará.

Cuando el culpable real es un montaje o un dispositivo

Si un servicio tiene RequiresMountsFor=/var/lib/vz (o una dependencia implícita por uso de la ruta), y ese montaje falta, systemd se negará a iniciarlo. El servicio no está “roto.”
Está siendo cauteloso de forma correcta.

El mejor truco: inspecciona el estado de la unidad .mount y sus logs. A menudo es más explícito que el log de un servicio.

Cuando el culpable real es un timeout

Algunos mensajes “Dependency failed” aparecen porque una dependencia no falló explícitamente—simplemente nunca se activó.
Por ejemplo: una unidad de dispositivo nunca aparece porque un disco no enumeró. Entonces un montaje espera, agota el tiempo, falla, y eso falla un servicio.

En estos casos, las líneas de log importantes están más arriba: mensajes del kernel, udev, errores del driver de almacenamiento, o demoras de firmware. No ignores dmesg.

cr0x@server:~$ dmesg --level=err,warn | tail -n 30
[    7.112345] sd 2:0:0:0: [sdc] tag#23 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[    7.112400] blk_update_request: I/O error, dev sdc, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0

Decisión: si ves errores de transporte, deja de editar unidades systemd y comienza a comprobar cables/HBA/salud de discos.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana ejecutaba un clúster Proxmox de dos nodos en sitios remotos. Los nodos eran estables, aburridos y mayormente intocados—hasta una renovación de red.
El equipo reemplazó un switch y ajustó VLANs. Los nodos volvieron, pero uno quedó “medio arrancado.” La consola mostró “Dependency failed for Proxmox VE API Proxy Server.”
Naturalmente, la primera respuesta fue reiniciar pveproxy. Luego pvedaemon. Luego corosync. Luego el nodo se volvió a reiniciar, porque reiniciar es un estilo de vida.

La suposición equivocada: “pveproxy es el problema porque es lo que notan los usuarios.” No lo era. El culpable real fue un drop-in override añadido meses antes
a pve-cluster.service forzando After=network-online.target y Wants=network-online.target.
El cambio de switch retrasó DHCP en una VLAN de gestión que nunca debió haber sido DHCP en primer lugar.

systemd-networkd-wait-online esperó por una dirección que nunca llegó. Eso impidió network-online.target,
que impidió pve-cluster, que impidió que pmxcfs montara /etc/pve, que impidió que pveproxy leyera la configuración.
El mensaje “Dependency failed” fue exacto, pero acusó al transeúnte equivocado.

La solución fue poco glamorosa: quitar el override, devolver la interfaz de gestión a direccionamiento estático, y aceptar que “network.target” es suficiente
para la mayoría de los servicios locales. También añadieron una comprobación durante cambios de red: verificar que “online” signifique lo que crees. Rara vez lo hace.

Microhistoria 2: La optimización que salió mal

Otra organización tenía la costumbre: acelerar el arranque “simplificando dependencias.” Alguien notó que el nodo tardaba 90 segundos en arrancar por un disco de backup faltante en fstab.
Así que añadieron nofail. Buen comienzo. Luego fueron más allá y pusieron timeouts agresivos en todas partes,
incluyendo la importación de ZFS, porque “los timeouts son malos.”

También deshabilitaron zfs-import-cache y confiaron en scan import, razonando que era “más flexible.” En teoría, sí.
En la práctica, scan import causó retrasos ocasionales cuando el timing de multipath cambió tras actualizaciones de firmware. A veces el pool se importaba unos segundos más tarde
que antes, lo cual estaba bien—excepto que habían acortado los timeouts de servicios y montajes requeridos.

El resultado: fallos intermitentes de arranque. No siempre, lo cual es lo peor. Las unidades de montaje agotaban el tiempo, ZFS importaba finalmente, pero el sistema ya había
fallado unidades críticas. Reiniciar a veces lo arreglaba, lo que animaba al equipo a seguir reiniciando hasta que funcionara. Eso no es ingeniería de confiabilidad; es desear que funcione.

El camino de recuperación fue deshacer la “optimización” y tratar las dependencias de arranque como un contrato. Si el almacenamiento es requerido, deja que espere lo suficiente para ser verdadero.
Si un disco es opcional, márcalo opcional, pero no acortes timeouts al azar para recursos requeridos. Los arranques deben ser deterministas, no una carrera.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un equipo empresarial ejecutaba nodos Proxmox con mirrors ZFS y un pequeño LVM local para scratch. Tenían una política:
cada cambio que tocara dependencias de arranque requería una validación en consola, una instantánea de overrides de servicio, y un registro “golden boot”.
La gente se quejaba de que era burocracia.

Entonces llegó una noche de guardia. Una actualización de kernel trajo un nuevo initramfs, y una compilación DKMS para ZFS falló silenciosamente por falta de un paquete de headers
tras un cambio de repositorio. El nodo se reinició y cayó en un estado donde los módulos ZFS no estaban disponibles lo suficientemente temprano. La importación de almacenamiento falló,
las unidades de montaje fallaron, los servicios de Proxmox se encadenaron.

La práctica aburrida dio fruto. Compararon el “golden boot” con el arranque actual vía journalctl -b -1 y vieron la línea de fallo de DKMS en la ejecución previa.
También tenían una lista guardada de unidades habilitadas y overrides, así que descartaron “alguien cambió dependencias systemd.”

La resolución fue rápida: instalar los headers faltantes, reconstruir DKMS, regenerar initramfs, reiniciar. Sin drama, sin reinicios aleatorios de servicios no relacionados.
El postmortem fue igual de aburrido: mantener la política. Aburrido es bueno cuando tu trabajo es evitar que las ideas emocionantes de otros rompan producción.

Errores comunes: síntoma → causa raíz → arreglo

Aquí está la librería de patrones. Si reconoces el síntoma, salta la adivinación.

1) “Dependency failed for Proxmox VE API Proxy Server”

Síntoma: pveproxy/pvedaemon no arranca; UI caída.
Causa raíz: /etc/pve no montado (pmxcfs caído), o almacenamiento/montajes faltantes.
Arreglo: verifica pve-cluster.service y el montaje pmxcfs; corrige el orden corosync/red solo si los logs lo muestran.

2) “Dependency failed for ZFS Mount” o “Failed to import ZFS pools”

Síntoma: servicios ZFS fallan; montajes faltan; invitados no arrancan.
Causa raíz: archivo de caché faltante, pool renombrado, cambios en rutas de dispositivo, módulo ZFS faltante en initramfs, o errores reales de disco.
Arreglo: confirma pools con zpool import, importa manualmente para diagnóstico, reconstruye caché y asegura servicios de importación e initramfs correctos.

3) Arranque se cuelga ~90 segundos en “A start job is running …”

Síntoma: demora larga en arranque; a veces termina en fallos de dependencia.
Causa raíz: servicio wait-online esperando por una interfaz, o montaje fstab esperando por un disco faltante.
Arreglo: identifica la unidad que espera con systemd-analyze critical-chain; deshabilita o configura correctamente wait-online; marca montajes no esenciales con nofail.

4) Fallos relacionados con clúster tras cambio de NIC o hardware

Síntoma: corosync.service falla; pve-cluster falla; el nodo no puede unirse al clúster.
Causa raíz: corosync configurado para un nombre de interfaz que ya no existe.
Arreglo: corrige la configuración de la interfaz de ring de corosync y reinicia corosync/pve-cluster en el orden correcto; evita enlazar a nombres de interfaz inestables.

5) “Dependency failed for Local File Systems”

Síntoma: el sistema cae a shell de emergencia; múltiples servicios cancelados.
Causa raíz: un montaje requerido en fstab falló (UUID incorrecto, errores fs, dispositivo faltante).
Arreglo: corrige fstab, añade nofail para montajes no esenciales, ejecuta fsck cuando corresponda, o arregla el problema de disco subyacente.

6) Tras una actualización de kernel, la importación de almacenamiento falla intermitentemente

Síntoma: servicios ZFS/LVM fallan solo después de ciertas actualizaciones; ruleta de reinicios.
Causa raíz: fallo en la construcción de módulos DKMS o initramfs sin el módulo/firmware necesario.
Arreglo: verifica el estado DKMS, reconstruye initramfs, asegura que los headers coincidan con el kernel, confirma presencia de módulos con lsinitramfs.

Listas de verificación / plan paso a paso (seguro, aburrido, efectivo)

Lista A: Encontrar la unidad que realmente falla

Ejecuta systemctl --failed. Anota las unidades fallidas.
Ejecuta journalctl -b -0 -p err..alert. Encuentra la primera línea “Failed to start …”.
Inspecciona esa unidad: systemctl status UNIT -l.
Si la “unidad fallida” es un servicio hoja (UI, firewall), mapea dependencias hacia atrás: systemctl list-dependencies --reverse.
Usa systemd-analyze critical-chain multi-user.target para confirmar qué bloqueó realmente alcanzar el target.

Lista B: Si huele a almacenamiento

Comprueba si existen pools/VGs: zpool import, vgs, pvs (si procede).
Busca fallos en unidades de montaje: systemctl --failed | grep mount, luego systemctl status *.mount según sea necesario.
Valida los montajes críticos para Proxmox: findmnt /var/lib/vz y lo que sostenga discos de VM.
Escanea logs del kernel por errores de transporte: dmesg --level=err,warn.
Sólo entonces considera importación/activación manual. Si la importación manual funciona, arregla el orden/configuración de arranque; no “repares” pools sanos por aburrimiento.

Lista C: Si huele a network-online o clúster

Comprueba retrasos de arranque: systemd-analyze blame y systemd-analyze critical-chain.
Mira quién trae network-online: systemctl list-dependencies --reverse network-online.target.
Inspecciona overrides de unidad: systemctl cat pve-cluster.service (y cualquier unidad sospechosa).
Confirma estado de corosync: systemctl status corosync y luego logs si es necesario.
Elimina dependencias “online” innecesarias. Prefiere network.target salvo que puedas explicar, por escrito, por qué online es obligatorio.

Plan paso a paso: Arreglar sin empeorar

Cuando termines de diagnosticar, arregla como un adulto:

Haz un cambio a la vez. Si cambias tres cosas y arranca, no aprendiste nada.
Prefiere drop-ins sobre editar archivos de unidades del proveedor, pero no mantengas drop-ins antiguos que nadie recuerda.
Tras cambios, recarga systemd y reinicia solo las unidades relevantes.

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart zfs-import-cache.service zfs-mount.service
cr0x@server:~$ sudo systemctl restart pve-cluster.service pveproxy.service

Qué significa la salida: si el restart ahora funciona, tu problema fue ordenamiento/config de arranque, no una rotura fundamental.
Si el restart aún falla, lee los logs de la unidad otra vez—tu arreglo no abordó la condición de fallo real.

Preguntas frecuentes

1) ¿Por qué systemd muestra “Dependency failed” por lo equivocado?

Porque muestra lo que canceló. La causa raíz suele ser la primera unidad que falló más arriba en la cadena. Encuentra esa unidad en el journal.

2) ¿Cuál es la forma más rápida de encontrar la primera unidad que falla?

journalctl -b -0 -p err..alert y busca la primera entrada “Failed to start …”. Luego abre los logs de esa unidad con journalctl -u.

3) ¿Debería reiniciar todos los servicios de Proxmox?

No. Reiniciar la pila puede enmascarar problemas de ordenamiento y hacer que el próximo reinicio falle otra vez. Arregla la dependencia (almacenamiento/montaje/red) primero.

4) ¿Es `After=network-online.target` una buena idea para Proxmox?

Normalmente no. Añade modos de fallo y retrasos. Úsalo solo si el servicio realmente requiere red enrutada durante el inicio, y has configurado wait-online correctamente.

5) ¿Cómo sé si es almacenamiento vs. ordenamiento de systemd?

Si la importación/activación manual funciona (el pool ZFS se importa, VG se activa) y no hay errores I/O en el kernel, probablemente sea ordenamiento/config.
Si faltan dispositivos o dmesg muestra errores, es almacenamiento/hardware.

6) ¿Y si un disco de backup faltante en fstab rompe el arranque?

Hazlo opcional: añade nofail y un corto x-systemd.device-timeout=. O móntalo bajo demanda. No dejes que almacenamiento opcional sea una barrera de arranque.

7) ¿Por qué `systemd-analyze blame` a veces apunta al cuello de botella equivocado?

Porque mide el tiempo pasado en unidades, incluyendo tiempo de espera. Usa systemd-analyze critical-chain para ver la ruta de dependencia verdadera.

8) Si `/etc/pve` no está montado, ¿puedo recuperar el nodo?

Sí, pero necesitas pve-cluster/pmxcfs saludables. Comienza arreglando corosync (si está en clúster) y asegurando los montajes/almacenamiento requeridos. Luego reinicia pve-cluster.

9) ¿Puede “Dependency failed” ser causado por una dependencia circular?

Sí. Especialmente con overrides personalizados que fuerzan network-online o montajes en la dirección equivocada. Busca bucles de ordenamiento en los logs y usa systemctl cat para encontrar el override que lo creó.

10) ¿Cuál es la forma más segura de cambiar dependencias systemd?

Usa un drop-in bajo /etc/systemd/system/UNIT.d/override.conf, documenta por qué, y prueba un reinicio. Si no puedes justificarlo, no lo publiques.

Conclusión: próximos pasos que puedes hacer hoy

La cura para “Dependency failed” no es superstición. Es trazado de grafos.
Encuentra la primera unidad que falla en el journal, confirma la cadena de dependencias, y arregla el bloqueador aguas arriba—usualmente importación/montaje de almacenamiento, pmxcfs, o network-online.

Pasos prácticos siguientes:

En un nodo sano, captura una línea base: systemctl --failed (debe estar vacío), systemd-analyze critical-chain, y overrides habilitados (systemctl cat para unidades críticas de Proxmox).
Audita /etc/fstab por montajes no esenciales y márcalos como opcionales o bajo demanda.
Busca y elimina drop-ins “misteriosos” que fuerzan network-online.target sin una razón sólida.
Tras actualizaciones de kernel, verifica que los módulos de almacenamiento estén presentes en initramfs antes de programar reinicios.