Physical Volume in LVMTAB not recognized with vgdisplay.

[Steven Hymanson]

I had a VG named vg01 with 2 disks and 4 logical volumes. I vgextended vg01 to include 2 more disks (c1t6d0, c2t6d0) and created a logical volume on the new disk. In the /etc/lvmtab I see vg01 and all 4 disks. When I run vgdisplay -v vg01, it shows only 3 of the disks and complains "vgdisplay: Warning: couldn't query physical volume /dev/dsk/c1t6d0: The specified path does not correspond to physical volume attached to this volume group". If I run vgcfgbackup vg01 I get "vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates 3 disks for "/dev/vg01"; /etc/lvmtab has 4 disks.
Cannot proceed with backup.". A reboot didn't clear this. Any ideas for fixing this inconsistency?

I receive

[RAC_1]

vgdisplay, must be showing active disk 4 and current disk 3. Is that right??

Do you have disk /dev/dsk/c1t6d0?? Can you do pvdisplay on all pvs under vg01??

What does vgsan -pva say??

[Steven Hymanson]

vgdisplay -v shows 3 disks. I can run diskinfo on c1t6d0 and it looks fine. When I run pvdisplay -v /dev/dsk/c1t6d0 I get "pvdisplay: Warning: couldn't query physical volume "/dev/dsk/c1t6d0":
The specified path does not correspond to physical volume attached to
this volume group
pvdisplay: Warning: couldn't query all of the physical volumes.
pvdisplay: Couldn't retrieve the names of the physical volumes
belonging to volume group "/dev/vg01".
pvdisplay: Cannot display physical volume "/dev/dsk/c1t6d0". The vgscan -p -v shows "Following Physical Volumes belong to one Volume Group.
Unable to match these Physical Volumes to a Volume Group.
Use the vgimport command to complete the process.
/dev/dsk/c1t6d0. Looks to me like the problem is that c1t6d0 doesn't have anything about vg01 in its header. Maybe a vgcfgrestore -n vg01 /dev/dsk/c1t6d0 and then a vgchange -a y vg01 and vgsync vg01 would work (like with a new disk).

[RAC_1]

strings /etc/lvmtab. Does vg01 show three or four disks??

Is firmware version on disk very old?? (disk info shows that. You can compare the diskinfo info of some other disk)

If it is showing in /etc/lvmtab, and you are sure it is part of vg01, you can run vgcfgrestore and try it.

Anil

[TwoProc]

Maybe you didn't do a pvcreate before adding it to the volume group? I'm thinking that the pv information on the disk is from a previous time when the disk belonged to a different volume group, and now it's confused. If this is so, can you just remove the offending disk from the vg - run pvcreate on it, and put it back in the volume group?

[Steven Hymanson]

The lvmtab shows all 4 disks. I believe what you are saying may be true. Another Application ran on this Server so the disk probably had old VG info on it. I did a pvcreate not a pvcreate -f and maybe I didn't see the message come out that cannot pvcreate cause belongs to another VG. Then I did the vgextend which added it to vg01 in lvmtab. It may be confused because the header info on /dev/dsk/c1t6d0 is not from vg01 but the lvmtab shows it as part of the VG. I cannot reduce it from the VG because it doesn't recognize it as part of vg01. Would the vgcfgrestore -n vg01 /dev/dsk/c1t6d0 work? If it did I could then do an lvextend -m 1 on the new logical volume I created on c2t6d0 to c1t6d0.

[Alan Meyer_4]

You should also use pvcreate -f to force a new format upon the disk

[TwoProc]

I'm thinking that at this point we could fail it like you've had a hard drive problem/error. Pull the disk, wait a while, re-insert. Run pvcreate -f on it. Then do a vgcfgrestore. If that doesn't work. Repeat, but do with a "dd if=/dev/zero of=/dev/dsk/c1t6d0 bs=8k" command first, then do what I said before.

If THIS doesn't work - pull the disk off to another spare HP box, and run the "dd" command, then a "pvcreate -f" command, then run "pvremove" on it. Then bring back to the original box that you were working on. You should be OK at that point.

If you can't(or don't want to) actually 'pull' the disks as per my suggestion above, then you can probably accomplish everything without it - I'm just thinking that the more steps we can use to convince the system that it's a failed disk the better (but probably totally unnecessary).

Also, keep in mind that if this is a disk that you're going to mirror a boot drive from you've got to run the pvcreate command with the "-B" option, as well as running the mkboot command.

[Devesh Pant_1]

The ioscan -funC disk should show the disk to be CLAIMED

If it is claimed then do the diskinfo on that disk.

These two should provide enough info to take it from there.

thanks
DP

[vinod_25]

hi steve

1. Boot into maintenance mode.

2. vgexport vg00

3. mkdir /dev/vg00

4. mknod /dev/vg00/group c 64 0x000000

5. vgimport /dev/vg00

If you are using standard lvol names then a map file is not needed.

6. vgscan

7. Do vgdisplay of vg00, it should now show the current and 4 active.

8. lvlnboot -v

9. Reboot the system.

The system should successfully display all active volume groups

Good Luck

vinod

[vinod_25]

hi steve

i mistook the vg as vg00(root vg). pls all ignore my previous reply;and can see this steps


1. vgexport vg01

2. mkdir /dev/vg01

3. mknod /dev/vg01/group c 64 0x010000

4. vgimport /dev/vg01

If you are using standard lvol names then a map file is not needed.

5. vgscan

6. Do vgdisplay of vg01, it should now show the current and 4 active.

7. Reboot the system if reqd.

The system should successfully display all active volume groups an pv's

Good Luck

vinod

[Devender Khatana · Accepted solution]

Hi Steven,

I was stucked with similar situation last week end. On running any commad it use to give "vgcfgbackup: /etc/lvmtab is out of date with the running kernel:Kernel indicates 3 disks for "/dev/vg01"; /etc/lvmtab has 4 disks.

As the missing disk in the one out of two new disks which you just added to the VG & do not contain anything, remove it from the VG forcefully as I did using -

#vgreduce -f /dev/vg01

Once done you can do normal vgextend after pvcreate on the same disk as posted earlier.

HTH,
Devender