NetworkManager.service não inicia em uma inicialização rápida, journalctl mostra muitos ciclos de ordenação do systemd durante a inicialização

Acabei de instalar o Ubuntu 24.04 em uma unidade Intel Optane p4801x. Estou tentando ver o quão rápido ele inicializa a partir deste disco. De fato, ele inicializa muito rápido. Mas a NetworkManagerunidade geralmente não inicia. Ela está habilitada, mas morta, e não há nada no journalctl -b 0 -u NetworkManager.service. Ou seja, a unidade nunca foi executada durante a inicialização. Quando eu mesmo a inicio após a inicialização, ela inicializa bem:

systemctl start NetworkManager

Os logs mostram que networkd-dispatcherfoi desabilitado para quebrar o ciclo de ordenação:

$ journalctl -b 0 | grep network
Oct 20 14:21:15 evergreens kernel: drop_monitor: Initializing network drop monitor service
Oct 20 14:21:15 evergreens systemd[1]: multi-user.target: Found ordering cycle on networkd-dispatcher.service/start
Oct 20 14:21:15 evergreens systemd[1]: multi-user.target: Job networkd-dispatcher.service/start deleted to break ordering cycle starting with multi-user.target/start
Oct 20 14:21:15 evergreens systemd[1]: Reached target network.target - Network.
Oct 20 14:21:15 evergreens systemd[1]: Reached target network-online.target - Network is Online.
...

Suspeito que isso fez com NetworkManagerque nunca fosse executado também.

O Systemd não mostra nenhum problema em nenhum dos dois:

$ sudo systemd-analyze verify networkd-dispatcher.service
$ sudo systemd-analyze verify NetworkManager.service
$

Mas o log na verdade mostra muito mais ciclos de ordenação, e isso aparece em verify multi-user.target:

$ journalctl -b 0 | grep "break.*cycle"
...
$ sudo systemd-analyze verify multi-user.target
...

Por exemplo, a rede:

$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo
multi-user.target: Found dependency on network.target/start
ubuntu-advantage.service: Found ordering cycle on network.target/start
ubuntu-advantage.service: Job network.target/start deleted to break ordering cycle starting with ubuntu-advantage.service/start
multi-user.target: Found ordering cycle on networkd-dispatcher.service/start
multi-user.target: Job networkd-dispatcher.service/start deleted to break ordering cycle starting with multi-user.target/start
multi-user.target: Found ordering cycle on NetworkManager.service/start
multi-user.target: Job NetworkManager.service/start deleted to break ordering cycle starting with multi-user.target/start

Mas, parece que sudo systemd-analyze verify multi-user.target imprime coisas diferentes em quase toda vez que eu o executo ? Isso é possível? Às vezes, ele imprime muito mais, às vezes, apenas 1 unidade.

Tentei traçar as dependências multi-user.targetseguindo a resposta no Unix Stackexchange :

$ sudo systemd-analyze verify multi-user.target 2>&1 |\
  perl -lne 'print $1 if m{Found.*?on\s+([^/]+)}' |\
  xargs --no-run-if-empty systemd-analyze dot | dot -Tsvg > cycle.svg

Não consegui ver um ciclo ali. Além disso, o gráfico é grande e difícil de ler. Tentei "dar zoom" em algumas unidades como, mas também não vejo um ciclo ali:

$ echo multi-user.target networkd-dispatcher.service basic.target |\
  xargs --no-run-if-empty systemd-analyze dot |\
  dot -Tsvg > cycle.svg

Como systemd-analyze verifyele imprime coisas diferentes quase toda vez que é executado, esses gráficos provavelmente não são confiáveis.

Olhando para unidades individuais, não encontro problema. As NetworkManagerdependências parecem boas:

$ cat /usr/lib/systemd/system/NetworkManager.service
[Unit]
Description=Network Manager
Documentation=man:NetworkManager(8)
Wants=network.target
After=network-pre.target dbus.service
Before=network.target
BindsTo=dbus.service
...

[Install]
WantedBy=multi-user.target
Also=NetworkManager-dispatcher.service

Eu tive um problema parecido ao inicializar de uma unidade NVMe comum da Corsair. E nunca tive quando a inicialização do NVMe da Corsair era anormalmente lenta por causa de uma unidade específica. (Montando um disco HDD /etc/fstab- ele não está fstabmais lá, então não deixa a inicialização lenta.)

Ie Eu acho que esse problema acontece somente quando a sequência de boot é rápida. Embora eu não entenda por que isso seria o caso. Por que um problema no gráfico de dependência apareceria somente em boot rápido?

Alguém poderia sugerir como rastrear os ciclos de pedidos?

O que está acontecendo com systemd-analyze verify multi-user.targeta impressão de coisas diferentes a cada vez? Esse é um comportamento conhecido real? Como ele atravessa o gráfico de dependência, é de alguma forma aleatório? Isso pode estar relacionado à causa que faz o systemd excluir unidades durante a inicialização, mas as mesmas unidades rodam bem depois?