Replacing bad mirror disk - pvcreate -f error

[William Baines]

Hi all,

I ran into a problem replacing a bad mirror disk and would appreciate some insights.

System:
9000/898/K370
Number of CPUs: 1
CPU Speed: 200 MHz
HP-UX B.10.20 E 9000/898

I swapped out the bad physical disk with a new one and issued the pvcreate -f command to initialize the disk.

I got the message:
pvcreate: The physical volume "/dev/dsk/c0t4d0" is already recorded in the "/etc/lvmtab" file.

So I used lvreduce to remove the disk entries from the 2 logical volumes that were on the bad mirror disk. I had to use the key paramter, but it processed the command OK.

Then I tried to use the vgreduce command to remove the old disk entries from lvmtab.
I get the message:
vgreduce: Couldn't query physical volume "/dev/dsk/c0t4d0":
The specified path does not correspond to physical volume attached to
this volume group

Ok - so I use the vgreduce -f option to force a rescan of the volume group and get the same message:
vgreduce: Couldn't query physical volume "/dev/dsk/c0t4d0":
The specified path does not correspond to physical volume attached to
this volume group

Are there any patch sets that address the failures of pvcreate and vgreduce to remove the missing disk?

The latest LVM patches I show on the system is:
PHCO_15895 B.10.00.00.AA LVM commands cumulative patch
PHKL_14491 B.10.00.00.AA VM,LVM,I/O,JFS,mprotect,SCSI,PM cumulative patch

Thanks

[Stefan Farrelly]

The problem is you replaced the disk without vgreducing it first. No worries, just forget using pvcreate, use vgcfgrestore on it and you should be back in business.

[James R. Ferguson]

William:

A more recent set of LVM cumulative patches is PHCO_18563.

...JRF...

[James R. Ferguson]

William:

A more recent set of LVM cumulative patches is PHCO_18563.

...JRF...

[Rita C Workman · Accepted solution]

Well, I have taken a very slightly approach when I have had to replace and resync either the main drive or the mirror drive. And I've had them fail either way.
If I am understanding your issue, your mirror drive went bad and you needed to replace it and resync the data back to the mirror from the primary.....

This is what I normally do...

Take down my system ( single user is up to you..I just take down the apps and vg affected)

1. Replace the bad drive with the new drive.
2. pvcreate -f /dev/rdsk/c_t_d_
3. vgcfgrestore /dev/vol_grp /dev/dsk/c_t_d_
4. vgchange -a y /dev/vol_grp
5. Either run:
vgsync /dev/vol_grp
OR
lvsync /dev/vol_grp/lvol_

Then I usually just bring it all back up....so far this has worked ok for me.

[Stefan Farrelly]

Take a look at the following link, it contains exact steps on replacing a mirror disk or a non-mirror disk or a boot disk.

http://europe-support.external.hp.com/cki/bin/doc.pl/sid=17b41b171db01f8983/screen=ckiDisplayDocument?docId=200000049436442

You dont need to use pvcreate, vgcfgrestore is enough.

[Denver Osborn]

I'll agree w/ Stefan. You don't need to pvcreate a replaced LVM Disk, the system already knows it belongs to the vg. Just restore the info to the header of the disk so it knows it belongs to the vg.

Here are some commands to help if you are unable to access that doc.

Restore lvm info:
# vgcfgrestore -n /dev/vg00 /dev/rdsk/c?t?d?

Make changes known:
# vgchange -a y /dev/vg00

Resync mirror copy:
# vgsync /dev/vg00

Make it bootable:
# mkboot /dev/rdsk/c?t?d?
# mkboot "hpux -lq" /dev/rdsk/c?t?d?

[William Baines]

Thanks to all for your help! (points awarded)
I was amazed at how quickly I got responses.

I was missing the vgchange command step to make the changes active. All bad drives have since been replaced and all mirrors resynched. Now I can sleep at night again :)