
一、事故背景昨晚虚拟机还好好的今天下午准备在 VMware 中的 OpenKylin 系统里安装 Claude Code刚登录进去发现网络彻底断了。任务栏右下角飘着刺眼的红字——维护模式。快捷操作面板里网络显示未连接有线网络设置里 ens33 网卡开关是灰的点一下又弹回去。就此开始了长达数小时的排查之旅。二、环境说明项目内容宿主机Windows VMware Workstation Pro 17虚拟机系统OpenKylin开放麒麟网络模式NATVMnet8子网 192.168.255.0网卡名称ens33别名 enp2s1宿主机上网方式手机热点三、排查过程与失败记录3.1 第一反应重启 NetworkManagersudo systemctl restart NetworkManager nmcli device status结果ens33 显示未托管unmanaged重启没有任何效果。3.2 尝试手动连接nmcli device connect ens33报错错误添加/激活新连接失败Connection ens33 is not available on device ens33 because device is strictly unmanaged关键词strictly unmanaged。这说明不是简单的断线而是 NetworkManager 被明确配置为不管理这块网卡。3.3 定位配置文件问题cat /etc/NetworkManager/NetworkManager.conf输出中发现[ifupdown] managedfalse找到了managedfalse导致 NetworkManager 拒绝接管任何通过/etc/network/interfaces管理的网卡。尝试修复sudo sed -i s/managedfalse/managedtrue/ /etc/NetworkManager/NetworkManager.conf sudo systemctl restart NetworkManager结果依然 unmanaged修改没有生效。3.4 怀疑 conf.d 目录有覆盖配置sudo grep -r unmanaged\|managedfalse /etc/NetworkManager/结果无输出。配置文件里已经没有 unmanaged 相关设置了但问题依旧。说明 NetworkManager 在运行时缓存了旧配置或者还有其他机制在起作用。3.5 强制 reload 并重新托管sudo nmcli general reload sudo nmcli device set ens33 managed yes nmcli device status结果仍然显示未托管。nmcli device set命令在这个状态下无法持久化。3.6 尝试退出维护模式sudo systemctl default sudo systemctl isolate graphical.target systemctl get-default输出graphical.target系统默认目标已经是 graphical.target理论上不在维护模式——但界面上依然显示维护模式红字。这说明维护模式是 OpenKylin 自己的界面提示并不完全等同于 systemd 的 rescue/emergency target。3.7 删除连接重建由于终端无法输入中文尝试sudo nmcli connection delete ens33报错错误未知的连接 ens33 错误无法删除未知连接ens33连接配置文件已经不存在了但网卡依然是 unmanaged 状态陷入了死循环。3.8 绕过 NetworkManager手动配置 IP既然 NetworkManager 不肯接管直接用ip命令手动配置sudo ip link set ens33 up sudo ip addr add 192.168.255.100/24 dev ens33 sudo ip route add default via 192.168.255.2 ping 8.8.8.8结果路由添加时报错Nexthop has invalid gatewayping 依然不通。原因分析ens33 状态为 DOWN即使添加了 IP网卡物理层没有 up网关也无法到达。四、根本原因深度分析经过完整排查总结出以下几个根本原因叠加导致了此次故障原因一维护模式破坏了网络服务状态OpenKylin 进入维护模式后部分系统服务被强制停止。NetworkManager 虽然进程还在但其对网卡的控制状态没有随着退出维护模式而恢复。这是 systemd 与 NetworkManager 之间的状态同步问题。原因二managedfalse的历史遗留OpenKylin 基于 Ubuntu/Debian 体系默认使用ifupdown插件管理网络。/etc/NetworkManager/NetworkManager.conf中的managedfalse是该体系的历史遗留配置——意思是凡是在/etc/network/interfaces中定义的网卡NetworkManager 不接管。这本是正常配置但在维护模式破坏网络状态后叠加这个配置导致恢复网络的所有 nmcli 命令全部失效。原因三连接配置文件丢失/etc/NetworkManager/system-connections/有线连接 1.nmconnection文件在某个时刻可能是维护模式中或之后的误操作被删除或损坏导致 nmcli 找不到可用的连接配置无法激活。原因四网卡持续处于 DOWN 状态2: ens33: BROADCAST,MULTICAST state DOWN网卡没有 UP即使手动配置 IP 和路由底层链路不通所有网络操作都会失败。这是最底层的问题应该最先解决。五、正确的解决思路复盘如果重来一次正确的排查顺序应该是第一步先把网卡 UPsudo ip link set ens33 up第二步修改 managedfalse 为 truesudo sed -i s/managedfalse/managedtrue/ /etc/NetworkManager/NetworkManager.conf第三步重新加载 NetworkManagersudo systemctl restart NetworkManager sudo nmcli general reload第四步重建连接配置sudo nmcli connection add type ethernet ifname ens33 con-name eth0 ipv4.method auto sudo nmcli connection up eth0第五步验证ip addr show ens33 ping 8.8.8.8六、经验教训维护模式不要随便进OpenKylin/Ubuntu 系维护模式会影响网络服务状态退出后不会自动完全恢复。排查网络问题要从底层开始先检查网卡是否 UPip link show再检查 IPip addr再检查路由ip route最后才是上层的 NetworkManager。managedfalse是陷阱在 Debian 系系统中这个配置会让 nmcli 的所有操作都失效遇到 strictly unmanaged 报错第一时间去查这个配置。nmcli 依赖连接配置文件没有.nmconnection文件nmcli 无法激活连接需要先connection add再connection up。虚拟机网络故障优先检查宿主机NAT 模式下宿主机有网虚拟机配置正确就能有网不要在虚拟机里找手机热点。七、总结这次故障的核心是维护模式 managedfalse 连接配置丢失 网卡 DOWN四个问题同时出现每一个单独都好解决叠加在一起让排查走了很多弯路。希望这篇踩坑记录能帮到同样在 OpenKylin 或其他国产 Linux 系统上遇到类似问题的同学。