Using Kexec and Kdump in Rawhide

From FedoraNEWS.ORG

Written by Jeff Moyer on 2005-10-21

The kexec-tools package was recently added to rawhide. This package allows the user to reboot his system without first passing through the BIOS. In other words, the running kernel acts as the boot loader, and directly jumps to the next kernel. This is especially useful for machines which take a long time to reboot, perhaps due to a large number of expansion cards, or due to an extraordinarily long POST (Power On Self Test) process. Kexec also paves the way for other projects, such as kboot (http://kboot.sourceforge.net), a kexec-based boot loader, or kdump, discussed next.

Kdump allows for the capture of a kernel crash dump upon panic. This crash dump can then be passed on to kernel developers to help in analyzing the cause of the panic. To facilitate this functionality, the kdump patches were added to the kexec-tools package. This article focuses on how to use both kexec and kdump in rawhide.

The discussion starts with kexec. The primary tool for loading a new kernel is, not surprisingly, 'kexec'. This tool supports a plethora of options, only some of which will be discussed here. The first step in using kexec is ensuring that the kernel has support for the kexec system calls. In rawhide, this support is built-in by default. The kernel which you boot does not require kexec support.

In a relatively vanilla Fedora install, a kexec command line to load the kernel may look something like this:

kexec -l -t bzImage --command-line="ro root=LABEL=/" \
        --initrd="/boot/initrd-2.6.13-1.1621_FC5.img" /boot/vmlinuz-2.6.13-1.1621_FC5.img

Examining each of these options, we see that -l specifies that we want to load a kernel. --command-line and --initrd are obvious. And we end with the kernel image we wish to boot. Now, if we wish to execute this kernel (reboot), we can simply issue the following command:

kexec -e

Note that if you make a mistake, and wish to load a different kernel, you can simple issue a kexec -u, or, just re-run kexec -l, as that will take care of first unloading the old kernel, and then inserting the new one.

Once you have successfully booted a kernel via kexec, I would strongly encourage you to check out kboot.

Moving on to kdump, the process is even simpler. First, install the kernel-kdump package. The init script provided with the kexec-tools package in rawhide automates the kexec process, and the capturing of the crash dump. You must add the kernel command line option "crashkernel=XM@16M" to the "normal" kernel's boot parameter list. Replace the "X" with the number of megabytes you would like to reserve for the crash kernel. In testing, I've used 48 and 64 with success. So, chkconfig kdump on, reboot your system, and kdump is ready to go.

You can test that kdump is working by invoking a crash via the magic sysrq key. First, enable sysrq by issuing the following command as root:

sysctl -w kernel/sysrq=1

Then, you can invoke a crash with the following command:

echo c > /proc/sysrq-trigger

When the system panics, kexec is invoked to execute the "panic kernel." During bootup, the kdump init script will be called. It detects the presence of a /proc/vmcore file, creates a directory in /var/crash to store the crashdump, copies the crashdump, and reboots the system through the BIOS.

On the subsequent boot, you will find a file named vmcore in the /var/crash/<date-time> directory. If you wish to examine the crashdump, the venerable crash utility is a must. You can yum install crash.

Crash requires a kernel binary built with debugging symbols. The debuginfo packages contain such information. So, you will want to install the kernel-debuginfo package for the kernel you are debugging. In that package, you should find a vmlinux file. Then, you may invoke crash as crash vmlinux vmcore and you are ready to start debugging.

In future installments, we'll take a look at the functionality provided by crash. For now, this should be enough fun stuff to play with!