Hello 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 <awa...@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): > > USE_KDUMP=1 > KDUMP_COREDIR="/var/crash" > DEBUG_KERNEL=/usr/lib/debug/boot/vmlinux-3.2.0-0.bpo.3-amd64 > 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: > /usr/lib/debug/boot/vmlinux-3.2.0-0.bpo.3-amd64 > > 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. > > Thanks. > > *Andrew Walsh* > -- esta es mi vida e me la vivo hasta que dios quiera
