Couldn't query volume group "vg00"

[Ralph Grothe]

Hello forumers,

currently I cannot access the URI of the ITRC Technical Knowledge Base (immediately after servicing of index page I get an HTTP 404).

That's why I have to bother you although I guess this is one of those FAQs.

Actually, I only realized this when a make_recovery failed because it couldn't query LVM metadata for vg00.

The same happens when I invoke vgdisplay:

# vgdisplay vg00
vgdisplay: Couldn't query volume group "vg00".
Possible error in the Volume Group minor number; Please check and make sure the group minor number is u
nique.
vgdisplay: Cannot display volume group "vg00".


I cannot see that a device minor number is being reused as the error message implies.

# ll /dev/vg00/|sort -n +6
brw-r----- 1 root sys 64 0x000001 May 8 2003 lvol1
brw-r----- 1 root sys 64 0x000002 Oct 19 1999 lvol2
brw-r----- 1 root sys 64 0x000003 Oct 19 1999 lvol3
brw-r----- 1 root sys 64 0x000004 May 8 2003 lvol4
brw-r----- 1 root sys 64 0x000005 May 8 2003 lvol5
brw-r----- 1 root sys 64 0x000006 May 8 2003 lvol6
brw-r----- 1 root sys 64 0x000007 May 8 2003 lvol7
brw-r----- 1 root sys 64 0x000008 May 8 2003 lvol8
brw-r----- 1 root sys 64 0x000009 May 8 2003 lvol9
brw-r----- 1 root sys 64 0x00000a Jan 7 2000 lvol10
crw-r----- 1 root sys 64 0x000001 Oct 19 1999 rlvol1
crw-r----- 1 root sys 64 0x000002 Oct 19 1999 rlvol2
crw-r----- 1 root sys 64 0x000003 Oct 19 1999 rlvol3
crw-r----- 1 root sys 64 0x000004 Oct 19 1999 rlvol4
crw-r----- 1 root sys 64 0x000005 Oct 19 1999 rlvol5
crw-r----- 1 root sys 64 0x000006 Oct 19 1999 rlvol6
crw-r----- 1 root sys 64 0x000007 Oct 19 1999 rlvol7
crw-r----- 1 root sys 64 0x000008 Oct 19 1999 rlvol8
crw-r----- 1 root sys 64 0x000009 Nov 30 1999 rlvol9
crw-r----- 1 root sys 64 0x00000a Jan 7 2000 rlvol10
crw-r--r-- 1 root sys 64 0x000000 Oct 19 1999 group
total 0


The backed up LVM conf of vg00 looks such

# vgcfgrestore -f /etc/lvmconf/vg00.conf -l
Volume Group Configuration information in "/etc/lvmconf/vg00.conf"
VG Name /dev/vg00
---- Physical volumes : 2 ----
/dev/rdsk/c1t6d0 (Bootable)
/dev/rdsk/c2t6d0 (Bootable)


Any ideas what else could be the reason for the failure of queries of vg00 LVM metadata?

[T G Manikandan]

I had this problem before

Are you running serviceguard or previously running

check for the file

#ls -l /dev/slvmvg
#mv /dev/slvmvg /dev/slvmvg.old
# mv /etc/lvmtab /etc/lvmtab.latest
# vgscan -v


Revert

[T G Manikandan · Accepted solution]

If that was your problem as suggested above load the patches to resolve it

PHCO_24437 - 11.00 LVM commands cumulative patch
PHCO_24809: - 11.11 LVM commands cumulative patch

[Madhu Sudhan_1]

Did you add any new groups with the minor number 0x000000 as it is implied by the error message.

[Ralph Grothe]

Manikandan,

you're right, we are using MC/SG, and I have such a device that has the same major and minor as /dev/vg00/group


# ll -i /dev/slvmvg /dev/vg00/group
1170 crw-rw---- 1 root root 64 0x000000 Nov 30 1999 /dev/slvmvg
364 crw-r--r-- 1 root sys 64 0x000000 Oct 19 1999 /dev/vg00/group


But I checked with other boxes of ours' that use MC/SG as well.
There it has the same major and minor.
So it seems in order to me.
Btw, could you tell me what this device is for?

Obviously, the cmlvmd daemon is using this device on the box where I experience the problem.


# ps -fp "$(fuser -u /dev/slvmvg 2>/dev/null)"
ps: wrong PID number
UID PID PPID C STIME TTY TIME COMMAND
root 28684 28682 0 Oct 1 ? 230:03 /usr/lbin/cmlvmd



Finally, before I execute the vgscan command I had a peek in the manpage, and got a bit intimidated when reading this:

This command
should be run only in the event of a catastrophic error such as the
deletion of the /etc/lvmtab file or the mismatch of names of the
physical volumes in the /etc/lvmtab file to the actual physical volume
path configuration.


Whoah, do you think my problem is such a "catastrophic" event that justifies this action?

I appreceate that you also suggested to make a backup copy of /etc/lvmtab prior to issuing the vgscan command.

I only want to make sure that the cluster node or any cluster package won't fail because we have a production system running there.

[Ralph Grothe]

Allen,

I don't know if someone recently created some VGs since this box is usually administered by a colleague (ok I could check mtimes or grep the syslog.log for vgcreate)
I can only see that the vg00's group device seems to be the only one that has 0x000000 as minor (apart from the slvmvg device mentioned in my reply to Manikandan's proposal).

# ll /dev/vg*/group|grep 0x000000
crw-r--r-- 1 root sys 64 0x000000 Oct 19 1999 /dev/vg00/group

[Robert-Jan Goossens]

Ralph,

http://www5.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000067003049

Regards,

Robert-Jan.

[Michael Steele_2]

Let me see, this all started when a make_recovery restoration failed.

"..Actually, I only realized this when a make_recovery failed because it couldn't query LVM metadata for vg00..."

Question 1: Sure you got the right make_recovery tape associated to the right server?

Use this procedure to verify make_recovery tape:

# mt -t /dev/rmt/0m rew
# mt -t /dev/rmt/0m rew
# mt -t /dev/rmt/0mn fsf 1 (* note, 0mn no rewind *)
# cd /tmp
# tar -xvf /dev/rmt/0m "etc/hosts"
# vi /tmp/etc/hosts
check for machine name

#######################################

At this point, since your already into the O/S installation process, why not just continue with a cold install from cdrom?

[Ralph Grothe]

Robert,

thanks for the knowledge base link.
I knew I would find it in there, and I would have searched the base exactly for that error message.
But as I told you I couldn't access the URI.
Most of the time HP webservers' servicability to European clients is inferior I suspect than what you are accustomed to at the other bank of the pond.

After performing the step I could issue vgdisplay again, and make_recovery didn't fail either.