为Proxmox启动kdump

为Proxmox启动Kdump捕获异常

本文将记录如何在Proxmox系统中安装配置Kdump，Kdump可以在系统遇到故障时及时捕获异常，是系统排障的最佳选择之一，建议所有人为自己的Proxmox系统安装配置以备不时之需。

当然如果有可能，我更希望你永远也用不上这个。

测试环境

硬件环境

AMD 7950X
TUF B650M Plus
128G DDR5
256+1T

软件环境

Proxmox 8.1.3

安装软件

apt update
apt install kdump -y

配置软件

编辑配置文件

编辑Kdump的配置文件，如果自行选择使用nano或者vim编辑，个人推荐nano好用一点。

nano /etc/default/grub.d/kdump-tools.cfg

如果我们的版本一样或者差不多的话，里面只有一行配置，你的配置应该和这个类似，但是后面的一些参数可能你的会和下面的有所不同。

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=512M-2G:64M,2G-100G:128M,100G-:2G"

配置解释

crashkernel:

• 这个参数用于为 kdump 保留特定数量的内存。当系统崩溃时，kdump 会使用这部分内存启动一个崭新的内核来捕获内存转储。
• 根据系统总内存的不同，保留不同大小的内存块。格式为：<内存范围>:<保留内存大小>，多个范围用逗号分隔。

所以你可以粗略的将冒号作为分隔线，比如下面的配置可以说明为。

• 512M-2G:64M
  • 当系统内存为512M 到 2G时，分配64M给Kdump用于处理崩溃后的系统。
• 2G-100G:128M
  • 当系统内存为2G 到 100G时，分配128M给Kdump用于处理崩溃后的系统。
• 100G-:2G
  • 当系统的内存大于100G时，分配2G给Kdump用于处理崩溃后的系统。

检查Kdump服务

检查Kdump是否已经启动。

systemctl status kdump-tools
root@pve:~# systemctl status kdump-tools
● kdump-tools.service - Kernel crash dump capture service
     Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2024-06-25 18:21:35 CST; 17min ago
    Process: 1292 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS)
   Main PID: 1292 (code=exited, status=0/SUCCESS)
        CPU: 354ms

如果你得到的结果和上面类似，是active，则代表Kdump已经正常启动。
如果你不确定这个服务是否开机启动，请使用

systemctl enable kdump-tools

保存文件，输入update-grub命令来让配置生效。

reboot，重启系统。

验证生效

pve重启完成后，可以在journalctl查看kdump启动的日志，如果你的启动出现了明显失败的字样，比如fail，bye等字样，则为配置有误，需要检查配置是否正确。

root@pve:~# journalctl -r -u kdump-tools
Jun 25 18:21:35 pve systemd[1]: Finished kdump-tools.service - Kernel crash dump capture service.
Jun 25 18:21:35 pve kdump-tools[1423]: loaded kdump kernel
Jun 25 18:21:35 pve kdump-tools[1420]: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.5.11-4-pve root=/dev/mapper/pve-root ro quiet reset_devices sy>
Jun 25 18:21:35 pve kdump-tools[1330]: loaded kdump kernel.
Jun 25 18:21:35 pve kdump-tools[1330]: Creating symlink /var/lib/kdump/initrd.img.
Jun 25 18:21:35 pve kdump-tools[1330]: Creating symlink /var/lib/kdump/vmlinuz.
Jun 25 18:21:35 pve kdump-tools[1292]: Starting kdump-tools:
Jun 25 18:21:35 pve systemd[1]: Starting kdump-tools.service - Kernel crash dump capture service...

崩溃转储验证

请注意，本操作会直接崩掉系统(不会造成硬件损害)，请勿在生产环境进行。
请注意，本操作会直接崩掉系统(不会造成硬件损害)，请勿在生产环境进行。
请注意，本操作会直接崩掉系统(不会造成硬件损害)，请勿在生产环境进行。

注意观察链接系统的屏幕，在命令行输入

echo c > /proc/sysrq-trigger

输入后系统光标卡死，键盘灯熄灭，较短一些时间后系统重启。
如果此时你的系统长时间卡死没有重启，可能代表你的Kdump配置有误，需要去检查配置文件，网上有一些说法，让你去改的文件和我上面指出的文件不一致，注意甄别。

重启启动完成后，可以使用journalctl看到kdump的工作日志，同时也可以发现journalctl并没有记录下我们需要的日志，这就是使用kdump的意义，详情见下方的Jun 25 18:51:11 pve kdump-tools[508]:开始。

Jun 25 18:51:11 pve systemd[1]: Starting kdump-tools-dump.service - Kernel crash dump capture service...
Jun 25 18:51:11 pve systemd[1]: open-iscsi.service - Login to default iSCSI targets was skipped because no trigger condition checks were met.
Jun 25 18:51:11 pve systemd[1]: Reached target remote-fs-pre.target - Preparation for Remote File Systems.
Jun 25 18:51:11 pve systemd[1]: Finished blk-availability.service - Availability of block devices.
Jun 25 18:51:11 pve kdump-tools[508]: Starting kdump-tools:
Jun 25 18:51:11 pve kdump-tools[512]: running makedumpfile -F -c -d 31 /proc/vmcore | compress > /var/crash/202406251851/dump-incomplete.
Jun 25 18:51:11 pve kernel: vmbr0: port 1(eno1) entered disabled state
Jun 25 18:51:18 pve kdump-tools[528]: [1.6K blob data]
Jun 25 18:51:18 pve kdump-tools[528]: The dumpfile is saved to STDOUT.
Jun 25 18:51:18 pve kdump-tools[528]: makedumpfile Completed.
Jun 25 18:51:18 pve kdump-tools[512]: kdump-tools: saved vmcore in /var/crash/202406251851.
Jun 25 18:51:18 pve kdump-tools[532]: saved vmcore in /var/crash/202406251851
Jun 25 18:51:18 pve kdump-tools[512]: running makedumpfile --dump-dmesg /proc/vmcore /var/crash/202406251851/dmesg.202406251851.
Jun 25 18:51:18 pve kdump-tools[534]: The dmesg log is saved to /var/crash/202406251851/dmesg.202406251851.
Jun 25 18:51:18 pve kdump-tools[534]: makedumpfile Completed.
Jun 25 18:51:18 pve kdump-tools[512]: kdump-tools: saved dmesg content in /var/crash/202406251851.
Jun 25 18:51:18 pve kdump-tools[535]: saved dmesg content in /var/crash/202406251851
Jun 25 18:51:18 pve kdump-tools[537]: Tue, 25 Jun 2024 18:51:18 +0800
-- Boot 3d384452b3d744db8ad7b48b3629a29e --
Jun 25 18:51:38 pve kernel: Linux version 6.5.11-4-pve (fgruenbichler@yuna) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEM>

进入崩溃日志的储存目录，可以看到产生了今日的崩溃记录202406251851,进入文件夹后可以看到包含两个文件。

注意，其实正常情况下，应该会生成vmcore，至于为什么没有生成的原因是因为Proxmox的这个核心似乎不受支持，如果你使用了市面上较为常用的系统安装Proxmox，则会产生vmcore文件，你可以使用crash工具读取该文件，这个文件中包含了崩溃时系统的很多状态，可以更细致的分析问题原因。你可以使用uname -r看到自己的系统信息，如果你不是使用Proxmox官方的安装工具安装而在其他Linux发行版中安装，vmcore将对你可用。

cd /var/crash
root@pve:/var/crash# ls
202406251851  kdump_lock  kexec_cmd
root@pve:/var/crash/202406251851# ls
dmesg.202406251851  dump.202406251851

使用nano查看dmesg.202406251851文件翻页到最下方，可以发现问题原因是我们之前输入的指令，注意1777.129960的那一行。

[   17.616160] [    T238] vmbr0: port 1(eno1) entered forwarding state
[   17.942498] [   T1740] kvm[1740]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
[ 1777.129960] [   T5956] sysrq: Trigger a crash
[ 1777.129977] [   T5956] Kernel panic - not syncing: sysrq triggered crash
[ 1777.129987] [   T5956] CPU: 21 PID: 5956 Comm: bash Kdump: loaded Tainted: P           O       6.5.11-4-pve #1
[ 1777.129998] [   T5956] Hardware name: ASUS System Product Name/TUF GAMING B650M-PLUS, BIOS 2613 04/12/2024
[ 1777.130013] [   T5956] Call Trace:
[ 1777.130019] [   T5956]  <TASK>
[ 1777.130026] [   T5956]  dump_stack_lvl+0x48/0x70
[ 1777.130036] [   T5956]  dump_stack+0x10/0x20
[ 1777.130043] [   T5956]  panic+0x2e8/0x360
[ 1777.130051] [   T5956]  ? srso_alias_return_thunk+0x5/0x7f
[ 1777.130061] [   T5956]  sysrq_handle_crash+0x1a/0x20
[ 1777.130070] [   T5956]  __handle_sysrq+0xe5/0x1a0
[ 1777.130076] [   T5956]  ? wp_page_reuse+0x67/0x90
...

Tips

一般情况下，如果你的pve突然出现莫名其妙的突然重启，如果确认你的主板的来源正规的话(非二手非咸鱼)，大部分情况下是内存的锅，你可以在错误日志出频繁看到page相关的错误，本条仅供参考。

总结

一般情况下，只要不是在那种特别恶劣的环境下，即使是消费级硬件，也可以有很好的稳定性，但是Kdump作为一个保底排查手段，仍然建议安装使用。
另外某些对自己系统稳定性特别有自信的选手其实可以选配这个，毕竟，我自己就有一台特别能抗的，附一张自己一台消费级设备的在线时间，中途因为吹灰关了一次机，如果不吹灰的话大约是400d+稳定。