CentOS 7 升级内核后 kdump 不能启动
20231108 by Xia Haitao
现象
一般是升级内核后会出现这个问题，kdump 服务无法启动，系统启动时会报错。
Failed to start Crash recovery kernel arming
See 'systemctl status kdump.service' for details
查看 kdump 服务，服务启动失败。
[root@ai66 test_k8s_log]# systemctl status kdump.service
● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2023-11-01 15:24:49 CST; 6 days ago
Process: 1070 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE)
Main PID: 1070 (code=exited, status=1/FAILURE)
Nov 01 15:24:49 ai66 systemd[1]: Starting Crash recovery kernel arming...
Nov 01 15:24:49 ai66 kdumpctl[1070]: No memory reserved for crash kernel
Nov 01 15:24:49 ai66 kdumpctl[1070]: Starting kdump: [FAILED]
Nov 01 15:24:49 ai66 systemd[1]: kdump.service: main process exited, code=exited, status=1/FAILURE
Nov 01 15:24:49 ai66 systemd[1]: Failed to start Crash recovery kernel arming.
Nov 01 15:24:49 ai66 systemd[1]: Unit kdump.service entered failed state.
Nov 01 15:24:49 ai66 systemd[1]: kdump.service failed.
解决
1、系统无法启动
启动时，在 grub 节目按 e，进入grub修改启动项，然后启动。
# 默认值是 auto
crashkernel=auto
# 改为预定义值（predefined）， 128M、256M 或 512M
crashkernel=256M
2、系统可以启动
# 1）修改默认 grub 文件
vim /etc/default/grub
# 改为预定义值（predefined）， 128M、256M 或 512M
crashkernel=256M
# 2）重新生成启动 grub 文件，可以先看看原来文件在哪个目录，先备份再生成
# UEFI 启动
cp /boot/efi/EFI/centos/grub.cfg /boot/efi/EFI/centos/grub.cfg.bak
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.19.12-1.el7.elrepo.x86_64
Found initrd image: /boot/initramfs-4.19.12-1.el7.elrepo.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-693.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-693.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-fbb0faf5108c4bf4b8c6898af707e091
Found initrd image: /boot/initramfs-0-rescue-fbb0faf5108c4bf4b8c6898af707e091.img
done
# 早期 Legacy 启动的使用下面命令
cp /boo/grub2/grub.cfg /boo/grub2/grub.cfg.bak
grub2-mkconfig -o /boo/grub2/grub.cfg
# 3）重启
reboot
3、验证
重新查看服务
systemctl status kdump.service
● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2023-11-08 11:00:38 CST; 3min 14s ago
Process: 1068 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Main PID: 1068 (code=exited, status=0/SUCCESS)
Memory: 0B
CGroup: /system.slice/kdump.service
Nov 08 11:00:38 ai66 kdumpctl[1068]: Unknown type (Reserved) while parsing /sys/firmware/memmap/11/type. Please
Nov 08 11:00:38 ai66 kdumpctl[1068]: Unknown type (Reserved) while parsing /sys/firmware/memmap/1/type. Please
Nov 08 11:00:38 ai66 kdumpctl[1068]: Unknown type (Reserved) while parsing /sys/firmware/memmap/18/type. Please
Nov 08 11:00:38 ai66 kdumpctl[1068]: Unknown type (Reserved) while parsing /sys/firmware/memmap/8/type. Please
Nov 08 11:00:38 ai66 kdumpctl[1068]: Unknown type (Reserved) while parsing /sys/firmware/memmap/16/type. Please
Nov 08 11:00:38 ai66 kdumpctl[1068]: Unknown type (Reserved) while parsing /sys/firmware/memmap/6/type. Please
Nov 08 11:00:38 ai66 kdumpctl[1068]: Unknown type (Reserved) while parsing /sys/firmware/memmap/14/type. Please
Nov 08 11:00:38 ai66 kdumpctl[1068]: kexec: loaded kdump kernel
Nov 08 11:00:38 ai66 kdumpctl[1068]: Starting kdump: [OK]
Nov 08 11:00:38 ai66 systemd[1]: Started Crash recovery kernel arming.
this is my test!