vgchange failed

[Wayne Yu_1]

I helped a customer populate a N4000 server to another identical N4000 server by "make_tape_recovery" and boot the tape on the 2nd ssystem. I did change the advanced option during boot to be "on a different H/w".

Once the system came up, I cleaned the other VGs by vgexport them. Only left vg00, then I mirrored them one logical volume at a time.
Everything looks fine before I reboot the 2nd box.

During boot, vgchange complaints:"
vgchange:
Couldn't set the unique id for volume group "/dev/vg00"

File exists."

What unique ID and which file exisits? How could fix this problem? the system actually boot up and mirrors are working, vgdisplay would not show anything, but lvdisplay show all the logical volumes fine.

Have never seen this before. I would suggest the programmer if they decide to putout error message and bail out, please explain in the man page how to fix the problem or at least explain what was the thing it talked about. vgchange 's man page has nothing about this error.

Thanks for any help.

[Sridhar Bhaskarla]

Hi,

For me it looks like a conflict of the minor numbers. Do an ll /dev/*/group and see if there are group files in the other volume groups with the same minor number. Get rid of them.

If it does not solve the problem, then do the following.

Bring the system in lm maintenance mode (interact with isl, boot the system with hpux -lm -is command).

Once it boots, do an export of vg00. Create vg00 fresh and then import it back and then run the lvlnboot commands.


-Sri

[S.K. Chan · Accepted solution]

I've seen this once, basically it means LVM will not allow the same group minor to be activated with a different VGID and if you do that vgchange activation will complain. What you have to do is, take note of all your VGs group minor number (assuming they are all unique), pick the next unique minor number that's not used. This minor number will be used to recreate vg00. Then you would have to boot in LVM maintenance mode (hpux -lm), then do ..
# vgexport -m /mapfile /dev/vg00
# mkdir /dev/vg00
# mknod /dev/vg00/group c 64 0x0#0000
=> Use the "unique" minor number that you have noted down earlier.
# vgimport -m /mapfile /dev/vg00 /dev/dsk/CXtYdZ /dev/dsk/...
# vgchange -a y /dev/vg00
It should activate without complaining now.

[Wayne Yu_1]

But on the system, there is no other volume group other than vg00. Under /dev there is only one vg00. Vgexport already removed all other /dev/vg*. I will try to schdule a time to the customer site and take look and hopefully, there is no other /dev/vg* on the system....

[Jeff Schussele]

Hi Wayne,

What does
strings /etc/lvmtab | more
show?

Are there more than one VG in there?

If so
mv /etc/lvmtab /etc/lvmtab.old
vgscan -av
then try to vgchange the vg00 VG.

Also IF the tape came off an MC/SG system, you may have pulled over a file named
/dev/slvmvg
that has the same major/minor numbers as vg00.
IF you aren't running MC/SG you should remove this file & rebuild lvmtab as noted above.

Rgds,
Jeff

[Wayne Yu_1]

lvmtab has only vg00 in it and two mirrored drives. There is no other volume group on the system, other than vg00.

[Dietmar Konermann]

Hi!

During activation LVM gets the VGID from /etc/lvmtab and creates a new VG structure in memory. While attaching PVs to that structure the VGID of that PVs are checked against that one found in lvmtab.

So I assume that the VGID in lvmtab does not match the VGID on disk. vgexport/vgimport from maintanance mode should fix the problem. See other responses above.

To check the VGID on disk:

echo "0d8208?UU" | /usr/bin/adb /dev/dsk/cXtYdZ

To check the VGID from lvmtab:

strings -t d /etc/lvmtab |grep /dev |grep -v /dev/dsk |while read offset path; do
xd -An -j$(($offset+1024)) -N8 -tuL /etc/lvmtab |read vgid1 vgid2
echo $path $vgid1 $vgid2
done

Regards...
Dietmar.

[Wayne Yu_1]

vgexport and vgimport fixed the problem. It is strange that only doing vgexport to other vgs could affect the vg00. But it is fixed now and customer is happy.