常见内核panic错误排查
排查内核 panic，能拿到屏幕输出是最直接的。如果你还能打开云厂商的 VNC 控制台，第一时间看虚拟机“屏幕上”打出的 panic 信息，把关键行记下来。如果连 VNC 也已经挂掉、没留下截图，那就只能回头从系统里残存的内核日志入手，逐条排查。下面列出最常见的 10 种 panic 信息，无论从屏幕上看到还是在日志里搜到，都可以直接对照定位。
1. VFS: Unable to mount root fs on unknown-block(0,0)
含义
内核找不到根文件系统。常见于磁盘驱动未加载、根设备名称错误或 initramfs 缺失/损坏。
怎么查
- 确认根设备：
cat /proc/cmdline或查看grub.cfg中的root=参数。 - 检查 initramfs 是否包含对应存储驱动（VPS 常用 virtio_blk）：
lsinitrd /boot/initrd.img | grep -i virtio - 重建 initramfs：
Debian/Ubuntu：update-initramfs -u -k all
RHEL 系：dracut -f - 若在内核升级后出现，回退旧内核即可快速恢复。
2. Kernel panic - not syncing: Attempted to kill init!
含义
init (PID 1) 被杀死。通常是 OOM Killer 选中了 init，或 init 自身段错误退出。
怎么查
- 检查同屏 OOM 信息：
dmesg | grep -i "out of memory"或journalctl -k -b -1 | grep oom - 列出被杀进程：
grep -i "Killed process" /var/log/syslog - 查看 init 自身输出：
journalctl -b -1 -u init.scope - 确认内存不足时，增加 swap 或物理内存，排查内存泄漏进程。
3. Kernel panic - not syncing: Out of memory and no killable processes
含义
内存耗尽，但 OOM Killer 找不到可杀的用户进程。可能所有用户进程都设了oom_score_adj=-1000，或只剩内核线程。
怎么查
- 列出 OOM 免疫进程：
ps -eo pid,comm,oom_score_adj --sort=-oom_score_adj | head - 对非关键服务降低免疫级别，或通过 systemd 配置
OOMScoreAdjust=500。 - 用 cgroup 的
MemoryMax限制高风险服务。 - 务必配置 swap 作为缓冲，哪怕只是应急。
4. Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
含义
内核栈被越界写破坏，堆栈保护触发。通常由第三方内核模块或驱动 bug 引起。
怎么查
- 查看调用栈顶部函数，定位可疑模块。
- 用
cat /proc/sys/kernel/tainted查看内核污染原因。 - 卸载无关模块（如
tcp_kcc、闭源驱动），重启观察。 - 升级内核或移除不可信模块。
5. Kernel panic - not syncing: Fatal exception in interrupt
含义
中断处理期间发生不可恢复错误，常伴随Oops和Call Trace。
怎么查
- 分析调用栈底部函数，常见于网卡、存储控制器的中断处理代码。
- 卸载对应驱动测试：
modprobe -r <driver> - 检查
/proc/interrupts中相关中断计数是否异常暴增。 - 在 VPS 环境，若怀疑宿主机问题，可迁移实例。
6. NMI watchdog: BUG: soft lockup - CPU#x stuck for xx s
含义
CPU 在内核态执行时间超过阈值（通常 20 秒以上），无法调度。常见于死循环、自旋锁争抢或虚拟化调度延迟。
怎么查
- 从调用栈定位卡死函数，重点关注
spin_lock、mutex_lock路径。 - 检查是否有实时进程长时间占据 CPU：
chrt -p <PID> - VPS 中若偶发且与自身软件无关，考虑更换实例类型或迁移。
- 临时规避：
echo 0 > /proc/sys/kernel/nmi_watchdog（不解决问题）。
7. Kernel panic - not syncing: Aiee, killing interrupt handler!
含义
中断处理程序内部发生严重错误，内核主动终止该中断上下文。
怎么查
- 查看紧随的
Oops信息，定位中断处理函数。 - 检查是否同时出现 Machine Check 错误：
dmesg | grep -i "machine check" - 查看
/proc/interrupts，观察各 IRQ 异常计数。 - 更新固件/驱动，或重分配中断，必要时更换内核版本。
8. Kernel panic - not syncing: Machine Check Exception (MCE)
含义
CPU 检测到致命硬件错误（缓存 ECC 故障、总线错误等）。虚拟化环境下可能反映宿主机硬件问题。
怎么查
- 安装
mcelog或rasdaemon，查看 MCE 记录：mcelog --client - 检查内核日志中
mce:段，确定错误来源（CPU 核、内存 Bank）。 - 联系云厂商，说明实例遇到 MCE，请求排查宿主机或迁移实例。
9. Kernel panic - not syncing: corrupted stack end detected inside scheduler
含义
调度器检测到内核栈破坏，通常因栈溢出或内存踩踏。
怎么查
- 确认内核栈大小：
ulimit -s和CONFIG_FRAME_WARN内核配置项。 - 排查使用深度递归的内核模块（如某些文件系统）。
- 若有 kdump，用
crash工具分析 vmcore，检查线程栈底魔数。 - 移除可疑模块；
CONFIG_VMAP_STACK（5.x+ 默认开启）可提供一定保护。
10. Kernel panic - not syncing: Requested init /init failed (error -13) 或 -2 (ENOENT)
含义
内核找不到/init或无权执行，用户态启动失败。常见于 initramfs 损坏、内核命令行错误或 rootfs 挂载问题。
怎么查
- 检查内核命令行
init=参数路径是否正确（通常默认/init）。 - 进入救援模式，检查
/init是否存在且具有可执行权限。 - 重新生成 initramfs：
dpkg-reconfigure initramfs-tools，然后update-initramfs -u。 - 确认根文件系统未以
noexec方式挂载。
通用排查准备（无论哪种 panic 都应该提前配置）
当 VNC 不可用时，以下手段能保留下一次崩溃的现场：
- 持久化日志：
journalctl -k -b -1可查看上次启动内核日志；在/etc/systemd/journald.conf设置Storage=persistent，避免重启丢失。 - 安装 kdump：
apt install linux-crashdump或yum install kexec-tools，崩溃后/var/crash下生成 vmcore，用crash分析。 - 配置 netconsole：实时发送内核日志到远端服务器：
modprobe netconsole netconsole=@本机IP/,@远端IP/ - 开启 pstore：内核参数添加
pstore.backend=ramoops，将 panic 日志保存于保留内存，重启后挂载读取：mount -t pstore pstore /sys/fs/pstore - 分析调用栈：忽略顶层
dump_stack、panic，直接看底部具体函数名，定位子系统。
拿到 panic 字符串后，按上述条目对号入座，再用对应工具深入。若无法匹配，将完整 panic 输出原样提交到内核社区或发行版论坛，是获得帮助的最有效方式。