Error Message

Scanning logical volumes
  Ignoring /dev/vx: No such file or directory.
  Reading all physical volumes.  This may take a while...
  No volume groups found
  No volume groups found
Activating logical volumes
  Ignoring /dev/vx: No such file or directory.
  No volume groups found
  Ignoring /dev/vx: No such file or directory.
  No volume groups found
Free memory/Total memory (free %): 343420 / 500536 ( 68.6104 )
Saving to the local filesystem UUID=7dbf010f-7826-421d-bc1b-add5159f652b
Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
                                [-I inode_buffer_blocks] [-P process_inode_size]
                                [-l|-L bad_blocks_file] [-C fd] [-j
external_journal]
                                [-E extended-options] device

Emergency help:
-p                   Automatic repair (no questions)
-n                   Make no changes to the filesystem
-y                   Assume "yes" to all questions
-c                   Check for bad blocks and add them to the badblock
lRestarting system.
ist
-f    

As part of VxDMP Native support we update the lvm.conf global filters to reject all devices and accept only the VxDMP devices. The kdump ramdisk (initramfs)  is desinged to load regular linux devices and does not include VERITAS modules in the kdump ramdisk, which would be required for it to find VxDMP devices.

When a system Panic occurs and is switched to the Kdump ramdisk and kernel to capture the system core it fails to find a VxDMP device, since VERITAS modules are not loaded.

Workaround 1: The case where kdump is configured on / root file system under VxDMP native support.
 
1. Copy vxvm lvm.conf.
 
# cp /etc/lvm/lvm.conf /etc/lvm/lvm.conf.vxvm
cp: overwrite `/etc/lvm/lvm.conf.vxvm'? y
 
2. Copy original lvm.conf back (lvm.conf prior to enabling VxDMP Native.
 
# cp /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
cp: overwrite `/etc/lvm/lvm.conf'? y
 
3. Remove kdump initrd.
 
# rm -rf /boot/initrd-2.6.32-504.el6.x86_64kdump.img
 
4. Restart kdump this will also rebuild the initramfs.
 
# service kdump restart
Stopping kdump:                                            [  OK  ]
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.32-504.el6.x86_64kdump.img
Starting kdump:                                            [  OK  ]
 
5. Copy VxVM lvm.conf back. This will ensure that after panic and reboot the system comes back up with VxDMP Native device.
 
# cp /etc/lvm/lvm.conf.vxvm /etc/lvm/lvm.conf
cp: overwrite `/etc/lvm/lvm.conf'? y
 

Note:  The next command will panic the system. Only to be done as part of testing and verification of workaround!
 
# echo c > /proc/sysrq-trigger
 
Drawback:
 
The drawback here is you will have to run this every time.
You have to restart kdump, since the kdump initrd will be recreated once the kdump service is restarted.
So you will have to perform these steps each and every time after reboot.

Note: You can configure steps 1-5 in /etc/init.d/rc.local
 
Workaround 2: Configure the kdump device on a seperate disk not to be managed by VxDMP.
 
Add the filter for the dump device in accept section in lvm.conf file
Again we need to make sure that the DUMP device is *not configured* on root device i.e “/”.
If the device is accepted. It will not come under DMP and will continue to be monitored by Linux Native Multipathing.
 
Permanent fix:
 
Veritas is planning an enhancement release for 7.1

VERITAS DMP (VxDMP) Native support was not designed with kdump functionality in mind.

Currently if you enable VxDMP Native support on a boot disk and encounter or manually panic the system to gather a system core dump, it will fail. The kdump utility will fail when attempting to load the kdump initramfs (ramdisk).