Ubuntu 20.04以太网消失？排查nmcli与netplan管理冲突

Ubuntu 20.04系统设置里那个“网络连接—以太网”的条目突然消失右上角托盘只剩Wi-Fi图标有线网卡插上去一点反应都没有这问题我最近在好几台机器上挨个踩了一遍。先说结论绝大多数情况下网卡硬件是好的别一上来就怀疑主板坏了或者想重装系统问题基本出在系统里负责网络管理的组件没有把这个有线接口“接管”起来或者接管了但没有在GNOME设置面板里生成对应的入口。这篇文章就按照我实际排查的顺序把完整的定位思路和修复过程写下来给同样被“以太网消失”折磨的人一份可以直接照着操作的参考。我这次处理的机器配置不算特殊一套普通AMD主机加Realtek板载网卡装的Ubuntu 20.04桌面版之前一直正常某次开机后网络就没了。如果你也遇到一模一样的情况跟着下面的步骤走大概率能在一个小时内解决问题。1. 先分清网卡没被识别还是服务没接管很多人在这一步就走偏了。看到“以太网”选项消失第一反应是打开终端执行ifconfig发现输出里连eth0都没有就直接断定网卡坏了。这里有两个容易混淆的概念网卡驱动有没有加载和网卡有没有被NetworkManager管理完全是两码事。1.1 最快的基础诊断命令打开终端依次执行这三个命令ip link nmcli device status lspci -k | grep -iA2 ethernetip link看的是内核态的网络接口只要驱动加载成功网卡就会出现在这里哪怕它没有IP地址、没有被任何服务管理。nmcli device status看的是NetworkManager这个上层管理服务能否看到设备。lspci -k | grep -iA2 ethernet用来确认PCIe总线上的以太网控制器有没有被内核驱动绑定。我那次的情况是这样的$ ip link 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 ... 2: enp3s0: BROADCAST,MULTICAST mtu 1500 state DOWN ...enp3s0存在但state DOWN。这说明系统知道有这个网卡驱动也在只是没有被启用。再看nmcli device status$ nmcli device status DEVICE TYPE STATE CONNECTION enp3s0 ethernet unmanaged --注意最后那个unmanaged这就是最典型的状态。网卡躺在系统里但NetworkManager明确表示“我不接管它”GNOME设置里的“有线”选项自然会消失。1.2 从输出判断问题方向我把不同输出组合对应的可能性列成一张表方便对照ip link结果nmcli device status结果大概率的根因没有对应网卡接口看不到设备驱动没加载或网卡被BIOS禁用有接口state DOWNunmanagedNetworkManager未托管或netplan后端冲突有接口state UPdisconnected网卡已接管但缺少连接配置有接口state UPconnected但面板不显示GNOME设置缓存或桌面组件问题大多数“以太网入口消失”的案例都落在第二行接口存在但状态是unmanaged。这种情况就别去折腾模块驱动了问题在网络管理栈上。2. 核心排查顺序服务状态、systemd日志、托管开关确定接口存在之后排查的逻辑就非常清晰了按下面的顺序来不需要跳来跳去。2.1 确认NetworkManager服务是否在运行Ubuntu 20.04桌面版默认用NetworkManager管理网络这个服务一旦没跑起来系统设置里整个“网络”页面都会残缺不全。先看服务状态systemctl status NetworkManager如果输出里出现Active: inactive (dead)或者failed那问题就在这里。直接启动并设置开机自启sudo systemctl start NetworkManager sudo systemctl enable NetworkManager如果服务已经在运行继续往下查。有一点要特别注意systemctl status NetworkManager和nmcli networking是两套控制方式。有时候服务进程活着但nmcli networking off被触发过这会导致NetworkManager进程存在但不管理任何设备表现出来就是接口全部unmanaged。可以用下面命令确认nmcli -t -f RUNNING general status输出应该是running。如果输出是not running执行sudo nmcli networking on就能恢复。我遇到过好几次这种奇怪状况可能是某个桌面组件或脚本误关了。2.2 systemd日志里会写关键线索服务正常但接口unmanaged时最值得看的是NetworkManager自己的日志sudo journalctl -u NetworkManager -b -0 --no-pager | grep -i ethernet sudo journalctl -u NetworkManager -b -0 --no-pager | grep -i unmanaged日志里通常会直接告诉你它为什么不管这个设备。比较常见的有两类信息一类是说接口“not available”另一类会直接提到某个连接配置文件失败。举个例子我查日志时看到过这种NetworkManager: warn ... connection 有线连接 1 is not available on device enp3s0 because device has no carrier第一眼看上去像物理链路不通但网线明明插着后来才发现是连接配置里绑定了一个已经不存在的MAC地址或者旧的接口名。这种问题靠重启服务解决不了得清理连接配置。2.3 检查networkmanager.conf的托管开关Ubuntu 20.04的NetworkManager有一个总开关决定它是否接管系统中所有网络设备配置文件在/etc/NetworkManager/NetworkManager.confsudo cat /etc/NetworkManager/NetworkManager.conf默认内容一般长这样[main] pluginsifupdown,keyfile [ifupdown] managedfalse关键在于[ifupdown]下面的managedfalse/false。如果为trueNetworkManager会接管/etc/network/interfaces里配置的传统接口改配置后需要重启服务才能生效sudo systemctl restart NetworkManager不过我这次遇到的不是这个原因managedtrue已经设好问题出在netplan上。3. 真正的元凶netplan配置与NetworkManager的管理权冲突这是Ubuntu 20.04特有的坑也是我这次折腾最久的部分。3.1 netplan是从哪冒出来的Ubuntu从18.04开始引入netplan作为默认网络配置工具。它本身不是一个网络管理服务而是一层“配置翻译层”读取/etc/netplan/*.yaml里的配置然后选择后端渲染到systemd-networkd或者NetworkManager。也就是说你最终用的还是NetworkManager或systemd-networkd但谁能拿到网卡的管理权由netplan的renderer决定。桌面版安装时/etc/netplan/下通常只有一个文件# /etc/netplan/01-network-manager-all.yaml network: version: 2 renderer: NetworkManager这个配置的意思是“把所有接口都交给NetworkManager”。一旦这个文件被改成了renderer: networkd或者有人额外添加了一个netplan的yaml文件把renderer覆盖成networkdNetworkManager就会失去对有线网卡的管理权GNOME面板里的“以太网”选项就会直接消失。3.2 如何判断当前由谁在管事打开/etc/netplan/目录ls /etc/netplan/ sudo grep -r renderer /etc/netplan/如果看到renderer: networkd那问题基本就锁定了。还有另一个判断方法看当前系统里连接文件在哪个目录NetworkManager管理的连接放在/etc/NetworkManager/system-connections/systemd-networkd管理的连接放在/etc/systemd/network/或由netplan直接生成的运行时文件。我之前那台机器非常典型/etc/netplan/下除了01-network-manager-all.yaml之外还有一个从网上抄来的99-custom.yaml里面写了renderer: networkd还配了一个静态IP。结果netplan处理配置时后面的文件覆盖了默认的rendererNetworkManager就成了光杆司令。正确的修复方式很简单删掉多余文件或者编辑主文件确认renderer是NetworkManager然后重新应用配置sudo rm /etc/netplan/99-custom.yaml sudo netplan generate sudo netplan apply sudo systemctl restart NetworkManager执行完毕后再看nmcli device status接口状态应该从unmanaged变成disconnected接着就会出现connecting和connected。到这一步GNOME设置里的“有线”入口通常就回来了。3.3 不管配置先救急恢复联网如果你现在急着上网下载东西不想一步步排查可以先不碰netplan直接在终端手动把网卡拉起来。这种方法解决不了根因但能让你先恢复网络。NetworkManager还在运行的情况下直接让它接管接口sudo nmcli device connect enp3s0注意接口名要换成你自己的比如eno1、eth0以ip link输出为准。如果这条命令无效说明当前接口确实不在NetworkManager管辖范围内那就直接用传统方式sudo ip link set enp3s0 up sudo dhclient enp3s0这两条命令会在当前的网络环境里通过DHCP自动获取IP地址。前提是你的路由器开启了DHCP并且网线物理连接正常。等联网之后再去慢慢修netplan的问题。4. 重建有线连接配置让GNOME设置面板恢复正常排查完netplan之后如果你的接口已经从unmanaged变成disconnected但设置面板里还是看不到“以太网”那就到了处理连接配置文件的环节。4.1 删除失效连接配置的完整操作NetworkManager会为每个网卡保存连接配置路径在/etc/NetworkManager/system-connections/。这些文件的名字通常叫有线连接 1.nmconnection或者Wired connection 1.nmconnection。当系统更新、网卡换了PCIe插槽、或者配置里绑定了一个已经失效的MAC地址时这些连接文件会对新接口“失效”NetworkManager不会把它们显示出来。列出现有连接nmcli connection show如果这个列表是空的但设备状态是disconnected那就手动创建一个。如果列表里有明显无效的连接先删掉sudo nmcli connection delete 有线连接 1或者直接删除文件sudo ls /etc/NetworkManager/system-connections/ sudo rm /etc/NetworkManager/system-connections/有线连接 1.nmconnection然后重启NetworkManagersudo systemctl restart NetworkManager重启后NetworkManager会重新扫描接口并自动生成一个默认的有线连接配置。在大多数家庭网络环境下它会直接通过DHCP获取IP地址并把“以太网”显示在设置里。这里有个细节直接删除文件比用nmcli connection delete更彻底后者有时候会留下一些缓存状态。4.2 从终端手动创建“有线连接”作为兜底如果删除配置后系统没有自动生成或者你希望连接配置更可控可以用nmcli手动新建一个有线连接sudo nmcli connection add type ethernet ifname enp3s0 con-name ether sudo nmcli connection up etherifname参数必须和网卡实际接口名完全一致否则连接创建成功但状态永远是unavailable。创建完通常会自动切换到这个连接。没有静态IP需求的话NetworkManager默认会用DHCP不用额外配置任何IPV4选项。手动创建的连接同样会持久化在/etc/NetworkManager/system-connections/ether.nmconnection里重启不会丢失。这种方式的好处是干净利落不依赖GNOME设置面板的图形界面适合服务器环境或者没有桌面的时候操作。4.3 检查内核驱动模块这个隐藏变量前面说过大多数情况不是驱动问题但有一种场景例外新装机的双系统环境。我处理过一台刚装完Windows再装Ubuntu 20.04的机器也是“以太网入口消失”ip link里完全找不到有线接口的名字。这时候要看lspci输出lspci | grep -i ethernet常见输出02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller如果是RTL8125这种较新的网卡Ubuntu 20.04自带的r8169驱动可能没有正确绑定或者绑了但接口没被创建。检查模块状态lsmod | grep r8169有时候重新装一下驱动模块或者更新内核就能解决sudo modprobe -r r8169 sudo modprobe r8169如果模块加载成功但依然没有接口考虑安装厂商驱动或升级内核sudo apt update sudo apt install linux-generic不建议新装系统的人一开始就折腾驱动先把Netplan和NetworkManager这一层的问题排除掉再考虑驱动顺序不能乱。5. 常见问题速查与避坑清单把这次排查过程中踩到的坑和平时积累的常见问题整理成一张速查表目录放在这里以后遇到类似问题直接查。症状可能原因优先处理方式设置面板完全没有“有线”选项ip link里能看到网卡NetworkManager服务未运行或未接管systemctl start NetworkManager再查netplan renderer右上角托盘只有Wi-Fi有线图标消失接口状态unmanagednetplan renderer被改成networkd编辑netplan文件renderer: NetworkManager执行netplan applyip link里完全没有有线接口内核驱动未加载或网卡被BIOS禁用lspci -k看驱动modprobe加载模块进BIOS确认网卡开启之前正常某次更新后消失连接配置文件损坏或绑定了旧的MAC地址删除/etc/NetworkManager/system-connections/下对应文件重启服务IPv4显示“连接中”但一直拿不到IPDHCP服务异常或接口名变了重启路由器或用nmcli重新创建连接虚拟机里“以太网激活失败”open-vm-tools未安装或虚拟交换机配置问题安装open-vm-tools检查虚拟网络适配器连接状态再说几个实操中真正会省时间的避坑经验第一别在设置面板里反复开关“有线”开关。如果连接配置失效开关多少次都不会有用反而可能让NetworkManager的日志变多干扰排查。第二改任何netplan配置前先备份。很多人改坏renderer之后甚至直接进不了系统因为网络管理栈整个乱了。备份就是一行命令的事sudo mkdir -p /root/netplan-backup sudo cp /etc/netplan/*.yaml /root/netplan-backup/第三检查前先固定网卡名。新机器的接口名从eth0变成enp3s0这类Predictable Network Interface Names格式非常正常。写脚本、建连接配置的时候务必以ip link输出的实际名字为准不要想当然用eth0。这次修复过程中真正让我多绕弯路的点是netplan的renderer覆盖机制。很多人知道netplan但没意识到/etc/netplan/下多个yaml文件之间是有优先级冲突的。修好之后我特意在机器里留了个备份脚本把netplan配置、NetworkManager的连接配置目录都打包了一份。对我个人来说以后遇到“以太网消失”我会优先检查netplan的renderer这是Ubuntu 20.04上成功率最高的修复路径。最后分享一个小习惯修好网络后顺手把/etc/NetworkManager/system-connections/里自动生成的有效连接配置文件也复制一份到备份目录。下次如果再遇到类似的问题三分钟就能把网络恢复原样完全不用重新去猜root cause。