Corruption in the /etc/vx/disk.info file after installing Solaris patches and rebooting system

Article:TECH44060  |  Created: 2005-01-30  |  Updated: 2009-01-04  |  Article URL http://www.symantec.com/docs/TECH44060
Article Type
Technical Solution


Environment

Issue



Corruption in the /etc/vx/disk.info file after installing Solaris patches and rebooting system

Solution



The persistent device naming feature, introduced in VERITAS Volume Manager 4.1, makes the names of disk devices persistent across system reboots. If operating system-based naming is selected, each disk name is usually set to the name of one of the paths to the disk.

This feature relies on the accuracy and persistency of device mapping information stored in the /etc/vx/disk.info file.

On systems running Volume Manager 4.1, after installing Solaris patches and rebooting the server, it has occasionally been noticed that the /etc/vx/disk.info file gets corrupted.

This affects the persistent device naming feature and is visible to the user in that the DEVICE-to-DISK name mapping as seen in the vxdisk list output appears to be in a scrambled state .

Example of device mapping when the system is in a good state:

# vxdisk -e list

DEVICE       TYPE      DISK          GROUP        STATUS       OS_NATIVE_NAME
c2t1d5s2     auto      d5            alexdg       online       c2t1d5s2
c2t1d6s2     auto      d6            alexdg       online       c2t1d6s2
c2t1d7s2     auto      d7            alexdg       online       c2t1d7s2
c2t1d8s2     auto      d8            alexdg       online       c2t1d8s2
........

After installing a Solaris patch and rebooting, the /etc/vx/disk.info file has been corrupted. Here's what device mapping appears like after the reboot:

# vxdisk -e list

DEVICE       TYPE      DISK          GROUP        STATUS       OS_NATIVE_NAME
c2t1d5s2     auto      d5            alexdg       online       c2t1d5s2
c2t1d6s2     auto      d11           alexdg       online       c2t1d11s2
c2t1d7s2     auto      d13           alexdg       online       c2t1d13s2
c2t1d8s2     auto      d7            alexdg       online       c2t1d7s2
.......


Symantec has identified the root cause of the issue and it is being tracked via Etrack Incident 423812.

The issue can occur under the following sequence of events:

1. A Solaris patch that affects a library file on which the Volume Manager 4.1 configuration daemon "vxconfigd" depends has recently been installed on the system.

To determine on which libraries the vxconfigd binary depends:
 
# ldd /sbin/vxconfigd
       libsocket.so.1 =>        /usr/lib/libsocket.so.1
       libnsl.so.1 =>   /usr/lib/libnsl.so.1
       libintl.so.1 =>  /usr/lib/libintl.so.1
       libvxdiscovery.so =>     /etc/vx/slib/libvxdiscovery.so
       libdevinfo.so.1 =>       /usr/lib/libdevinfo.so.1
       libthread.so.1 =>        /usr/lib/lwp/libthread.so.1
       libc.so.1 =>     /usr/lib/libc.so.1
       libdl.so.1 =>    /etc/lib/libdl.so.1
       libvxscsi.so =>  /usr/lib/libvxscsi.so
       libkstat.so.1 =>         /usr/lib/libkstat.so.1
       libmp.so.2 =>    /usr/lib/libmp.so.2
       liba5k.so.2 =>   /etc/vx/slib/liba5k.so.2
       libg_fc.so.2 =>  /etc/vx/slib/libg_fc.so.2
       libdevice.so.1 =>        /etc/vx/slib/libdevice.so.1
       libnvpair.so.1 =>        /usr/lib/libnvpair.so.1
       /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1

2. After installing the patch, the system is either rebooted by the system administrator or is affected by a system panic and consequent reboot.

If the above sequence occurs, then,  when the system boots up again, Volume Manager 4.1 detects that the libraries in /etc/vx/slib  are not in sync with their counterparts in /usr/lib, copies over the modified libraries,  and restarts vxconfigd during the boot phase.

This sequence can cause Volume Manager 4.1 to hit Etrack Incident 423812 and the /etc/vx/disk.info file may then be corrupted.

This is a cosmetic issue in that it only affects the device mapping portrayed in the vxdisk list output. The actual system devices, volumes,  and data are not affected and there is no risk of loss of data.

If the system has been affected by Etrack Incident 423812, here are the steps to recover from this situation:

For systems running VERITAS Volume Manager in a non-cluster environment

a. Remove the corrupted /etc/vx/disk.info file:
# rm -f /etc/vx/disk.info

b. Restart vxconfigd:
# /sbin/vxconfigd -k

For systems running VERITAS Volume Manager in a VERITAS Cluster Server environment

a. Freeze all the service groups running on the system that has Volume Manager resources:

    #  hagrp  -freeze  <service_group_name>

b. Remove the corrupted disk.info file:

   #  rm -f  /etc/vx/disk.info

c. Restart vxconfigd:

   #  /sbin/vxconfigd -k

d. Unfreeze the service groups:

   #  hagrp  -unfreeze <service_group_name>

For systems running Cluster Volume Manager

a. Stop the cluster on the local node:

    #  hastop -local

b. Remove the corrupted disk.info file:

   #  rm -f  /etc/vx/disk.info

c. Restart vxconfigd:

   #  /sbin/vxconfigd -k

d. Start the cluster on local node

   #  hastart



This issue is fixed in the latest Maintenance, and Rolling Patches for Storage Foundation 4.1, and 5.0.
Please contact Symantec support to obtain the latest patches.


 


Supplemental Materials

SourceETrack
Value423812
Descriptioncorrupt /etc/vx/disk.info file after installing Solaris patch

Legacy ID



279364


Article URL http://www.symantec.com/docs/TECH44060


Terms of use for this information are found in Legal Notices