Bug 521524 – kdump; problems

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description Paige Thompson 2014-08-29 18:43:18 UTC]

Created attachment 383926 [details]
can't get kdump to work

indowlicker ~ # cat /proc/cmdline 
BOOT_IMAGE=/kernel-genkernel-x86_64-3.16.1-gentoo root=/dev/mapper/root ro iommu=pt iommu=1 pci-stub.ids=1002:68b8,1002:aa58 crashkernel=2G

windowlicker ~ # cat /etc/local.d/kdump.start 
#!/bin/bash
kexec -p /boot/kernel-genkernel-x86_64-3.16.1-gentoo initrd=/boot/initramfs-genkernel-x86_64-3.16.1-gentoo --append="root=/dev/mapper/root single irqpoll maxcpus=1 reset_devices"
windowlicker ~ # 

Linux windowlicker 3.16.1-gentoo #1 SMP Fri Aug 29 03:37:58 PDT 2014 x86_64 AMD Opteron(tm) Processor 6128 HE AuthenticAMD GNU/Linux

all kdump options enabled afaik, seen several sources

before you ask me why 2G : 

-rw-r--r--  1 root root 108M Aug 29 04:01 initramfs-genkernel-x86_64-3.16.1-gentoo <--- allmodules + debugging symbols.

-rw-r--r--  1 root root 4.6M Aug 29 03:38 kernel-genkernel-x86_64-3.16.1-gentoo

before you ask my why ramdisk :

windowlicker ~ # cryptsetup status root

/dev/mapper/root is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 256 bits
  device:  /dev/sda2
  offset:  4096 sectors
  size:    249085619 sectors
  mode:    read/write
windowlicker ~ # cat /proc/partitions | grep sda
   8        0  125034840 sda
   8        1     489951 sda1
   8        2  124544857 sda2


windowlicker ~ # /etc/local.d/kdump.start 
Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
Then try loading kdump kernel
windowlicker ~ # 

but yet somehow, with crashkernel=64M it ran, except when injecting sysrq it oops'd then never booted the kernel (probably because 64M isn't enough?

windowlicker ~ # kexec --version
kexec-tools 2.0.4 released 29 August 2014
windowlicker ~ # 


I'll keep trying to get it working, just wanted to get some information in here since theres not very much, I've had to take from several sources. I attached a screenshot of what it does with crashkernel=64M. It does *start* to work if I use 64M, load it and then reboot but that doesn't really do me much good. Oddly enough, it doesn't check to see if 64M is enough for both the kernel and initramfs, but it seems to be completely ignoring the 2G option as if that were unreasonable (or maybe I'm just really frustrated and reading too much into the behavior I'm seeing.)

I Really need to get this working correctly, please let me know what's necesarry I need to isolate this spontaneous reboot issue on my hypervisor (probably a hardware error, could be ~amd64 kernel could be qemu-9999...don't know this is supposed to help me figure that out.)

references: : https://www.kernel.org/doc/Documentation/kdump/kdump.txt

[Comment 1 Paige Thompson 2014-08-29 18:58:15 UTC]

tried this with no luck: 

windowlicker ~ # cat /etc/local.d/kdump.start 
#!/bin/bash
kexec -p /boot/kernel-genkernel-x86_64-3.16.1-gentoo initrd=/boot/initramfs-genkernel-x86_64-3.16.1-gentoo --append="root=/dev/mapper/root single irqpoll maxcpus=1 reset_devices"
windowlicker ~ # cat /proc/cmdline 
BOOT_IMAGE=/kernel-genkernel-x86_64-3.16.1-gentoo root=/dev/mapper/root ro iommu=pt iommu=1 pci-stub.ids=1002:68b8,1002:aa58 crashkernel=2G@0
windowlicker ~ # 


I also tried 2048M earlier no luck with that either, I guess I can try crashkernel=999M and see what it does

[Comment 2 Paige Thompson 2014-08-29 19:29:15 UTC]

512M max. also I read the doc a little more... makes a bit more sense

alright so 512M .... 
loaded, checked for loaded, triggered sysrq... /dev/mapper/root vfs panic no busybox shell I'm vaguely familiar with this issue..... not really... it usually says it can't find /dev/mapper/root and drops to busy box shell :P 

scren cap http://i.imgur.com/GE08a3K.png

I really want to believe... 

- I need a different kernel / initramfs because this one is too big. I mean sure it can fit 100M compressed ramdisk into 512M but where does it uncompress to? Maybe I'm wrong about that? I mean with 64M it still tried, no error and didn't even boot the kernel probably because it couldn't fit enough I really dont know I guess I'll have to look at the code... when I have time right now I am behind on actual real non "exploratory" work and its really late... 

- I really shouldn't be concerned with this since I have 64GB of RAM to play with

will check back later

notes: 
The syntax is:

    crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
    range=start-[end]

    'start' is inclusive and 'end' is exclusive.

For example:

    crashkernel=512M-2G:64M,2G-:128M

This would mean:

    1) if the RAM is smaller than 512M, then don't reserve anything
       (this is the "rescue" case)
    2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
    3) if the RAM size is larger than 2G, then reserve 128M

[Comment 3 Paige Thompson 2014-08-29 22:15:31 UTC]

I think probably the thing to do would be to try to build another kernel/initramfs for the recovery just so I know for sure its the right size and all. 

- I'll look into how genkernel / grub and initramfs work more closely, to find out what parameters are needed (if not the kernel command line parameters) to get it to drop to a busybox shell

- I'll see if theres any of this that the genkernel maintainer(s) might be interested in 

- I'll see if I can contact the editors of this Gentoo Wiki page since the information is a bit misleading. 

-Arch has a nice init / systemd wrapper it looks like, maybe that would be useful in the form of a package. I think along with a genkernel that produces a tiny kernel/initramfs in addition to one that produces a kernel / initramfs with debugging info and necesarry options enabled the two could be kinda complimentary. 

- Honestly I've wondered in the past how I can just get gentoo to drop to a busybox shell by default without giving it a root= parameter... more interesting stuff to investigate.