How to recover the failed disk in the condition with TECH140473

  • Article ID:100004872
  • Modified Date:
  • Product(s):


"vxdisk -g dg_name resize disk_name" failed then vxconfigd daemon died. No core dump left.

Error Message

1. According to the technote: TECH140473, the error message is as follows.

# vxdisk -g testdg resize sda  
VxVM vxdisk ERROR V-5-1-8643 Device sda: resize failed: Unsupported partition layout  

2. However, sometimes there is no error messages left because vxconfigd died without core since VxVM5.0MP4(1797540: The vxdisk resize no longer intermittently causes vxconfigd to dump core)


Etrack: 2156649
TN: TECH140473



1. Confirm the disk actually can handle more than 2TB.
For Linux to do this, it will be required to need a GPT label on the disk. So, to check do the following:
#parted /dev/sdb
(parted) print
- After the output is seen, just type in quit to exit parted
- Then something should be seen like this:
          (parted) print
          Disk geometry for /dev/hda: 0.000-2445.679 megabytes
          Disk label type : msdos
          Minor    Start       End     Type      Filesystem Flags
          1          0.031    945.000 primary   fat32       boot, lba
          2        945.000   2358.562 primary   ext2
          3       2358.562   2445.187 primary   linux-swap
          (parted) print 1
          Minor: 1
          Flags: boot, lba
          File System: fat32
          Size:            945.000Mb (0%)
          Minimum size:     84.361Mb (0%)
          Maximum size:   2445.679Mb (100%)
Note: Please note above that the label type is “ msdos ” (and will NOT support) big disks
If there is a GPT label on the disk, all should be fine for the disk over 2TB.
If there is NOT a GPT label on the disk,    it is required to re-label the disk , which means that ALL data on the disk will be lost !!!
2. If there is no GPT label on the disk,  it may be needed to look for what can be salvaged from the disk.
- See what the partitions are and search for the partition with the type “f” (indicating a private region).
- If it is missing (because the resize actually calls parted and gave the size invalid, parted failed and messed up the disk),
- Then redo the partitions from the CBR (if this is not the only disk in a DG, just doing an init again might help and then followed by a “adddisk –k” ).
- In inference, if only the partition table is stuffed on this disk and that once  doing “fix” it is done, then the data will be accessible again.
3. So therefore, please CHECK if the resized LUNs are re-labeled or not after size increase.
1. Please save the configuration data of disks.
#vxdisk list sdb
2. Place the disks offline with the command vxdisk offline <disk>
#vxdisk offline sdb
3. Use the command blockdev --rereadpt /dev/vx/dmp/<disk>
#lockdev --rereadpt /dev/vx/dmp/sdb
4. Place the disks online with vxdisk online <disk>
#vxdisk online sdb
5. Rescan the disk with vxdisk scandisk
#vxdisk scandisks
6. Check to see if the configuration data gets wrong due to some reason by comparing with the previous configuration data in the step #1.
# vxdisk list sdb
Now the disk will be shown as online and as normal.
On the other hand, in case there is anything wrong even after step 6 above,
1.  please initialize the disk with the configuration data from the step above
#/usr/lib/vxvm/bin/vxdisksetup -i sdb format=sliced privoffset=16065 privlen=15808 puboffset=32130 publen=9367308720
2. Then try to add disk to disk group by force
#vxdg -g PDDG -k adddisk sdb
3. Thereafter, please start volume
#vxvol -g PDDG -f start PD-volume
4. Then mount the file system
# mount -t vxfs /dev/vx/dsk/datadg/datavol /data

Applies To

[ The version of OS/Package ]
- Linux symc-linux #1 SMP Fri May 28 12:10:21 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

- VRTSvxvm-common-

Was this content helpful?

Get Support