As already mentioned above, it's necessary to reserve some memory at bootup for kdump. Because that memory must be reserved very early during the boot process, the configuration is done via a kernel command line parameter called crashkernel. That memory will be used to load a second kernel in that memory that will be executed without rebooting if the first kernel crashes. That kernel also has a special initrd which contains all programs that are necessary to save the dump to network or disk, send the notification email and finally reboot.

You can enable or disable that the crashkernel parameter is written for the default boot kernel with the add_crash_kernel tag and you can specify the value of the crashkernel parameter using the crash_kernel tag.

For the memory reservation there are two things to specify: The amount of reserved memory (such as 64M to reserve 64 MiB of memory from the RAM) and the offset. The syntax is crashkernel=AMOUNT@OFFSET. Luckily the kernel is able to auto-detect the right offset for you nowadays (with the exception of the Xen hypervisor where you have to specify 16M as offset), so you don't have to worry about that too much. You can just specify <crash_kernel>crashkernel=64M</crash_kernel> and the right thing will happen.

For the amount of memory, following values are recommended:

To make things even more complicated, there's a so-called extended command line syntax where you can specify the amount of reserved memory dependent of the System RAM. That is good if you share one AutoYaST profile for multiple installations or when you often remove or install memory on one machine. The syntax is:

BEGIN_RANGE_1-END_RANGE_1:AMOUNT_1,BEGIN_RANGE_2-END_RANGE_2:AMOUNT_2@OFFSET

In that syntax BEGIN_RANGE_1 is the start of the first memory range (for example: 0M) and END_RANGE_1 is the end of the first memory range (and can be empty in case "infinity" should be assumed) and so on. So for example 256M-2G:64M,2G-:128M means to reserve 64 MiB of crashkernel memory when the system has between 256 MiB and 2 GiB RAM and to reserve 128 MiB of crashkernel memory when the system has above 2 GiB RAM.

The following table contains the settings that are necessary for the memory reservation:

<add_crash_kernel config:type="boolean">true</add_crash_kernel>

<crash_kernel>256M:64M</crash_kernel>

It's useful to get notified via email that a machine has crashed and a dump has been saved. That way you can for example setup a dump server in a company and trigger some actions by that email automatically like calling the administrator from home to check if everything runs again.

Because the dump is saved in a special initrd environment, we cannot use a local mail server just to send that notification email. However, it's better to send that email in the initrd just because it's more likely that we have a working network connection here (which we need in the netdump case to save the dump away anyway) compared that the server comes up again and everything is working.

You have to provide at least exactly one address in KDUMP_NOTIFICATION_TO and zero, one or more addresses in KDUMP_NOTIFICATION_CC. Please note that you can only specify the address here, not a real name or some other fancy stuff.

To actually send the email, we need KDUMP_SMTP_SERVER and (if the server needs authentication) KDUMP_SMTP_USER and KDUMP_SMTP_PASSWORD. Please note that TSL or SSL are not supported. That may be added in future.

<KDUMP_NOTIFICATION_TO>bwalle@suse.de</KDUMP_NOTIFICATION_TO>

<KDUMP_NOTIFICATION_CC>spam@suse.de devnull@suse.de</KDUMP_NOTIFICATION_CC>

<KDUMP_SMTP_SERVER>email.suse.de</KDUMP_SMTP_SERVER>

<KDUMP_SMTP_USER>bwalle</KDUMP_SMTP_USER>

<KDUMP_SMTP_PASSWORD>geheim</KDUMP_SMTP_PASSWORD>

As already mentioned, a special kernel is booted to save the dump. If you don't want to use the auto-detection mechanism to find out which kernel is used (see the kdump(5) manual page that describes the algorithm which is used to find the kernel), you can specify the version of a custom kernel in KDUMP_KERNELVER. If you set that to foo, then the kernel located in /boot/vmlinuz-foo or /boot/vmlinux-foo (in that order on platforms that have a vmlinuz file) will be used.

You can even specify the command line which will be used to boot the kdump kernel. Normally the boot command line is used minus some settings that hurt in the kdump case (like the crashkernel parameter itself) plus some settings that are needed in the kdump case (see the manual page kdump(5)). If you just want some additional parameters like a overwritten console setting then use KDUMP_COMMANDLINE_APPEND. If you know what you're doing and you want to specify the whole command line, set KDUMP_COMMANDLINE.

<KDUMP_KERNELVER>2.6.27-default</KDUMP_KERNELVER>

<KDUMP_COMMANDLINE_APPEND>console=ttyS0,57600</KDUMP_COMMANDLINE_APPEND>

<KDUMP_COMMANDLINE_APPEND>root=/dev/sda5 maxcpus=1 irqpoll</KDUMP_COMMANDLINE>