Linux kernel panic 应急处理方法

不能。kernel panic 时内核已停止调度，键盘等所有设备驱动基本失效，按键无响应，唯一安全方式是长按电源键断电。

kernel panic 发生时屏幕卡死，还能按键盘吗？ 不能。一旦触发 kernel panic，内核已停止调度，键盘、鼠标、网络等所有设备驱动基本失效，仅部分硬件（如串口）可能仍有输出能力。此时任何按键操作都无响应，强行长按电源键是唯一安全断电方式——但要注意：若使用 LVM 或 ext4 挂载为 data=ordered 以外模式，突然断电可能导致文件系统元数据损坏。

• 真正有效的“响应”只发生在 panic 前一刻：比如看到 Kernel panic - not syncing: Attempted to kill init! 后迅速拍照/手记下前 3 行错误地址和模块名
• 若配置了串口控制台（console=ttyS0,115200），panic 信息会输出到串口，可用另一台机器抓取
• 不要尝试盲按 Alt+SysRq 组合键——现代发行版默认禁用 sysrq，且 panic 已发生时该机制通常无法激活

如何从 dmesg 或日志里提前发现 panic 苗头？ panic 很少凭空出现，多数由此前的 WARNING、bug、Oops 逐步升级而来。关键不是等 panic，而是盯住这些信号：

• dmesg -T | grep -E "(Oops|WARNING|BUG|invalid opcode|slab Error)" —— 尤其关注带模块名（如 nvme、iwlwifi）或内存地址（如 ip ffffffffa0123456）的行
• /var/log/kern.log 中重复出现的 buffer I/O error on dev sda1 可能预示磁盘固件故障，后续易引发 panic
• 使用 journalctl -k --since "2 hours ago" | grep -i "unable to handle" 快速过滤内核异常上下文
• 注意 soft lockup 和 hard lockup 日志：前者说明某个 CPU 核心长时间未调度，后者意味着完全死锁，都是 panic 前兆

重启后怎么快速定位是哪个模块或硬件惹的祸？ 别急着重装系统。先做三件事：

• 检查 dmesg -T 开机日志里是否有 loading module xxx 后紧跟着 init_module: xxx: probe failed —— 特别是闭源驱动（nvidia、amdgpu-pro、rtl8821ae）
• 运行 lsmod | awk '$3 > 1000 {print $1,$3}' 查看加载次数异常高的模块，结合 modinfo <module_name></module_name> 看是否含 author: "Proprietary" 字样
• 用 sudo smartctl -a /dev/sda 检查磁盘 Reallocated_Sector_Ct 和 Current_Pending_Sector 是否非零；用 sudo memtest86+ 跑一整轮内存测试（BIOS 中启动，不依赖内核）
• 若最近更新过内核，用 GRUB 启动旧版本（如 vmlinuz-5.15.0-91-Generic）验证是否复现——很多 panic 是新内核对某款老网卡/RAID 卡兼容回退导致

怎样让 panic 时自动保存现场而不是黑屏？ 默认 panic 后不写磁盘，因为文件系统可能已不一致。但可通过以下方式捕获关键信息：

• 添加内核启动参数：oops=panic crashkernel=auto，并确保安装 kdump-tools（debian/ubuntu）或 kexec-tools（RHEL/centos）
• 验证是否生效：cat /sys/kernel/kexec_crash_loaded 应返回 1；systemctl status kdump 应为 active
• panic 后系统会自动切换到保留内存中的捕获内核，生成 /var/crash/ 下的 vmcore 文件，用 crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/*/vmcore 分析
• 注意：启用 kdump 后，系统启动时会预留约 128–256MB 内存，低配机器（≤2GB RAM）可能因内存不足导致服务启动失败

有些 panic 现场根本留不住——比如发生在 early boot 阶段、或硬件直接拉闸（如 PSU 不稳）。这时候真正有用的，其实是上次正常运行时的 dmesg 快照和模块加载顺序记录。