If the free -m command on an AlmaLinux server shows less memory than is included in the VPS plan, one possible cause could be a **kdump**. In the event of a kernel crash, kdump saves the contents of memory so that the cause of the error can be investigated afterwards. To do this, at system start-up, a memory area (crashkernel) is reserved for a second, so-called rescue kernel; the system does not use this area for anything else.

This is noticeable on a small VPS: on a 2 GB machine, the default allocation is 256 MB, which is one-eighth of the memory. On most servers hosting websites, nobody ever analyses the kdump backups, so this memory is better spent on applications.

We tested these steps in October 2026 on AlmaLinux 9.8 and 10.2, using a virtual machine with 2 GB of RAM.

Is there a reservation on the server?

grep -o 'crashkernel=[^ ]*' /proc/cmdline
echo $(( $(cat /sys/kernel/kexec_crash_size) / 1048576 )) MB
systemctl is-enabled kdump

• If the first command does not display anything and the second shows 0 MB, there is no memory usage and no action is required. This was the case on machines installed using the AlmaLinux 9 and 10 cloud images during testing: kdump was disabled and there was no crashkernel parameter. However, on systems installed from the installer (ISO), it is enabled by default.
• The actual allocation is also shown in the kernel boot log: sudo dmesg | grep -i crashkernel, for example, crashkernel reserved: 0x00000000a5400000 - 0x00000000b5400000 (256 MB).

The default value depends on the amount of memory. The factory setting is displayed by the command sudo kdumpctl get-default-crashkernel; in our test on AlmaLinux 9 aarch64, the values were 1G-4G:256M,4G-64G:320M,64G-:576M, i.e. 256 MB for 1–4 GB of memory. On x86_64 systems, the values are lower (according to Red Hat’s documentation, 192 MB for 1–4 GB).

Option 1: smaller reservation, the kdump remains

If you want to keep the kdump but would prefer to use less memory:

sudo grubby --update-kernel=ALL --args="crashkernel=1G-4G:128M,4G-64G:192M,64G-:256M"
sudo reboot

In the test, on the 2 GB machine, this allocation decreased from 256 MB to 128 MB, the total memory as shown by free -m increased from 1699 MB to 1827 MB, and the kdump service remained active. If the allocation is too small, kdump cannot start (systemctl status kdump returns an error); in this case, increase the value.

The default value can be restored using the command sudo kdumpctl reset-crashkernel --kernel=ALL (effective after a reboot).

Option 2: Disabling kdump

If you do not need the kdump, disable it and cancel the reservation:

sudo systemctl disable --now kdump
sudo grubby --update-kernel=ALL --remove-args="crashkernel"
sudo reboot

After the test, the allocated memory was 0 MB, whilst the total memory according to the free -m command was 1955 MB – that is, 256 MB more than the allocated 256 MB.

Two comments on some of the older guides that are frequently read:

• crashkernel=no is not a valid value. During testing, it did terminate the reservation, but only because the kernel did not recognise it: upon start-up, it logged the following: crashkernel: memory value expected. Remove this parameter using the --remove-args switch.
• There is no need to run grub2-mkconfig: grubby modifies the boot entries directly. To check: sudo grubby --info=DEFAULT | grep args.

AlmaLinux 10

The steps are the same. On AlmaLinux 10, the kdumpctl command and the kdump service are included in the kdump-utils package; if this is not installed (it was not on the test cloud image), kdump will not run in the first place, and there is nothing to disable.

When is it worth keeping it?

If your server mysteriously restarts or freezes without warning, and you wish to investigate the cause of the fault with the support of Red Hat, AlmaLinux or a software vendor, the saved kdump (in /var/crash) is the most important clue. In such cases, keep it, at least until the fault has been investigated. If you are consistently running low on memory, rather than reducing your memory allocation, you should also consider upgrading your VPS plan; the article ‘Out of memory: OOM killer and swap file’ discusses the symptoms of memory shortages.