cancel
Showing results for 
Search instead for 
Did you mean: 

"vxprivutil" not able to read configuration data from disk

timus
Level 4

OS name :  HP-UX B.11.31 U ia64

VxVM version : VRTSvxvm              5.0.31.1       Veritas Volume Manager by Symantec

 

Below is the scneario -

# vxdg list vgebt2db02
Group:     vgebt2db02
dgid:      1291366621.1290.edcdqh0
import-id: 1024.1296
flags:     cds
version:   140
alignment: 8192 (bytes)
local-activation: read-write
ssb:            on
detach-policy: global
dg-fail-policy: dgdisable
copies:    nconfig=default nlog=default
config:    seqno=0.1238 permlen=24072 free=24036 templen=17 loglen=3648
config disk c18t1d4 copy 1 len=24072 state=clean online
config disk c18t1d5 copy 1 len=24072 state=clean online
config disk c18t1d6 copy 1 len=24072 disabled
config disk c21t11d2 copy 1 len=24072 state=clean online
config disk c21t12d2 copy 1 len=24072 disabled
config disk c22t0d0 copy 1 len=24072 state=clean online
config disk c22t0d1 copy 1 len=24072 state=clean online

As seen above the clean copy of DG configration is present on c18t1d4, c18t1d5, c21t11d2, c22t0d0  and c22t0d1

when I try to read the configuration from the above disks using "/etc/vx/diag.d/vxprivutil" , it gives no o/p with exit code 126

# root> /etc/vx/diag.d/vxprivutil scan /dev/vx/rdmp/c21t11d2;echo $?
126

o/p of vxdisk list is  -

#root> vxdisk list c21t11d2
Device:    c21t11d2
devicetag: c21t11d2
type:      auto
hostid:    edcdqh0
disk:      name=vgebt2db0202 id=1291366372.1230.edcdqh0
timeout:   30
pftostate: enabled
group:     name=vgebt2db02 id=1291366621.1290.edcdqh0
info:      format=cdsdisk,privoffset=128
flags:     online ready private autoconfig noautoimport imported
pubpaths:  block=/dev/vx/dmp/c21t11d2 char=/dev/vx/rdmp/c21t11d2
guid:      {b652ab7e-1dd1-11b2-85d4-0015605ed921}
udid:      EMC%5FSYMMETRIX%5F102487%5F60060480000190102487533031363346
site:      -
version:   3.1
iosize:    min=512 (bytes) max=256 (blocks)
public:    slice=0 offset=32896 len=17642624 disk_offset=0
private:   slice=0 offset=128 len=32768 disk_offset=0
update:    time=1291368880 seqno=0.11
ssb:       actual_seqno=0.0
headers:   0 120
configs:   count=1 len=24072
logs:      count=1 len=3648
Defined regions:
 config   priv 000024-000119[000096]: copy=01 offset=000000 enabled
 config   priv 000128-024103[023976]: copy=01 offset=000096 enabled
 log      priv 024104-027751[003648]: copy=01 offset=000000 enabled
 lockrgn  priv 027752-027823[000072]: part=00 offset=000000
Multipathing information:
numpaths:   2
c21t11d2        state=enabled
c25t11d2        state=enabled

 

Can anyone suggest what is wrong here ??

1 ACCEPTED SOLUTION

Accepted Solutions

g_lee
Level 6

A clue as to why/how vxprivutil was zeroed is in your output examples:

# root> /etc/vx/diag.d/vxprivutil scan /dev/vx/rdmp/c21t11d2;echo $?

and later:

/homeroot/root> ll /etc/vx/diag.d/vxprivutil

It appears your default prompt (PS1) is [current working directory]> (ie: current working directory followed by the ">" character. If the command was copied and pasted from an earlier run, and the last character of the prompt was accidentally copied as well, this would zero the file.

ie: if you accidentally enter

> /etc/vx/diag.d/vxprivutil scan <disk>

instead of just

/etc/vx/diag.d/vxprivutil scan <disk>

This would zero the file, as it directs "nothing" to the file (ie: overwrites its contents with nothing)

Similarly, if you ran the command in your intial post exactly as follows:

# root> /etc/vx/diag.d/vxprivutil scan /dev/vx/rdmp/c21t11d2;echo $?

Assuming the # is your prompt and the rest of the line (ie: in italics) is your command, this would definitely have overwritten the file with the contents of the file "root" if it existed. If no file named "root" existed (which presumably is the case) then this overwrites the contents with nothing, resulting in a zero file.

In summary, to avoid this problem in future take care when copying/pasting commands, particularly if your prompt has ">" or other characters that may be interpreted/parsed by shell if entered accidentally/incorrectly!

View solution in original post

8 REPLIES 8

Gaurav_S
Moderator
Moderator
   VIP    Certified

very strange..

are you getting the same message while doing a dumpconfig as well ?

Only thing that comes to my mind at this point is IOFencing, are you using this box in cluster with IOFencing enabled ? just thinking if any reservation is blocking to read from the disk..

 

Gaurav

timus
Level 4

Yes same message with dumpconfig as well -

root> /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/rdmp/c21t11d2;echo $?
126

IOFencing is not enabled.

Gaurav_S
Moderator
Moderator
   VIP    Certified
hmm .. anything change from storage recently ?

kunal
Level 4
Employee

Hi,

Exit code 126 generally means that the command was found but was not executable and its most likely permissions issue.

 

It might be worth checking the permissions of /etc/vx/diag.d/vxprivutil

timus
Level 4

No changes done from storage side.

file permissions seems ok

/homeroot/root> ll /etc/vx/diag.d/vxprivutil
lr-xr-xr-x   1 bin        bin             30 Feb 22  2010 /etc/vx/diag.d/vxprivutil -> /etc/vx/type/static/vxprivutil

homeroot/root> ll /etc/vx/type/static/vxprivutil
-r-xr-xr-x   1 bin        bin              0 Dec  3 05:12 /etc/vx/type/static/vxprivutil

g_lee
Level 6

According to your output /etc/vx/type/static/vxprivutil is a zero-sized file - it looks like the file may have been accidentally overwritten/zeroed on Dec 3 05:12 according to the timestamp

This would be why the file is not executable / is giving an error.

If you have a backup available, you will need to restore a good copy of the file from backup.

Alternatively, if you have another system with the same platform version and exact same SF version you could try copying that file from the good system to see if that will work - note that the version details need to match exactly (ie: don't copy the file from a system with an older/newer version of VxVM, or different version of OS, etc as this will not work)

timus
Level 4

Thanks for all the help, it worked after copying "vxprivutil" from another system. but why vxprivutil became size-zero is still unanswered. anways thanks all of you.

g_lee
Level 6

A clue as to why/how vxprivutil was zeroed is in your output examples:

# root> /etc/vx/diag.d/vxprivutil scan /dev/vx/rdmp/c21t11d2;echo $?

and later:

/homeroot/root> ll /etc/vx/diag.d/vxprivutil

It appears your default prompt (PS1) is [current working directory]> (ie: current working directory followed by the ">" character. If the command was copied and pasted from an earlier run, and the last character of the prompt was accidentally copied as well, this would zero the file.

ie: if you accidentally enter

> /etc/vx/diag.d/vxprivutil scan <disk>

instead of just

/etc/vx/diag.d/vxprivutil scan <disk>

This would zero the file, as it directs "nothing" to the file (ie: overwrites its contents with nothing)

Similarly, if you ran the command in your intial post exactly as follows:

# root> /etc/vx/diag.d/vxprivutil scan /dev/vx/rdmp/c21t11d2;echo $?

Assuming the # is your prompt and the rest of the line (ie: in italics) is your command, this would definitely have overwritten the file with the contents of the file "root" if it existed. If no file named "root" existed (which presumably is the case) then this overwrites the contents with nothing, resulting in a zero file.

In summary, to avoid this problem in future take care when copying/pasting commands, particularly if your prompt has ">" or other characters that may be interpreted/parsed by shell if entered accidentally/incorrectly!