Bug 683735

Summary:	Makedumpfile fails to recover the raw dump file
Product:	Red Hat Enterprise Linux 6	Reporter:	Cong Wang <amwang>
Component:	kexec-tools	Assignee:	Cong Wang <amwang>
Status:	CLOSED ERRATA	QA Contact:	Chao Ye <cye>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	6.0	CC:	cye, nhorman, phan, rkhan
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	kexec-tools-2_0_0-168_el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-19 14:16:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Cong Wang 2011-03-10 08:45:00 UTC

Description of problem:
When we do kdump over a raw block device, the vmcore is supposed to be recovered automatically during the next we start kdump service, at least for the default configuration. But the recovery fails due to that we don't specify a core collector which will be 'dd' by default and recover it with 'makedumpfile'.

How reproducible:
Always

Steps to Reproduce:
1. *Only* put raw XXX in kdump.conf
2. restart kdump service
3. trigger a crash and watch the dump and then reboot
  
Actual results:
vmcore is not recovered successfully.

Expected results:
vmcore should be recovered successfully.

Additional info:
We should use 'makedumpfile' as the default core collector for raw dump too, instead of dd, otherwise users will get confused. And we should emit a warning for user when they specify their own core collector which is not makedumpfile.

Comment 2 Chao Ye 2011-03-18 09:50:46 UTC

Tested with latest build:
=====================================================
[root@ibm-js22-07 ~]# service kdump status
Kdump is operational
[root@ibm-js22-07 ~]# rpm -q kernel kexec-tools
kernel-2.6.32-122.el6.ppc64
kexec-tools-2.0.0-171.el6.ppc64
[root@ibm-js22-07 ~]# tail /etc/kdump.conf 
#kdump_post /var/crash/scripts/kdump-post.sh
#extra_bins /usr/bin/lftp
#disk_timeout 30
#extra_modules gfs2
#options modulename options
#default shell

raw /dev/sda3
core_collector makedumpfile -c --message-level 1 -d 31
default shell
[root@ibm-js22-07 ~]# touch /etc/kdump.conf 
[root@ibm-js22-07 ~]# service kdump restart
Stopping kdump:[  OK  ]
Detected change(s) the following file(s):
  
  /etc/kdump.conf
Rebuilding /boot/initrd-2.6.32-122.el6.ppc64kdump.img
Starting kdump:[  OK  ]
[root@ibm-js22-07 ~]# echo c > /proc/sysrq-trigger
--------------------------------------------------------------------------------------
mdadm: No arrays found in config file or automatically
Free memory/Total memory (free %): 150208 / 231296 ( 64.9419 )
Scanning logical volumes
  Reading all physical volumes.  This may take a while...
  Found volume group "vg_ibmjs2207" using metadata type lvm2
Activating logical volumes
  2 logical volume(s) in volume group "vg_ibmjs2207" now active
Free memory/Total memory (free %): 149312 / 231296 ( 64.5545 )
Saving to partition /dev/sda3
Free memory/Total memory (free %): 149312 / 231296 ( 64.5545 )
Copying data                       : [100 %] 
Saving core complete
Restarting system.
......

Starting RPC idmapd: [  OK  ]
Dump saved to /var/crash/2011-03-18-05:46/vmcore
Starting kdump:[  OK  ]
......


Change status to VERIFIED.

Comment 3 errata-xmlrpc 2011-05-19 14:16:10 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0736.html