Summary

On systems with low RAM (for example 1 GB), the automatic kdump configuration may reserve memory for crashkernel that your system simply does not have. This often results in messages such as:

crashkernel=2G-64G:256M,64G-:512M

This tutorial explains why this appears, what it means, and how to safely disable or adjust kdump on low-memory servers.


What is kdump and crashkernel?

Kdump is the Linux crash dump feature. When the kernel crashes, a special small “second kernel” boots and saves diagnostic information.

To do this, the system must reserve RAM during startup using a kernel boot parameter called crashkernel.

For example:

  • crashkernel=256M means 256MB is reserved at boot
  • This memory is not available to normal applications

Why it becomes a problem on 1 GB RAM

Many Linux distributions set a range-based crashkernel parameter:

2G-64G:256M,64G-:512M

Meaning:

  • If RAM is between 2GB and 64GB, reserve 256MB
  • If RAM is above 64GB, reserve 512MB

On a 1 GB server, this does NOT match any rule. So kdump either does nothing or tries to reserve memory that reduces usable RAM. In most 1 GB cases, kdump becomes impractical and should be disabled.


Should I disable kdump if I have 1GB RAM?

Usually yes.

Reasons:

  • You lose a lot of precious RAM
  • The machine may become slow or unstable
  • You rarely need kernel debugging on low-resources systems

Option A (Recommended): Disable kdump completely

Stop the service

sudo systemctl stop kdump

Disable it at boot

sudo systemctl disable kdump

Check status

sudo systemctl status kdump

Option B: Prevent automatic crashkernel change

Edit:

sudo nano /etc/kdump.conf

Add this line:

auto_reset_crashkernel=no

Save and exit.
Then reboot.

After reboot:

cat /proc/cmdline

You should not see unwanted crashkernel entries anymore.


Option C (not recommended): Set a manual very small crashkernel

If you absolutely need crash dumps, set a tiny value such as:

crashkernel=128M

Edit:

sudo nano /etc/default/grub

Find the line:

GRUB_CMDLINE_LINUX="..."

Add inside:

crashkernel=128M

Save, then regenerate grub (varies by distro):

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Reboot, check:

cat /proc/cmdline

Warning: Your system may lose usable RAM or become unstable.


How to confirm kdump state

After reboot:

sudo systemctl status kdump

Check kernel command line:

cat /proc/cmdline

Check configuration:

cat /etc/kdump.conf

Troubleshooting

• Still seeing messages?
Reboot after changes.

• System slowed down?
Disable crashkernel or disable kdump completely.

• Unsure where grub lives?
UEFI systems usually use /boot/efi paths, traditional systems use /boot/grub2.


Frequently Asked Questions

Is disabling kdump safe?
Yes, especially on low-memory systems that do not need debugging information.

Will disabling improve performance?
It frees RAM, which is critical on 1GB systems.

Should I enable kdump on larger servers?
Yes, if you need kernel crash analysis and you have 2GB+ RAM.


Final Notes

On small servers (1GB RAM), kdump usually causes more problems than benefits. The safest approach is to disable it or prevent automatic crashkernel settings. On bigger servers, kdump is useful for diagnosing kernel crashes.

Last Update: December 6, 2025

Tagged in:

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,