Ubuntu20排查 Wi-Fi 和蓝牙同时消失的经验总结1. 先确认“系统没显示设备”到底是哪一层出了问题2. PCI 设备还在不代表无线网卡工作正常3. Wi-Fi 和蓝牙一起消失意义非常大4. 蓝牙服务 inactive 不等于“蓝牙服务坏了”5. rfkill 为空比“被飞行模式关闭”更严重一点6. 固件文件存在不代表固件一定正常工作7. 当前内核不是太旧但仍值得更新8. ASPM 是值得测试的兼容性点但不是万能解9. 不要因为一个不存在的模块名而误判新故障当前最合理的故障结论后续处理的正确顺序第一优先级更新软件和固件第二优先级真正断电复位第三优先级做系统级排除第四优先级硬件检查Wi-Fi 与蓝牙同时消失时先查“组合卡有没有被系统枚举”而不是先修网络图标或蓝牙服务PCIe 的 Wi-Fi 报-110内部 USB 蓝牙也消失优先怀疑整卡初始化、电源状态、固件内核兼容性。1. 先确认“系统没显示设备”到底是哪一层出了问题一开始nmcli device只有有线网卡和loenxf639a6743c47 ethernet 已连接 enp6s0 ethernet 不可用 lo loopback 未托管没有任何wlan0、wlp...之类的无线接口。这说明不是“Wi-Fi 没连上”而是Linux 根本没有成功创建无线网卡接口。所以不要优先去折腾 NetworkManager、Wi-Fi 图标或网络设置。2. PCI 设备还在不代表无线网卡工作正常通过此前的lspci确认无线部分仍然能被 PCI 总线发现08:00.0 Network controller: MEDIATEK Corp. Device 0616而驱动日志显示mt7921e 0000:08:00.0: ASIC revision: 79220010 mt7921e: probe of 0000:08:00.0 failed with error -110这说明驱动能找到无线芯片甚至能读到芯片版本但在后续初始化时超时因此没有生成 Wi-Fi 接口。error -110的核心含义是设备通信超时。它更偏向设备初始化、电源状态、PCIe 通道、固件加载后卡死等问题而不是普通设置问题。3. Wi-Fi 和蓝牙一起消失意义非常大Wi-Fi 和蓝牙一起消失。这张 MediaTek 组合无线卡通常是功能常见连接方式Wi-FiPCIe蓝牙内部 USB我看到 Wi-Fi 部分是mt7921e ... probe failed with error -110同时蓝牙相关的 USB 日志有usb 1-10: device descriptor read/64, error -110 usb 1-10: device not accepting address ..., error -71并且lsusb里没有 MediaTek / Bluetooth 设备。这说明蓝牙不是单纯“服务没启动”而是蓝牙所在的内部 USB 设备根本没有正常枚举出来。所以两者一起失效时优先怀疑的是无线组合卡卡死无线卡异常供电或异常休眠状态PCIe / 内部 USB 初始化异常固件、内核与硬件兼容性问题更靠后的可能才是网卡本体、插槽或主板硬件问题。4. 蓝牙服务 inactive 不等于“蓝牙服务坏了”当时蓝牙状态是bluetooth.service Active: inactive (dead) Condition check resulted in Bluetooth service being skipped.这并不代表应该直接重装蓝牙服务。它真正表示systemd 检测到系统中没有可用的蓝牙控制器因此直接跳过启动蓝牙服务。而且timeout5bluetoothctl list超时退出返回124也和“没有控制器可用”相符。因此排查蓝牙时要先看lsusb rfkill list all bluetoothctl list而不是一上来就重装bluez。5.rfkill为空比“被飞行模式关闭”更严重一点我的rfkill list all没有任何输出。这表示当前不是简单的Soft blocked: yes Hard blocked: yes而是系统连能被 rfkill 管理的无线设备都没有注册出来。所以飞行模式、Fn 无线开关虽然仍可以顺手检查但它不是当前最强嫌疑。6. 固件文件存在不代表固件一定正常工作查到/lib/firmware/mediatek/中有BT_RAM_CODE_MT7922_1_1_hdr.bin WIFI_MT7922_patch_mcu_1_1_hdr.bin WIFI_RAM_CODE_MT7922_1.bin这说明不是“文件彻底缺失”的那种简单问题。但这些固件文件时间较早而且“文件存在”只能证明系统有固件不能证明驱动成功把固件传进芯片芯片成功启动PCIe 和 USB 两条通道都恢复卡没有停留在异常电源状态。所以以后遇到类似问题不要看到固件文件存在就完全排除固件/内核兼容性。7. 当前内核不是太旧但仍值得更新内核是5.15.0-139-generic这已经不是 Ubuntu 20.04 最初的 5.4 内核说明你在用 HWE 内核。这意味着不能简单说“因为内核只有 5.4所以不支持”mt7921e驱动和 MT7922 固件已经确实被系统识别但 Ubuntu 20.04 较早固件 较新的 MediaTek 组合卡仍可能出现初始化不稳定。因此后续合理操作是sudoaptupdatesudoaptinstall--reinstalllinux-firmwaresudoaptupgradesudoupdate-initramfs-u-kall重点是更新linux-firmware内核相关包initramfs而不是只重装 NetworkManager。8. ASPM 是值得测试的兼容性点但不是万能解确认驱动支持modinfo mt7921e|grep-idisable_aspm输出parm: disable_aspm:disable PCI ASPM support (bool)这意味着可以通过sudomodprobe mt7921edisable_aspm1临时关闭 PCIe ASPM 省电机制测试是否是 PCIe 省电兼容性导致的初始化失败。这一步的经验是它是一个低风险、很值得做的诊断若恢复说明偏 PCIe 电源管理兼容性若不恢复不能说明驱动没加载而是说明问题不止 ASPM。你这次关闭 ASPM 后Wi-Fi 仍未出现因此ASPM 可能不是主因至少不是唯一主因。9. 不要因为一个不存在的模块名而误判新故障执行sudomodprobe-rmt7921e mt7921_common mt76_connac_lib mt76时出现modprobe: FATAL: Module mt7921_common not found.这个并不表示无线网卡又多了一个错误。它只表示当前内核没有把mt7921_common编译为独立可卸载模块。实际加载中的模块是mt7921e mt76_connac_lib mt76 mac80211 cfg80211以后重载驱动时更稳一点的写法是sudomodprobe-rmt7921esudomodprobe mt7921edisable_aspm1避免因为无关模块不存在导致命令中断。当前最合理的故障结论目前最符合所有现象的结论是MT7922 / RZ616 无线组合卡整体没有完成初始化。Wi-Fi 的 PCIe 端在驱动探测阶段超时蓝牙的内部 USB 端没有被正常枚举因此系统中同时没有 Wi-Fi 接口和蓝牙控制器。按可能性从高到低大致是无线组合卡卡在异常电源/休眠状态固件与当前 Ubuntu 20.04 / 5.15 HWE 组合兼容性问题PCIe 或 USB 初始化异常BIOS 电源管理、双系统快速启动遗留状态网卡松动、插槽接触、电源或网卡硬件故障。后续处理的正确顺序第一优先级更新软件和固件有网线时执行sudoaptupdatesudoaptinstall--reinstalllinux-firmwaresudoaptupgradesudoupdate-initramfs-u-kall然后完全关机。第二优先级真正断电复位不是“重启”而是sudo poweroff拔电源或充电器长按电源键约 60 秒等十秒再开机检查 Wi-Fi 与蓝牙。这一步对“Wi-Fi 和蓝牙一起失踪”的组合卡异常很重要。第三优先级做系统级排除若更新和断电后仍无效用 Ubuntu 24.04 启动盘进入“试用模式”不安装系统只检查nmcli device bluetoothctl list lsusb|grep-Eimediatek|bluetooth判断逻辑试用系统结果结论Wi-Fi、蓝牙都回来当前 Ubuntu 20.04 环境问题为主两者仍都消失更偏 BIOS、电源、网卡或硬件层面仅 Wi-Fi 回来蓝牙 USB 通道/蓝牙固件问题仅蓝牙回来Wi-Fi PCIe 初始化问题第四优先级硬件检查若新系统试用模式下仍然没有 Wi-Fi 和蓝牙再考虑台式机重新插拔无线网卡、检查 M.2 Key-E 插槽、检查无线卡的内部 USB 连接笔记本检查 BIOS 无线设置、断电复位、必要时拆机检查或更换无线网卡。