VPS 发生 Kernel Panic 时，很多人的第一反应是：机器是不是坏了？服务商是不是崩了？
控制台上可能只剩一屏英文：
Kernel panic - not syncing
Unable to mount root fs
Oops: 0000 [#1]
Call Trace:
RIP: 0010:...
或者你根本没看到 panic 画面，只发现 VPS 突然自动重启，业务中断，SSH 重新连上以后日志断了一截。这个时候不要只看应用日志。Kernel Panic 是内核层面的故障，排查重点在上一次启动日志、内核 ring buffer、崩溃转储和宿主机/云盘/驱动证据。
这篇按 VPS 场景讲清楚：先确认是不是 kernel panic，再判断是文件系统、内存、驱动、内核升级还是服务商底层问题，最后说明什么时候需要配置 kdump 和怎么把证据提交给服务商。
服务崩了，系统还活着；Kernel Panic 是系统内核自己撑不住了。
先看重启记录：
last -x reboot shutdown | head -n 20
再看上一次启动的错误日志：
journalctl -b -1 -p err --no-pager
如果系统支持持久化 journal，还可以看上一轮启动完整内核日志：
journalctl -k -b -1 --no-pager
重点搜索：
journalctl -k -b -1 --no-pager | grep -Ei 'panic|oops|call trace|not syncing|segfault|mce|i/o error|ext4|xfs'
如果你只看到某个服务 failed，那不一定是 kernel panic。可以先看：VPS 日志怎么看（journalctl、systemctl、Nginx、应用日志）。
Kernel Panic 的日志不需要逐字读懂，先抓关键词。
这是明确的内核恐慌。常见原因包括：
- 根文件系统挂载失败
- 关键内核模块异常
- init 进程无法启动
- 内核遇到不可恢复错误
这通常和启动盘、initramfs、fstab、内核升级或文件系统有关。
常见场景：
- 更新内核后 initramfs 没生成好
/boot或根分区异常- 云盘设备名变化
- 文件系统损坏
如果同时看到只读文件系统、fsck、emergency mode，可以参考：VPS 变成只读文件系统怎么办。
Oops 不一定立刻 panic，但说明内核遇到了严重异常。Call Trace 是调用栈，能帮助定位哪个模块或驱动出问题。
例如：
Oops: 0000 [#1] SMP PTI
Call Trace:
? some_driver_function+0x...
RIP: 0010:...
如果栈里反复出现某个模块名、文件系统名、网卡驱动名或第三方内核模块，那就是排查重点。
如果看到：
Machine Check Exception
Hardware Error
MCE
这类日志通常指向硬件或宿主机层面问题。VPS 用户无法直接换内存或 CPU，但可以把日志发给服务商，让他们检查宿主机硬件、迁移节点或更换实例。
当前系统还活着时，可以看：
dmesg -T | grep -Ei 'panic|oops|call trace|mce|hardware error|i/o error|ext4|xfs'
但如果机器已经 panic 并重启，dmesg 通常只包含这次启动后的内核日志。要看上一次启动，优先用：
journalctl -k -b -1
前提是 journal 持久化开启。如果 /var/log/journal 不存在，很多系统只保存当前启动日志。可以启用持久化：
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
这不会帮你找回已经丢失的旧 panic，但能让下一次故障更容易追。
Kernel Panic 经常发生在内核升级后，尤其是：
- 更新过程中磁盘满了
/boot空间不足- initramfs 生成失败
- 使用了不兼容的第三方模块
- 旧 VPS 镜像和新内核组合不稳定
检查最近安装记录：
grep -i 'install\|upgrade' /var/log/dpkg.log | tail -n 50
Debian / Ubuntu 也可以看 apt 历史：
grep -i kernel /var/log/apt/history.log
查看当前内核：
uname -a
列出已安装内核：
dpkg -l | grep 'linux-image'
如果你能通过服务商控制台进入 GRUB，可以尝试选择旧内核启动。不要一上来删除旧内核，至少保留一个确认能启动的版本。
Kernel Panic 不一定是内核本身有 bug。根分区、云盘、文件系统错误也可能把系统拖进 panic。
查内核日志里的 I/O 和文件系统错误：
journalctl -k -b -1 --no-pager | grep -Ei 'i/o error|buffer error|blk_update|ext4|xfs|remount|read-only'
如果看到大量：
Buffer I/O error on dev vda
EXT4-fs error
XFS metadata I/O error
要优先怀疑云盘、文件系统或宿主存储。此时不要只重启。能读数据时先备份，必要时进 rescue mode 做 fsck 或迁移到新盘。
VPS 用户看不到宿主机硬件，但内核日志有时会透露线索。
搜索硬件错误：
journalctl -k -b -1 --no-pager | grep -Ei 'mce|machine check|hardware error|edac|memory error'
如果出现 MCE 或硬件错误，不建议自己在系统里瞎修。你应该：
- 保存日志。
- 记录发生时间和时区。
- 提交服务商工单。
- 请求检查宿主机硬件、迁移 VPS 或更换节点。
如果你同时看到 steal time 高、磁盘抖动、同节点多人受影响，可以结合：VPS 超售怎么判断。
Kernel Panic 后默认行为取决于系统配置。有些系统会停在 panic 画面，有些会自动重启。
查看配置：
sysctl kernel.panic
如果希望 panic 后 10 秒自动重启：
sudo sysctl -w kernel.panic=10
永久配置：
echo 'kernel.panic = 10' | sudo tee /etc/sysctl.d/99-kernel-panic.conf
sudo sysctl --system
注意：自动重启能减少停机时间，但也可能掩盖现场。生产系统建议配合监控告警和 kdump，不要只靠自动重启。
如果 Kernel Panic 反复出现，但日志里看不出根因，就需要 kdump。
kdump 的作用是：系统崩溃时，保留一份内存转储文件 vmcore，之后用 crash 工具分析。
Debian / Ubuntu 安装：
sudo apt install kdump-tools crash linux-crashdump -y
RHEL / Rocky / AlmaLinux：
sudo dnf install kexec-tools crash -y
启用后要确认 crashkernel 参数是否存在：
cat /proc/cmdline | grep crashkernel
kdump 是否正常：
systemctl status kdump-tools
systemctl status kdump
不同发行版服务名不同。VPS 内存很小的时候，预留 crashkernel 会占用一部分内存，1GB 以下的小机器要谨慎。
如果成功生成 vmcore，常见路径可能是：
/var/crash/
/var/lib/systemd/coredump/
/var/crash/127.0.0.1-YYYY-MM-DD-...
用 crash 分析需要：
- vmcore 文件
- 对应内核的 vmlinux / debug symbols
基本命令类似：
sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/vmcore
进入 crash 后，可以用：
bt
log
ps
kmem -i
sys
对大多数 VPS 用户来说，不需要自己完整读懂 crash 输出。更现实的做法是：确认 vmcore 已生成，把关键信息和服务商工单一起提交。对于自管业务团队，至少能从 bt 和 log 看出是否和某个模块、文件系统、驱动或内存错误有关。
不要只写：“机器 Kernel Panic 了，请处理。”
更好的工单内容：
故障时间：2026-05-25 10:18 Asia/Shanghai
现象：VPS 自动重启，业务中断约 2 分钟
实例 ID：xxx
系统：Ubuntu 24.04 / kernel xxx
已确认：
- last -x 显示异常 reboot
- journalctl -k -b -1 中出现 Kernel panic / Call Trace
- dmesg 中有/无 I/O error
- MCE/Hardware Error 有/无
附件：
- journalctl -k -b -1 输出
- last -x reboot shutdown 输出
- vmcore（如有）
如果日志里有 I/O error、MCE、宿主资源异常，明确要求服务商检查宿主机、云盘和迁移可能性。
遇到 VPS Kernel Panic 或异常重启，按这个顺序查：
last -x reboot shutdown确认异常重启时间。journalctl -b -1 -p err看上一轮启动错误。journalctl -k -b -1搜索panic/oops/call trace/mce/i/o error。- 检查最近是否更新内核、initramfs 或第三方模块。
- 搜索文件系统和云盘错误：
ext4/xfs/i/o error/read-only。 - 搜索硬件错误：
mce/machine check/hardware error。 - 必要时设置
kernel.panic=10降低停机时间。 - 反复出现时配置 kdump，收集 vmcore。
- 用 crash 取
bt/log/sys基础信息。 - 带完整时间线和日志开服务商工单。
Kernel Panic 不是普通应用崩溃。它通常意味着内核、文件系统、云盘、驱动、硬件或宿主机层面出现了不可恢复问题。
先用 journalctl -k -b -1 和 last -x 还原时间线，再按关键词区分文件系统、内核升级、MCE 硬件错误和驱动异常。一次性的 panic 可以先观察；反复出现就要配置 kdump 留 vmcore，并把证据提交给服务商。不要只靠重启掩盖问题，否则下一次可能发生在业务高峰期。