排查内核 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_blklsinitrd /boot/initrd.img | grep -i virtio重建 initramfsDebian/Ubuntuupdate-initramfs -u -k allRHEL 系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 配置OOMScoreAdjust500。用 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路径。检查是否有实时进程长时间占据 CPUchrt -p PIDVPS 中若偶发且与自身软件无关考虑更换实例类型或迁移。临时规避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_STACK5.x 默认开启可提供一定保护。10. Kernel panic - not syncing: Requested init /init failed (error -13) 或 -2 (ENOENT)含义内核找不到/init或无权执行用户态启动失败。常见于 initramfs 损坏、内核命令行错误或 rootfs 挂载问题。怎么查检查内核命令行init参数路径是否正确通常默认/init。进入救援模式检查/init是否存在且具有可执行权限。重新生成 initramfsdpkg-reconfigure initramfs-tools然后update-initramfs -u。确认根文件系统未以noexec方式挂载。通用排查准备无论哪种 panic 都应该提前配置当 VNC 不可用时以下手段能保留下一次崩溃的现场持久化日志journalctl -k -b -1可查看上次启动内核日志在/etc/systemd/journald.conf设置Storagepersistent避免重启丢失。安装 kdumpapt install linux-crashdump或yum install kexec-tools崩溃后/var/crash下生成 vmcore用crash分析。配置 netconsole实时发送内核日志到远端服务器modprobe netconsole netconsole本机IP/,远端IP/开启 pstore内核参数添加pstore.backendramoops将 panic 日志保存于保留内存重启后挂载读取mount -t pstore pstore /sys/fs/pstore分析调用栈忽略顶层dump_stack、panic直接看底部具体函数名定位子系统。拿到 panic 字符串后按上述条目对号入座再用对应工具深入。若无法匹配将完整 panic 输出原样提交到内核社区或发行版论坛是获得帮助的最有效方式。
常见内核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_blklsinitrd /boot/initrd.img | grep -i virtio重建 initramfsDebian/Ubuntuupdate-initramfs -u -k allRHEL 系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 配置OOMScoreAdjust500。用 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路径。检查是否有实时进程长时间占据 CPUchrt -p PIDVPS 中若偶发且与自身软件无关考虑更换实例类型或迁移。临时规避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_STACK5.x 默认开启可提供一定保护。10. Kernel panic - not syncing: Requested init /init failed (error -13) 或 -2 (ENOENT)含义内核找不到/init或无权执行用户态启动失败。常见于 initramfs 损坏、内核命令行错误或 rootfs 挂载问题。怎么查检查内核命令行init参数路径是否正确通常默认/init。进入救援模式检查/init是否存在且具有可执行权限。重新生成 initramfsdpkg-reconfigure initramfs-tools然后update-initramfs -u。确认根文件系统未以noexec方式挂载。通用排查准备无论哪种 panic 都应该提前配置当 VNC 不可用时以下手段能保留下一次崩溃的现场持久化日志journalctl -k -b -1可查看上次启动内核日志在/etc/systemd/journald.conf设置Storagepersistent避免重启丢失。安装 kdumpapt install linux-crashdump或yum install kexec-tools崩溃后/var/crash下生成 vmcore用crash分析。配置 netconsole实时发送内核日志到远端服务器modprobe netconsole netconsole本机IP/,远端IP/开启 pstore内核参数添加pstore.backendramoops将 panic 日志保存于保留内存重启后挂载读取mount -t pstore pstore /sys/fs/pstore分析调用栈忽略顶层dump_stack、panic直接看底部具体函数名定位子系统。拿到 panic 字符串后按上述条目对号入座再用对应工具深入。若无法匹配将完整 panic 输出原样提交到内核社区或发行版论坛是获得帮助的最有效方式。
