CentOS 7 升级内核后 kdump 不能启动

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!