Bug 959914 - kdump does not work on Fedora 19
kdump does not work on Fedora 19
Product: Fedora
Classification: Fedora
Component: kexec-tools (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Baoquan He
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-05-06 04:45 EDT by Martin Milata
Modified: 2013-06-13 22:03 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-06-13 22:03:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Serial console output. (1.23 KB, text/plain)
2013-05-06 04:45 EDT, Martin Milata
no flags Details

  None (edit)
Description Martin Milata 2013-05-06 04:45:05 EDT
Created attachment 744028 [details]
Serial console output.

Description of problem: I'm unable to produce a kdump on Fedora 19 installed in KVM.

Version-Release number of selected component (if applicable):

How reproducible: Always.

Steps to Reproduce:
1. Install Fedora 19 (used RC4 Alpha) into virt-manager VM. Default disk layout, without LVM, without encryption, ext4 filesystem.
2. In the VM, install kexec-tools.
3. Append "crashkernel=128M" to GRUB_CMDLINE_LINUX variable in /etc/default/grub, run grub2-mkconfig -o /boot/grub2/grub.cfg.
4. Reboot.
5. Edit /etc/kdump.conf to contain (replace the UUID with UUID of your root partition):

 ext4 UUID=3c1cd5dc-7287-4333-a27f-43ce95aa7650
 path /var/crash

6. Run systemctl restart kdump.
7. Run echo c > /proc/sysrq-trigger.
Actual results: Virtual machine reboots almost immediately, /var/crash is empty on next boot.

Expected results: vmcore saved under /var/crash.

Additional info: Attaching serial console output.
Comment 1 Baoquan He 2013-05-06 05:25:56 EDT

Please add crashkernel_low=64M into your cmdline, and test it again.
If you can upgrade your kernel above 3.9-rc8, this problem should have been resolved.

Comment 2 Martin Milata 2013-05-07 05:48:11 EDT
Baoquan, thank you for your quick reply.

Adding crashkernel_low=64M to the command line does not seem to change anything.
(And if I replace the original crashkernel=128M with it, the line "[   36.842014] Kernel panic - not syncing: Fatal exception" appears after the usual stack trace and the machine gets stuck instead of reboot.)

Also, 3.9.0-301.fc19, isn't it? I tried 3.10.0-0.rc0.git19.1.fc20 but the result seems to be the same:

[    0.000000] do_IRQ: 0.113 No irq handler for vector (irq -1)
[    1.725883] netif_napi_add() called with weight 128 on device eth%d
dracut-pre-pivot[89]: ++ KDUMP_PATH=/var/crash
dracut-pre-pivot[89]: ++ CORE_COLLECTOR=
dracut-pre-pivot[89]: ++ DEFAULT_CORE_COLLECTOR='makedumpfile -c--message-level 1 -d 31'
dracut-pre-pivot[89]: ++ DEFAULT_ACTION='reboot -f'
dracut-pre-pivot[89]: +++ date +%Y.%m.%d-%T
dracut-pre-pivot[89]: ++ DATEDIR=2013.05.07-09:42:16
dracut-pre-pivot[89]: ++ HOST_IP=
dracut-pre-pivot[89]: ++ DUMP_INSTRUCTION=
dracut-pre-pivot[89]: ++ SSH_KEY_LOCATION=/root/.ssh/kdump_id_rsa
dracut-pre-pivot[89]: ++ KDUMP_SCRIPT_DIR=/kdumpscripts
dracut-pre-pivot[89]: ++ DD_BLKSIZE=512
dracut-pre-pivot[89]: ++ FINAL_ACTION='reboot -f'
dracut-pre-pivot[89]: ++ DUMP_RETVAL=0
dracut-pre-pivot[89]: ++ conf_file=/etc/kdump.conf
dracut-pre-pivot[89]: ++ KDUMP_PRE=
dracut-pre-pivot[89]: ++ KDUMP_POST=
dracut-pre-pivot[89]: ++ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/kdumpscripts
[    3.881530] Restarting system.
Comment 3 Martin Milata 2013-05-07 05:50:24 EDT
Instead of "3.9.0-301.fc19, isn't it?" I meant to write "3.9.0-301.fc19 is above 3.9-rc8, isn't it?" ... sorry.
Comment 4 Baoquan He 2013-05-27 23:11:04 EDT
HI Martin,
Sorry, in 3.9.0-301.fc19, the crashkernel_low is not needed any more. Normal crashkernel=Y@X is enough.

For this problem, it may be caused by NEWROOT bug, could you add NEWROOT=/sysroot at the beginning of /lib/dracut/modules/99kdumpbase/kdump.sh?

Sorry for late response.

Comment 5 Martin Milata 2013-05-29 09:04:47 EDT
I can confirm that after editing the file, kdump works correctly.

Update to kexec-tools-2.0.4-2.fc19-x86_64 did not seem to solve the issue.
Comment 6 Baoquan He 2013-05-29 21:30:19 EDT
Yeah, it's a dracut issue, a patch has been posted to upstream. Now Dave still discuss with maintainer. 

Please wait, I will update the info if any progress.

Note You need to log in before you can comment on or make changes to this bug.