看起来你遇到的是Ubuntu 24.04在高速Optane存储上启动时，systemd服务启动顺序冲突导致NetworkManager自动启动失败的问题，我来帮你梳理下问题原因和解决办法：

问题根源 #

从你提供的日志能明确看到，systemd在启动时检测到multi-user.target和networkd-dispatcher.service之间存在启动顺序循环——为了避免整个启动流程卡死，systemd直接删除了networkd-dispatcher.service的启动任务。而NetworkManager的自动启动逻辑和这个服务存在依赖或顺序绑定，最终导致NetworkManager也没被触发启动；但手动启动时不受启动时序约束，所以能正常运行。

解决办法 #

这里给你几个可行的方案，你可以根据自己的需求选择：

• 方案一：调整networkd-dispatcher的启动顺序
  通过修改服务配置，打破它和multi-user.target的循环依赖：

  1. 打开服务的自定义配置文件：

     sudo systemctl edit networkd-dispatcher.service
     

  2. 在编辑器中添加以下内容，明确它的启动顺序优先级：

     [Unit]
     After=multi-user.target
     Wants=multi-user.target
     Before=network.target
     

  3. 保存退出后，重新加载systemd配置：

     sudo systemctl daemon-reload
     

  4. 重启系统后，检查NetworkManager状态：

     systemctl status NetworkManager.service
     

• 方案二：直接禁用networkd-dispatcher（如果不需要）
  如果你主要用NetworkManager管理网络，而没有依赖systemd-networkd的场景，完全可以禁用这个服务来消除循环：

  1. 禁用并停止服务：

     sudo systemctl disable --now networkd-dispatcher.service
     

  2. 重启系统后，验证NetworkManager是否自动启动：

     systemctl status NetworkManager.service
     

• 验证修复效果
  不管用哪个方案，重启后都可以通过日志确认问题是否解决：

  journalctl -b 0 | grep network
  

  如果不再出现“ordering cycle”相关的日志，且NetworkManager状态为active (running)，就说明问题修复了。

额外说明 #

你的系统在Optane这种高速存储上启动，启动流程比普通硬盘快得多，服务启动的时序会变得非常紧凑，这就更容易触发原本在慢存储上不会显现的systemd顺序循环问题——这也是为什么你只在快速启动时遇到这个故障的原因。

备注：内容来源于stack exchange，提问作者xealits