Why does kdumpctl reset-crashkernel set an incorrect crashkernel value on systems with less than 2 GB RAM in RHEL 10?

Solution Verified - Updated

Environment

  • Red Hat Enterprise linux 10
  • kdump

Issue

  • Why does kdumpctl reset-crashkernel set an incorrect crashkernel value on systems with less than 2 GB RAM in RHEL 10?
  • kdumpctl reset-crashkernel command sets the following crashkernel value for system having less than 2 GB of RAM:
# cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-55.12.1.el10_0.x86_64 root=/dev/mapper/rhel_dhcp131--77-root ro resume=UUID=d8469a6f-cf99-4dac-a1c9-a7031815465e rd.lvm.lv=rhel_dhcp131-77/root rd.lvm.lv=rhel_dhcp131-77/swap rhgb quiet crashkernel=2G-64G:256M,64G-:512M

Resolution

  • A private jira RHEL-93334 has been created to address the issue either to ensure the crashkernel is not set or to provide an appropriate error or warning message. For more information, please open a support case with Red Hat.

Root Cause

With new kernel features being added, both the kernel itself and the initramfs
have gradually increased in size.

Previously, we used squashfs to package and reduce the initramfs size. However,
since squashfs will be replaced by erofs, we have transitioned to erofs. The
compression algorithms supported by erofs differ from those used in squashfs.
In previous squashfs implementations, we used zstd compression, but in RHEL-10,
the erofs implementation in the kernel does not yet support zstd decompression.
As a result, we had to switch to other compression algorithms, leading to
changes in the initramfs size.

In some scenarios, the previous 192M crashkernel reservation is no longer
sufficient. Recent NFS testing has shown that at least 238M is required to
successfully capture a vmcore. Given this, we have updated the default
crashkernel reservation to start from 2G, with 256M allocated for crash
recovery.

Since 256M is a significant portion of memory on smaller systems, we have
decided not to reserve crashkernel memory by default on systems with less
than 2G of RAM. However, users can still manually adjust the `crashkernel=`
setting via tools like `grubby` if needed.

Diagnostic Steps

  • Physical memory should be less than 2 GB:
# free -h
               total        used        free      shared  buff/cache   available
Mem:           1.4Gi       401Mi       1.0Gi       4.2Mi       125Mi       1.0Gi
Swap:          3.0Gi          0B       3.0Gi
  • Verify whether crashkernel is already set or not:
# kdumpctl estimate
Reserved crashkernel:    0M
Recommended crashkernel: 176M

Kernel image size:   59M
Kernel modules size: 6M
Initramfs size:      45M
Runtime reservation: 64M
Large modules:
    xfs: 3207168
WARNING: Current crashkernel size is lower than recommended size 176M.
  • Set the crashkernel parameter using kdumpctl reset-crashkernel command and reboot the machine to take the effect:
# kdumpctl reset-crashkernel
kdump: Updated crashkernel=2G-64G:256M,64G-:512M for kernel=/boot/vmlinuz-6.12.0-55.12.1.el10_0.x86_64. Please reboot the system for the change to take effect.

# reboot
  • Verify whether crashkernel has been set in kernel commandline:
# cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-55.12.1.el10_0.x86_64 root=/dev/mapper/rhel_dhcp131--77-root ro resume=UUID=d8469a6f-cf99-4dac-a1c9-a7031815465e rd.lvm.lv=rhel_dhcp131-77/root rd.lvm.lv=rhel_dhcp131-77/swap rhgb quiet crashkernel=2G-64G:256M,64G-:512M
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.