ubuntu20.04的5.15.139内核启动卡死问题解决过程

花了大概六个小时彻底解决问题。因为我很久之前就遇到过一样的问题，当时我认输了重装系统。但是现在我这个ubuntu有太多东西了我不能失去，而且我不想认输第二次。

如果遇到类似问题可以按照我的操作方法一条条试。

首先，根本原因

这是 Linux 5.15.0-139 内核与这台 Lenovo + Intel 13代平台（PCH）之间的 PCI/MSI 中断兼容性问题。

不是：

• ❌ NVIDIA 驱动
• ❌ snapd
• ❌ binfmt_misc
• ❌ initramfs
• ❌ ext4
• ❌ NVMe
• ❌ USB 外设本身
• ❌ Recovery Mode
• ❌ GDM
• ❌ Wayland

真正的问题发生在更底层。

这台电脑发生过什么？

• 5.15.0-139 本身存在一个与这台机器相关的 PCI/MSI 兼容性问题。不过不能确定是哪个设备带来的。
• 这个问题长期潜伏，并非每次启动都会暴露。
• 7 月 27 日进入 Windows、进入 BIOS 并不小心修改（哪怕改回）Graphic Device 后，硬件初始化状态发生了变化。
• 7 月 28 日开始，139 的 MSI 初始化稳定触发了这个 Bug，导致整个系统在根文件系统挂载后失去中断响应。
• pci=nomsi完全绕过了 MSI 路径，因此系统恢复正常。

为什么grub里linux那一行末尾加入pci=nomsi能解决？

PCI 设备有两种中断方式：

传统：

INTx

现代：

MSI

或者

MSI-X

Linux 5.15.0-139 默认大量使用 MSI。机器某个 PCI 设备（或者 PCH）：

MSI 有兼容性 Bug。

于是设备初始化完成以后：

等待 MSI 中断

↓

中断永远收不到

↓

CPU 一直等待

↓

整个系统看起来死机。

关键逻辑

1.Recovery Mode 一样卡。

这一下其实已经把：

• GDM
• Wayland
• GNOME
• NVIDIA Desktop

基本全排除了。因为 Recovery 根本不会启动这些。

2.试了init=/bin/bash

结果root@(none):/#出来了。

但是：不能输入。

NumLock灭。

CapsLock没反应。

说明不是 shell 没启动。

而是CPU已经不响应键盘中断。

一、问题概述

二、最初症状

2.1 屏幕报错

[FAILED] Failed to start Load Kernel Modules. See 'systemctl status systemd-modules-load.service' for details. Failed to load kernel module chromeos-pstore. Failed to start RF Kernel Switch Status.

2.2 启动行为

• 5.15.0-67-generic：正常启动，进入桌面。
• 5.15.0-139-generic：卡死，无法进入系统。
• Recovery Mode：同样卡死，无法进入恢复菜单。

2.3 最终卡死画面

/dev/nvme0n1p6: clean, 1383058/13107200 files, 47536298/52428800 blocks [ 2.776653] _

光标停止闪烁，系统完全无响应。

三、三方 AI 初始判断（第一轮）

3.1 DeepSeek

• 核心假设：systemd-modules-load.service失败是根因。
• 怀疑方向：NVIDIA 驱动 + Secure Boot 冲突。
• 推理：看到systemd-modules-load.service报错，联想到 NVIDIA DKMS 模块在 Secure Boot 开启时无法签名加载。
• 建议操作：

• • 检查/禁用 Secure Boot
  • 重装 NVIDIA 驱动
  • 更新内核头文件
  • 执行sudo dkms autoinstall

3.2 ChatGPT

• 核心假设：chromeos_pstore是噪音，不是根因。
• 怀疑方向：snapd或binfmt_misc循环导致卡死。
• 推理：注意到chromeos_pstore报错在非 ChromeOS 设备上很常见且不阻塞启动，真正的问题可能在 systemd 服务层。
• 建议操作：

• • 检查 snap 状态（snap changes）
  • 查看 snapd 日志
  • 分析/var/log/apt/history.log

3.3 Claude

• 核心假设：initramfs 内容异常或/boot空间不足。
• 怀疑方向：/boot分区空间不足导致 initramfs 截断，或模块缺失。
• 推理：注意到journalctl --list-boots没有卡死启动的日志（硬卡死日志无法落盘），怀疑 initramfs 生成不完整。
• 建议操作：

• • df -h /boot
  • ls -la /boot/initrd.img-*
  • diff对比两个 initramfs 的内容
  • sudo update-initramfs -u -k 5.15.0-139-generic

四、第一轮排查

4.1 检查 Secure Boot

mokutil --sb-state

结果：Secure Boot 已禁用。
三方结论：❌ 排除 Secure Boot 问题。

4.2 检查 DKMS 状态

dkms status

结果：NVIDIA 模块为5.15.0-139-generic成功编译，状态installed。
三方结论：❌ 排除 NVIDIA DKMS 编译失败。

4.3 检查/boot空间

df -h /boot ls -la /boot/initrd.img-5.15.0-*

结果：/boot不是独立分区（挂在根分区下），空间充足；-139initrd（92MB）比-67（80MB）还大，没有截断。
三方结论：❌ 排除/boot空间不足或 initramfs 截断。

4.4 重新生成 initramfs

sudo update-initramfs -u -k 5.15.0-139-generic sudo update-grub

结果：执行成功，但问题依旧。
三方结论：❌ 排除 initramfs 损坏（至少不是简单损坏）。

五、中间阶段：systemd 服务层排查

5.1 检查 snapd 状态和日志

snap changes snap list --all journalctl -u snapd --since "7 days ago"

结果：snapd 在 7 月 27 日有网络错误（408 超时、DNS misbehaving），但snap changes显示所有任务已完成。
DeepSeek 判断：snapd 可能有异常，建议 mask snapd 验证。
ChatGPT 判断：同样怀疑 snapd 自动更新可能触发了问题。
Claude 判断：未直接评论 snapd 方向。

5.2 Mask snapd（验证 snapd 是否为根因）

sudo systemctl mask snapd.service snapd.socket snapd.seeded.service

结果：重启后-139仍然卡死，症状完全一样。
三方结论：❌ 排除 snapd 为根因。

5.3 检查 apt 历史

grep -E "Start-Date|Upgrade:|Install:" /var/log/apt/history.log | tail -100 zcat /var/log/apt/history.log.*.gz | grep -i "linux-firmware"

结果：

• 7 月 21 日：用户安装/卸载了 kazam 等多媒体包。
• 3 月 12 日：linux-firmware从1.187.36升级到1.187.39。
  DeepSeek 初步判断：linux-firmware可能是元凶。
  ChatGPT 判断：时间线不吻合——3 月升级，7 月才坏，排除。
  a/发力Claude暴死，退出。

5.4 Mask proc-sys-fs-binfmt_misc.automount

sudo systemctl mask proc-sys-fs-binfmt_misc.automount

结果：重启后-139仍然卡死。
结论：❌ 排除binfmt_misc挂载为根因。

六、关键转折：目标层级下移

6.1 测试multi-user.target

在 GRUB 中，在linux行末尾添加：

systemd.unit=multi-user.target

结果：仍然卡死。
结论：❌ 排除图形界面服务。

6.2 测试rescue.target

在 GRUB 中，在linux行末尾添加：

systemd.unit=rescue.target

结果：仍然卡死。
结论：❌ 排除multi-user.target特定服务。

6.3 测试emergency.target

在 GRUB 中，在linux行末尾添加：

systemd.unit=emergency.target

结果：仍然卡死。
DeepSeek 判断：仍然怀疑binfmt_misc或 snap。
ChatGPT 判断：开始怀疑问题发生在 systemd 启动之前，建议systemd.device_watchdog参数。

关键转折点：emergency.target是 systemd 最精简的启动模式，它只启动sysinit.target中的基础服务。如果它都卡死，问题一定在sysinit.target层或更早。

6.4 测试systemd.device_watchdog

在 GRUB 中，在linux行末尾添加：

systemd.device_watchdog=30 systemd.device_watchdog_timeout=30

结果：仍然卡死。
deepseek方向：无效。

七、决定性突破：init=/bin/bash

7.1 ChatGPT 的关键提问

“如果init=/bin/bash都卡死，那问题不在 systemd，不在用户态服务，而在内核与硬件的交界处。”

7.2 执行init=/bin/bash

在 GRUB 中，在linux行末尾添加：

init=/bin/bash

启动后屏幕显示：

bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell root@(none):/# [USB 枚举日志...]

实际状态：

• 屏幕显示了root@(none):/#提示符。
• 键盘完全无反应，按任何键都没有输入回显。
• Num Lock 灯熄灭，Ctrl+Alt+Del无反应。
• 这不是“进入了 bash”，而是“bash 刚打印出提示符，系统就硬锁死了”。

7.3 对init=/bin/bash结果的解读

DeepSeek：

• 仍然怀疑是 systemd 某些服务的残留影响，或binfmt_misc在 kernel 层面的循环。
• 未充分重视“Num Lock 灯灭”这个信号。
• 继续在 systemd 层面思考。
• 浪费我大量时间。

ChatGPT：

• 立即识别出这是硬死锁（Hard Lockup）。
• 指出：Num Lock 灯灭意味着 CPU 停止响应中断，这是内核/硬件层面的问题。
• 放弃所有 systemd/snap/bin 方向，转向APIC/PCI/ACPI/CPU 电源管理。
• 建议测试底层参数：noapic、irqpoll、pci=nomsi、intel_idle.max_cstate=0。

八、最重要！！！底层参数测试

8.1noapic irqpoll

在 GRUB 中，在linux行末尾添加：

noapic irqpoll

结果：仍然卡死。
结论：❌ APIC 中断方向不是根因。

8.2intel_idle.max_cstate=0 processor.max_cstate=1

在 GRUB 中，在linux行末尾添加：

intel_idle.max_cstate=0 processor.max_cstate=1

结果：仍然卡死。
结论：❌ CPU 电源管理 C-State 不是根因。

8.3pci=nomsi✅

在 GRUB 中，在linux行末尾添加：

pci=nomsi

结果：成功进入系统！
结论：✅ MSI（消息信号中断）是根本原因。

九、pci=nomsi的含义与后续验证

9.1 参数说明

• MSI（Message Signaled Interrupt）：现代 PCIe 设备使用的中断机制，比传统 INTx 更高效。
• pci=nomsi：强制内核禁用所有 PCI 设备的 MSI，回退到传统 INTx 中断。

9.2 验证：pci=nomsi后系统表现

• ✅ 系统正常启动进入桌面。
• ✅ NVIDIA 驱动正常工作（nvidia-smi可用）。
• ⚠️ USB 初始化变慢，出现xhci_hcd: Timeout while waiting for setup device command。
• ⚠️ 但系统没有卡死，USB 超时只是禁用 MSI 后的副作用。

9.3 排除其他设备

• nomodeset无效 → 不是 NVIDIA DRM/KMS
• 拔掉 USB 外设无效 → 不是外设问题
• NVMe 工作正常（nvme0: 1/0/0 queues）→ NVMe 不是根因

十、pci=nomsi的副作用及后续处理

10.1 副作用（ChatGPT 提供）

10.2 VSCode 无法打开

报错：

内部错误，请报告：运行 "code" 失败：timeout waiting for snap system profiles to get updated

原因：之前排查时执行了sudo systemctl mask snapd.service snapd.socket snapd.seeded.service，忘记解除屏蔽。
解决：

sudo systemctl unmask snapd.service snapd.socket snapd.seeded.service sudo systemctl start snapd sudo systemctl enable snapd

结果：VSCode 恢复正常。

10.3 永久应用pci=nomsi

sudo nano /etc/default/grub # 修改： GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi" sudo update-grub

10.4 可选：锁定稳定内核

sudo apt-mark hold linux-image-5.15.0-67-generic linux-headers-5.15.0-67-generic

十一、为什么-67正常而-139坏的最终分析

11.1 内核差异

• 5.15.0-67：2022 年底发布，PCIe 中断处理代码较保守。
• 5.15.0-139：2024 年后更新，包含了 Intel Raptor Lake 平台的 PCIe MSI 优化补丁。

11.2 硬件组合

• Intel Raptor Lake Refresh（i7-14650HX）
• Intel 700 系列 PCH
• MediaTek MT7925 Wi-Fi
• Union Memory NVMe SSD
• 特定 BIOS 版本（S9CN13WW）

11.3 BIOS 状态变化

用户误触 BIOS 设置后（按 F2 进入 BIOS 点了一下某个选项又点回来），改变了 PCIe 设备的 IRQ 路由方式，使得原本隐藏的 MSI 死锁暴露出来。

11.4 结论

Linux 5.15.0-139 在联想 Y7000P 2025 上，某个 PCIe 设备（高度怀疑 Intel xHCI USB 控制器）启用 MSI 后触发了内核级硬死锁。pci=nomsi禁用 MSI，回退到传统 INTx，绕过了该兼容性问题。

十二、后续排查方向（ChatGPT 建议）

如果未来想“精准定位”而不是“一刀切”，可以依次测试：

1. intel_iommu=off（如果有效，问题在 IOMMU + MSI 组合）
2. pci=noaer（禁用 PCIe 高级错误报告）
3. pci=nommconf（禁用 MMCONFIG）
4. 检查联想官网是否有 BIOS 更新

十三、命令执行结果汇总表

以下是用过的指令，遇到相同问题可以参考。