In part 1 of this series, we did a high level overview of what is involved in obtaining a kernel crashdump.
We will continue our discussion in how to setup a system to obtain crashdumps.
2. Setting up the Main Kernel
To prepare the main kernel for crashdumps we need to configure a few things
1. Enable KEXEC in the defconfig via CONFIG_KEXEC=y. This is needed to enable the in-kernel bootloader which will boot the crash kernel.
2. Enable SYSFS in the defconfig via CONFIG_SYSFS=y
3. Enable the debug information via CONFIG_DEBUG_INFO=y, this is needed to populate the symbol table in the generated vmlinux file.
3. Setting up the Crash Kernel
4. Enable CONFIG_CRASH_DUMP via CONFIG_CRASH_DUMP=y
5. Enable VMCORE via CONFIG_PROC_VMCORE=y this will expose the interface for collecting the crashdump in /proc/
6. Enable the kernel to be relocatable via CONFIG_RELOCATABLE=y (x86) or AUTO_ZRELADDR=y (ARM)
============= x86_64 and i386 only =============
7. Disable SMP via CONFIG_SMP=n (i386 and x86_64 only)
8. Enable high memory support CONFIG_HIGHMEM4G=y or CONFIG_HIGHMEM64G=y
Communicate to the main kernel that it needs to reserve memory for the crash kernel at boot, via the cmd line argument:
This will tell the main kernel to reserve 128MB of noncontiguous RAM for the crash kernel. A whole slew of options is available to tell the kernel where this memory should be placed, please see the kdump docs
Please note, this is not just for the kernel to be placed. This RAM will be used to boot the entire userspace for the crash kernel as well.
To elaborate, when the crash kernel comes up, it run the init process from the provided rootfs, the init in this case could be systemd which may consume significant resources. It is important to be mindful of this as the memory requirements for the crashkernel will vary significantly between an embedded target or server.
- Debugging the Linux Kernel via Crashdumps Part 1
- Setting up Duply with Amazon S3