Description of problem:
kdump failed with cciss device when I sepcify the device by
device file name within /etc/kdump.conf.
Specify the device with uuid or label doesn't reproduce the failure.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Specify dump device as "ext3 /dev/cciss/c0d0p1" within kdump.conf
2. Configure kdump.
3. Crash the system.
kdump failed to mount the partition.
mount: Mounting /dev/cciss/c0d0p1 on /mnt failed: No such file or directory
umount: Couldn't umount /mnt: Invalid argument
kdump succesfully mount the device and copy /proc/vmcore into the partition.
I suspect mkdumprd failed to handle cciss device's naming rule,
when it create init script within initrd-kdump.img.
mkdumprd command creates initrd-kdump.img for kdump(diskdump).
The "init" is the core of the kdump.
During the block device creation section, the script search /sys/block.
If the HP Proliant system with cciss device, the output would be ...
# for i in `ls /sys/block` ; do echo $i ; done
In case of IDE disk, $i = hda.
In case of cciss disk, $i = cciss!c0d0
And then, the script create device files.
mknod /dev/$i$PART_NUM b $MAJOR_NUM $j
In case of IDE disk, $i$PART starts from /dev/hda1.
In case of cciss disk, $i$PART starts from /dev/cciss!c0d01.
This device file name doesn't follow the naming rule of cciss device.
As I specify "ext3 /dev/cciss/c0d0p1" within /etc/kdump.conf,
mkdumprd pickup the "/dev/cciss/c0d0p1" as DUMPDEV in init.
mount -t ext3 $DUMPDEV /mnt
The actual command would be "mount -t ext3 /dev/cciss/c0d0p1 /mnt".
But the init script has created /dev/cciss!c0d01.
This is why the mount command returns "no such file or directory".
I suspect this is the reason why the init script failed to mount
partition on a cciss device, if I specify the device as device
file name, but succeeded with label or uuid.
I hope you look into this symptom, and fix the mkdumprd ASAP.
Created attachment 153602 [details]
The init file created on HP Proliant with cciss
Please test out the patch in bz 228685. If it gives you appropriate results,
I'll check it in.
*** This bug has been marked as a duplicate of 228685 ***
Test in my lab confirm the patch in bz 228685 fixed the problem.
Thanks for support.