volume group disk problem

[Brian Harris]

I am running 10.20 on a legacy system and when I run any vg command I get following errors
Couldn't query physical volume "/dev/dsk/c1t3d0"
The specified path does not correspond to physical volume attached to this volume group.
the volume group is vg00 which has O/S on it.
This happened because I removed this disk and replaced it with a larger disk. The disk had no logical volumes on it, but I forgot to remove it from volume group before I replaced disk. I have tried many different things from recreating lvmtab to vgreduce and none ot this works. When I do vgdisplay it says Cur PV 4 and Act PV 3. It says this even when I have removed this disk from lvmtab. currently disk is in lvmtab. the vgdisplay does not show the disk I want removed c1t3d0. It shows other 3 disk which are still good.
I am looking for information on how to fix my problem. I do not need this disk in vg00 at this time, if I can remove it then I can re add it later old disk was 1 gig new disk is 4 gig I plan to use it to mirror o/s

[Torsten.]

Hi,

read the man page about "vgreduce" - the "-f" option is yours,
e.g. vgreduce -f vg00

[Brian Harris]

I have already tried the -f and it fails with following message
# vgreduce -f /dev/vg00
vgreduce: Couldn't query physical volume "/dev/dsk/c1t3d0":
The specified path does not correspond to physical volume attached to

I also tried it by remaking lvmtab to remove c1t3d0 and then do vgreduce and that also did not work
So I am no longer sure if I should first remove c1t3d0 or if I need to first do something to pv c1t3d0.

[erics_1 · Accepted solution]

Is this a disk you hot swapped out while the system was running? If so, try:

vgcfgrestore -n /dev/vg00 /dev/dsk/c1t3d0
vgchange -a y vg00
vgdisplay vg00 -->Does Act PV and Cur PV
match? If not:

mv /etc/lvmtab /etc/lvmtab.orig
vgscan -v

Eric

[Sheriff Andy]

As Eric recommended, mv the lvmtab then vgscan -v.

If that doesn't work, try ignite.

Andy

[Yang Qin_1]

I'm not sure vgcfgrestore will work in your case as the size of disk is not the same. If it does not work, try to remove newly replaced disk (/dev/dsk/c1t3d0) from your server and then try vgreduce -f /dev/vg00. You may need to put original lvmtab back if you still have a backup for that file. The reason is that from vgreduce manpage:

-f vg_name force reduction of missing physical volume(s) in a given volume group. vgreduce obtains the name of each physical volume (PV) belonging to the volume group from the file /etc/lvmtab. ...


Yang

[Sandman!]

Since it's vg00 and "vgreduce -f" is not working for you then your only option maybe to boot your system into lvm maintenance mode and do the following:

- vgexport -m /mapfile vg00
- mknod vg00
- vgimport -m /mapfile vg00 /dev/dsk/c#t#d# ...
- reboot into multi-user mode; and
- vgreduce -f vg00

~hope it helps

[Brian Harris]

I found a solution that seems to have worked, which is same solution some one posted. I did a vgcfgrestore and then a vgchange. and then when I did a vgdisplay it showed the new disk and it seems to be correct size. I had tried vgcfgrestore before but I had not used vgchange, because I only thought you did that when the volume group was not active, and in this case rest of the volume group was active and working. I don't understand why I had to do it, but it worked