Description of problem: The kdump initrd does not contain multipath for a boot from SAN configured system. This makes it so the crash cannot be written out to the /dev/mapper/mpath#p# device. Version-Release number of selected component (if applicable): RHEL 5.2 snap 4 Kernel 2.6.18-88.el kexec-tools-1.102pre-16.el5 How reproducible: Every time. Steps to Reproduce: 1.Perform a RHEL 5.2-snap4 installation using mpath on the install boot line. 2.Configure kdump to use a multipath device, i.e. /dev/mapper/mpath0p5. 3.Cause a crash via 'echo "c" > /proc/sysrq_trigger' Actual results: kdump will be unable to write out the dump as the device does not exist. Expected results: The dump gets written out to the multipath device. Additional info: Tested using Emulex FC HBA connected to an HP EVA 4000.
Sorry, multipath is something that we're not able to currently do in kdump. Getting multipath to work consistently in most situations (especially those where the path callout is a userspace program), is just to fragile at the moement. I've decided that multipath isn't an option for the time being. I recommend that you target network based dump target instead (nfs or scp).
Created attachment 390413 [details] Experimental patch adding multipath support to mkdumprd This might work for some multipath configurations, use at your own risk!
Multipath is not necessary for kdump to work to SAN disk. See the section "Dumping to a SAN Device" https://access.redhat.com/knowledge/solutions/6038