PVID diffrent-cant create fs nor lv

[bonsky]

dear gurus,
I have one B80,and i am trying to create lv and it doesnt allow me. I tried extending FS still doesnt allow me. I saw that when i do lspv its different PVID from the OS that is recognizing. Meaning, when i execute extending the filesystem, it gives me error, that cannot work with hdiskx with different PVID from lspv.
Any idea how to solve this one?
i tried synclvodm. still cannot
thanks!

 

[MoshiachNow]

HI,

1.synclvodm -vP svg3
2.If this does not help - export this disk,then try finding and deleting this stalled PVID from ODM.
Then re-import the disk.

Long live king Moshiach !

http://www.7for70.com/

 

[p5wizard]

what OS level?

on 53-02 there's a bug in that extendvg 'forgets' to write a VGID to newly added PVs to a VG. There's a fix for it. Don't know the number for it, but you can find out on the AIX support pages I guess.


HTH,

p5wizard

 

[ogniemi]

I think you should follow P5wizard's suggestion,

I also remember, long time ago I had similiar problem when disk's pvid changed - then I found the following (not supported) procedure for old pvid restoring (it helpded for me):


"
One method to get the volume group back is to write the old PVID onto
the disk. Here is a way to do that:



1) Translate the ORIGONAL PVID into the octal version. Take every 2
digits of the hex PVID and translate it to octal. This can be done
by hand, calculator, script, or web page.


00012a3e42bc908f3 -> 00 12 a3 e4 2b c9 08 f3
Octal version -> 000 022 243 344 053 311 010 363


2) Write the binary version of the PVID to the disk by using the octal
values. Each octal char is lead with a backslash-Zero "\0". Do
not use spaces or any other characters except for the final \c to
keep from issuing a hard return.


# echo "\0000\0022\0243\0344\0053\0311\0010\0363\c" |dd
of=/dev/hdisk0 bs=1 seek=128


Use the above info at your own risk.

 

[bonsky]

thanks alot guys for your help, however, the problem lies on my rootvg and not the othe vgs. So i cant do export -import of the vg here. any other ideas? thanks!

 

[DSMARWAY]

hi ,

which disk in the rootvg is your LV on ?

Is it mirrored ?



if so is the disk that it complains about a miiror copy if so you can reduce the mirrors ( smity rmlvcopy) so the disk it complains about is out of the question

Then try extending LV .. if it works

then take the disk out of the volume group ( you'll have to unmirror the rest of the LVs that reside on the disk)

take disk out of volume group

then re-add it back it and mirror everything back nb :-
if root disk mirror remeber to do bosboot etc...

 

[ogniemi]

I know that there is a way to reinitialize rootvg entries in odm.

http://www.unet.univie.ac.at/aix/aixprob/prbslvgd/reintrootvg.htm

---PASTE BEGIN---
Reinitializing the rootvg Volume Group
To reinitialize the rootvg volume group, copy the shell script to /bin/rvgrecover and run the following to make that file executable:

chmod +x /bin/rvgrecover
Then run:

/bin/rvgrecover
Use the following shell script to reinitialize the ODM entries for the rootvg volume group:

PV=/dev/ipldevice
VG=rootvg
cp /etc/objrepos/CuAt /etc/objrepos/CuAt.$$
cp /etc/objrepos/CuDep /etc/objrepos/CuDep.$$
cp /etc/objrepos/CuDv /etc/objrepos/CuDv.$$
cp /etc/objrepos/CuDvDr /etc/objrepos/CuDvDr.$$
lqueryvg -Lp $PV | awk '{ print $2 }' | while read LVname; do
odmdelete -q "name = $LVname" -o CuAt
odmdelete -q "name = $LVname" -o CuDv
odmdelete -q "value3 = $LVname" -o CuDvDr
done
odmdelete -q "name = $VG" -o CuAt
odmdelete -q "parent = $VG" -o CuDv
odmdelete -q "name = $VG" -o CuDv
odmdelete -q "name = $VG" -o CuDep
odmdelete -q "dependency = $VG" -o CuDep
odmdelete -q "value1 = 10" -o CuDvDr
odmdelete -q "value3 = $VG" -o CuDvDr
importvg -y $VG $PV # ignore lvaryoffvg errors
varyonvg $VG

---PASTE END---

maybe I am wrong, but I think that the same tip I had seen in some redbook...