What to Do When a VPS Kernel Panics (2026): kdump, vmcore, journalctl, and crash Troubleshooting Guide

When a service crashes, the system is still alive; a Kernel Panic is when the system kernel itself can't hold on.

First check the reboot records:

last -x reboot shutdown | head -n 20

Then check the error logs from the previous boot:

journalctl -b -1 -p err --no-pager

If the system supports persistent journal, you can also view the complete kernel log from the previous boot:

journalctl -k -b -1 --no-pager

Key things to search for:

journalctl -k -b -1 --no-pager | grep -Ei 'panic|oops|call trace|not syncing|segfault|mce|i/o error|ext4|xfs'

If you only see a certain service failed, that isn't necessarily a kernel panic. You can first read: How to read VPS logs (journalctl, systemctl, Nginx, application logs).

You don't need to read Kernel Panic logs word by word; first grab the keywords.

Oops: 0000 [#1] SMP PTI
Call Trace:
  ? some_driver_function+0x...
RIP: 0010:...

Machine Check Exception
Hardware Error
MCE

When the current system is still alive, you can view:

dmesg -T | grep -Ei 'panic|oops|call trace|mce|hardware error|i/o error|ext4|xfs'

But if the machine has already panicked and rebooted, dmesg usually only contains the kernel logs since this boot. To see the previous boot, prefer:

journalctl -k -b -1

This requires persistent journal to be enabled. If /var/log/journal doesn't exist, many systems only keep the current boot logs. You can enable persistence:

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

This won't help you recover an old panic that's already lost, but it will make the next failure easier to trace.

Kernel Panics often happen after a kernel upgrade, especially when:

• The disk filled up during the update
• /boot ran out of space
• initramfs generation failed
• An incompatible third-party module is used
• The combination of an old VPS image and a new kernel is unstable

Check recent installation records:

grep -i 'install\|upgrade' /var/log/dpkg.log | tail -n 50

On Debian / Ubuntu you can also check the apt history:

grep -i kernel /var/log/apt/history.log

View the current kernel:

uname -a

List installed kernels:

dpkg -l | grep 'linux-image'

If you can enter GRUB through the provider's console, you can try booting an older kernel. Don't delete old kernels right away; keep at least one version that you've confirmed can boot.

A Kernel Panic isn't necessarily a bug in the kernel itself. Root partition, cloud disk, and filesystem errors can also drag the system into a panic.

Check the kernel logs for I/O and filesystem errors:

journalctl -k -b -1 --no-pager | grep -Ei 'i/o error|buffer error|blk_update|ext4|xfs|remount|read-only'

If you see a lot of:

Buffer I/O error on dev vda
EXT4-fs error
XFS metadata I/O error

You should first suspect the cloud disk, filesystem, or host storage. At this point, don't just reboot. Back up data while it's still readable, and if necessary enter rescue mode to run fsck or migrate to a new disk.

VPS users can't see the host hardware, but kernel logs sometimes reveal clues.

Search for hardware errors:

journalctl -k -b -1 --no-pager | grep -Ei 'mce|machine check|hardware error|edac|memory error'

If MCE or hardware errors appear, it's not advisable to try to fix it yourself inside the system. You should:

1. Save the logs.
2. Record the time and time zone when it happened.
3. Submit a ticket to the provider.
4. Request a check of the host hardware, migration of the VPS, or replacement of the node.

If you also see high steal time, disk jitter, and multiple people on the same node affected, you can combine this with: How to tell if a VPS is oversold.

The default behavior after a Kernel Panic depends on the system configuration. Some systems stop at the panic screen, others reboot automatically.

Check the configuration:

sysctl kernel.panic

If you want it to reboot automatically 10 seconds after a panic:

sudo sysctl -w kernel.panic=10

Permanent configuration:

echo 'kernel.panic = 10' | sudo tee /etc/sysctl.d/99-kernel-panic.conf
sudo sysctl --system

Note: automatic reboot can reduce downtime, but it may also cover up the scene. For production systems, it's recommended to pair it with monitoring alerts and kdump, not rely on automatic reboot alone.

If Kernel Panics occur repeatedly but the root cause can't be seen in the logs, you need kdump.

kdump's role is: when the system crashes, preserve a memory dump file vmcore, then analyze it later with the crash tool.

Debian / Ubuntu installation:

sudo apt install kdump-tools crash linux-crashdump -y

RHEL / Rocky / AlmaLinux:

sudo dnf install kexec-tools crash -y

After enabling, confirm whether the crashkernel parameter exists:

cat /proc/cmdline | grep crashkernel

Whether kdump is working properly:

systemctl status kdump-tools
systemctl status kdump

The service name differs across distributions. When VPS memory is very small, reserving crashkernel takes up part of the memory, so be cautious on small machines under 1GB.

If a vmcore is successfully generated, the common path may be:

/var/crash/
/var/lib/systemd/coredump/
/var/crash/127.0.0.1-YYYY-MM-DD-...

Analyzing with crash requires:

• The vmcore file
• The vmlinux / debug symbols for the corresponding kernel

The basic command is similar to:

sudo crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/vmcore

After entering crash, you can use:

bt
log
ps
kmem -i
sys

For most VPS users, there's no need to fully understand the crash output yourself. A more realistic approach is: confirm the vmcore has been generated, and submit the key information together with the provider's ticket. For self-managed business teams, at least you can tell from bt and log whether it's related to a certain module, filesystem, driver, or memory error.

Don't just write: "The machine had a Kernel Panic, please handle it."

Better ticket content:

故障时间：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（如有）

If the logs contain I/O error, MCE, or host resource anomalies, explicitly ask the provider to check the host, cloud disk, and migration possibilities.

When you encounter a VPS Kernel Panic or abnormal reboot, check in this order:

1. last -x reboot shutdown to confirm the abnormal reboot time.
2. journalctl -b -1 -p err to see the previous boot errors.
3. journalctl -k -b -1 to search for panic/oops/call trace/mce/i/o error.
4. Check whether the kernel, initramfs, or third-party modules were recently updated.
5. Search for filesystem and cloud disk errors: ext4/xfs/i/o error/read-only.
6. Search for hardware errors: mce/machine check/hardware error.
7. If necessary, set kernel.panic=10 to reduce downtime.
8. If it occurs repeatedly, configure kdump and collect vmcore.
9. Use crash to get basic bt/log/sys information.
10. Open a provider ticket with the complete timeline and logs.

A Kernel Panic is not an ordinary application crash. It usually means an unrecoverable problem has occurred at the kernel, filesystem, cloud disk, driver, hardware, or host level.

First use journalctl -k -b -1 and last -x to reconstruct the timeline, then use keywords to distinguish filesystem, kernel upgrade, MCE hardware errors, and driver anomalies. A one-off panic can be observed first; if it occurs repeatedly, configure kdump to keep the vmcore and submit the evidence to the provider. Don't just rely on rebooting to cover up the problem, otherwise the next one may happen during peak business hours.