[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Difficulty configuring kdump


After you reboot and configure your kdump, before you do the test crash dump, check if your crash kernel was loaded corretly with grep -i crash /proc/iomem

2013/7/29 Andrew Walsh <awalsh@permabit.com>

Hi all,


I’ve got an issue trying to configure kdump on my debian systems, and I was hoping someone could help shine some light on the issue for me that might help me get it working.  I’ve done some extensive reading about how to configure it, but nothing has been fruitful in pointing me in the right direction.  The systems I am trying to get this working on are running debian squeeze with the 64-bit 3.2 backported kernel via squeeze-backports.


Here's the scenario:

I configure kdump /etc/default/kdump-tools as I would like (I've varied the location of /var/crash around in the event that partitioning or location had anything to do with it, with no success):

  KDUMP_CMDLINE_APPEND="irqpoll maxcpus=1"

And then update the grub config

  For grub1 (for xen-hosts): Append crashkernel=64M@192M to kernel line on default boot
  For grub2: edit /etc/default/grub and append "crashkernel=64M to GRUB_CMDLINE_LINUX_DEFAULT
    (I’ve noticed that if I keep quiet in there, kdump-tools fails to load as well)

  run update-grub
  (If there is a double space before crashkernel in the resulting grub.cfg or menu.lst, I noticed that I have to remove it manually)

On one of the systems (the same one showing the output of kdump-config), here is the resulting kernel param in my grub.cfg:
  linux   /boot/vmlinuz-3.2.0-0.bpo.3-amd64 root=UUID=8135cc05-9b88-4aa1-be74-9c4d687bf956 ro crashkernel=64M


I then reboot the host and run kdump-config status, which returns "Ready to kdump":

# kdump-config status
current state   : ready to kdump

This is the output of kdump-config show:

# kdump-config show
USE_KDUMP:        1
KDUMP_SYSCTL:     kernel.panic_on_oops=1
KDUMP_COREDIR:    /var/crash
crashkernel addr: 0x3300000
current state:    ready to kdump

kernel link:

kexec command:
  /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-3.2.0-0.bpo.3-amd64 root=UUID=8135cc05-9b88-4aa1-be74-9c4d687bf956 ro  irqpoll maxcpus=1" --initrd=/boot/initrd.img-3.2.0-0.bpo.3-amd64 /boot/vmlinuz-3.2.0-0.bpo.3-amd64

Ensure that I have the sysrq trigger set up correctly by setting it to 1:

echo 1 > /proc/sys/kernel/sysrq

(This is usually already set to 1, but I still do it to make sure)

Then I simulate a crash:

echo c > /proc/sysrq-trigger

On a Squeeze host, the panic occurs, but nothing else. I have to manually reset the machine to bring it back.
On a RHEL6 host (slightly varied configuration), the kernel dumps the core as expected and reboots.

One thing to also note is that when I have this config in place, sending a reboot operation to the system responds as expected, where it doesn’t fully reboot the machine, it just simply reloads the running kernel, so it does appear that things are half-working.

I have tried this configuration on several machines, and they all react the same way. I've reached out to the package maintainer for the best place to ask this question for kdump-tools, but I haven't gotten a reply, so this was my best guess.


I would greatly appreciate any help or insight into where I might find some assistance with this issue.


Andrew Walsh

esta es mi vida e me la vivo hasta que dios quiera

Reply to: