ignite backup fails due to missing link with lvmtab error

[masood bt]

create_recovery_image on hpux 11.23 server fails...

# /var/opt/ignite/create_recovery_image.sh
* Creating NFS mount directories for configuration files.

======= 10/21/20 15:36:47 BST Started /opt/ignite/bin/make_net_recovery. (WedOct 21 15:36:47 BST 2020)
@(#)Ignite-UX Revision C.7.2.94
@(#)ignite/net_recovery (opt) $Revision: 10.882 $ $Date: 2007/02/28
17:10:48 $

* Testing for necessary pax patch.
* Checking Versions of Recovery Tools
* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
01A4B07594C/recovery/2020-10-21,15:36/system_cfg vg00
lvlnboot: Couldn't query physical volume "/dev/dsk/c14t0d1":
The specified path does not correspond to physical volume attached to
this volume group
save_config: Error - The command "lvlnboot" returns a non-zero value. You may use "vgscan -v " command to recreate the "/etc/lvmtab" file.
ERROR: /opt/ignite/bin/save_config failed

======= 10/21/20 15:37:04 BST make_net_recovery completed unsuccessfully
#

It is not just /dev/dsk/c14t0d1 but all C14txdx disks are missing

C16txdx is alternate disk path. this is present.

lvlnboot: Couldn't query physical volume "/dev/dsk/c14t0d1":

# lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c2t0d0 (0/1/1/0.0.0) -- Boot Disk
/dev/dsk/c2t1d0 (0/1/1/0.1.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c2t0d0
/dev/dsk/c2t1d0
Root: lvol4 on: /dev/dsk/c2t0d0
/dev/dsk/c2t1d0
Swap: lvol2 on: /dev/dsk/c2t0d0
/dev/dsk/c2t1d0
Dump: lvol3 on: /dev/dsk/c2t0d0, 0

lvlnboot: Couldn't query physical volume "/dev/dsk/c14t0d1":
The specified path does not correspond to physical volume attached to this volume group

#

# ioscan -fnC disk|grep c14|wc -l
0
# ioscan -fnC disk|grep c16|wc -l
119
#

All disks' paths with c14 controller gone missing.

[PSPrakash]

Hello

Since you confirmed all disk paths with C14txdx are missing, either you may investigate why the c14 path is missing.

OR  Update the /etc/lvmtab with new path (if any)
If no new paths are available , you may reduce those missing (c14) paths from /etc/lvmtab (using vgreduce) .

[rachelgomez_123]

The lvdisplay/"lvremove" advise, lvremove should have been indeed lvreduce, came from a larger "replacing a faulty disk / secure way" procedure as can be seen below.

And this procedure, indeed makes the assumption, that at the start of the procedure, both the problem disk, is still part of /etc/lvmtab and even that the "faulty" disk is somehow visible in ioscan -fn, however the disk somehow visible in ioscan -fn, is not a must, I think.

Greetz,
Chris

>>>>>>>
replacing a faulty disk / secure way

Remove all extents from the defective lvol

#lvdisplay -v /dev/vg01/lvol4 > /tmp/lvdisplay_lvol4.out

#lvdisplay -v -k /dev/vg01/lvol4

#lvreduce -m 0 -k /dev/vg01/lvol4 7

Repeat above procedure for each affected lvol

Note : The lvreduce command will also remove extents off disks that are not defective, if this disks are so "unlucky" to be at the "same

side" as the defective disk.

* Remove the failed disks from /etc/lvmtab

#vgreduce -f /dev/vg01

Note : The vgreduce doesnt always work out. If you receive a error like

"/etc/lvmtab is out of date with the running kernel" then you will have to solve

this first.

"/etc/lvmtab is out of date" error

#cp /etc/lvmtab /etc/lvmtab.orig

#vgscan -p -v

a preview vgscan to check if the missing disks are left out

OK!

#mv /etc/lvmtab /etc/lvmtab.orig

#vgscan -v

">

works OK!

#vgchange -a y /dev/vg01

#lvlnboot -R

#vgreduce -f /dev/vg01

OK!

* Reactivate the volumegroup, which included the failed disk

#vgchange -a y /dev/vg01

#vgdisplay -v /dev/vg01

Act 9

Cur 9

pulled out defective disk

Regards,

Rachel Gomez