Search This Blog

Friday, May 30, 2014

How to Mount the Os disk or any data disk in running hp-unix system

Scenario:

How to Mount the Os disk or any data disk in running hp-unix system . 

--> Create a new mount point and group file for the OS disk/data disk 

# mkdir /dev/VG NAME #mknod /dev/VG NAME /group c 64 0x0#0000 

NOTE: The minor number above must be unique. Substitute a number where the # appears based on the next available number for all of your volume groups. The following command will help find what is already in use: 

# ls -l /dev/*/group

--> Get the device file for the OS disk. The example below hardware path 0/1/1/1.2.0 

# ioscan -fnC disk -H 0/1/1/1.2.0 Class I H/W Path Driver S/W State H/W Type Description =========================================================================== 
disk 2 0/1/1/1.2.0 sdisk CLAIMED DEVICE HP 36.4GST336753LC /dev/dsk/c3t2d0 /dev/dsk/c3t2d0s1 /dev/dsk/c3t2d0s2 /dev/dsk/c3t2d0s3 /dev/rdsk/c3t2d0 /dev/rdsk/c3t2d0s1 /dev/rdsk/c3t2d0s2 /dev/rdsk/c3t2d0s3 

NOTE: The disk device MUST use the s2 partition . For OS Disk.

Note : The disk device /dev/dsk/cxtxd0 used for data disk .

-->Import the OS disk /dev/dsk/c3t2d0s2 as /vg name 

# vgimport /dev/vg name /dev/dsk/cxtxd0s2 For OS Disk
# vgimport /dev/vg name /dev/dsk/cxtxd0

--> Activate the volume group 

# vgchange -a y /dev/vg name

-->Check the OS/data disk filesystems. Check the /stand filesystem on the OS disk 
# fsck -F hfs /dev/vg name/rlvol1 

Check the root filesystem on the OS disk 
# fsck -F vxfs -o full /dev/vgname/rlvol3 

Check other filesytems 

# fsck -F vxfs -o full /dev/vgname/rlvol# 

-->Same we can check the file system on data disk
#fsck –F vxfs -y /dev/vgname/rlvol#

--> Mount the OS /Data disk filesystems 
# mkdir /dir name 
# mount /dev/vg name/lvol1 /dir name 
# mount /dev/vgname/lvol3 /dir name/stand

The Update Process: Step by Step --HP-UX (V2 to V3)


 The Update Process: Step by Step
The following steps should be done from the console:
1. Make sure that all the virtual partitions are up. You can check this with vparstatus.
Example:
vpar1# vparstatus
[Virtual Partition]
Boot
Virtual Partition Name State Attributes Kernel Path Opts
===================== ===== ============ ======================= =====
vPar1                                     Up Dyn,Auto,Asr /stand/vmunix
vPar2_                                  Up Dyn,Auto,Nsr /stand/vmunix
vpar3                                     Up Dyn,Auto,Asr /stand/vmunix
vPar4                                     Up Dyn,Auto,Asr /stand/vmunix

2. Record the current autoboot and autosearch settings of all the virtual partitions. The update process sets autoboot to manual, so you will need to restore these settings later. To find the current settings, use vparstatus.
Virtual Partition Name State Attributes Kernel Path Opts
===================== ===== ============ ======================= =====
vPar1                                     Up Dyn,Auto,Asr /stand/vmunix
vPar2_                                  Up Dyn,Auto,Nsr /stand/vmunix
vpar3                                     Up Dyn,Auto,Asr /stand/vmunix
vPar4                                     Up Dyn,Auto,Asr /stand/vmunix

NOTE :
In a mixed HP-UX 11i v2/v3 vPars environment, the vPars running A.04.xx must be running version A.04.02 or later. Therefore, the “Revision” field in the depot should be A.04.02 or greater.
In our Scenario, all the vPars are running on A.04.05.07. That’s why we are updating only one virtual partition(vpar4).

Rebuilding the kernel
The update can fail if the HP-UX kernel build fails in the starting environment. To ensure that
you have a reliable starting point, rebuild the kernel before you update:
1. As root, enter:
/usr/sbin/mk_kernel –o /stand/vmunix

2. Fix any problems listed in the mk_kernel output.
3. Reboot your system to ensure that your new kernel boots.
Protect One Disk for all vPars
#pvchange –a N
Stop the LVM to access secondary disk and remove it.

For example (output):

# pvchange -a N /dev/dsk/c14t0d0s2
Warning: Detaching a physical volume reduces the availability of data
within the logical volumes residing on that disk.
Prior to detaching a physical volume or the last available path to it,
verify that there are alternate copies of the data
available on other disks in the volume group.
If necessary, use pvchange(1M) to reverse this operation.
Physical volume "/dev/dsk/c14t0d0s2" has been successfully changed.

Check vg status--- (disk should show unavailable)
#vgdisplay –v
--- Physical volumes ---
PV Name /dev/dsk/c6t0d0s2
PV Status available
Total PE 4346
Free PE 1901
Autoswitch On
Proactive Polling On
PV Name /dev/dsk/c14t0d0s2
PV Status unavailable à Search for this information in output.
Total PE 4346
Free PE 1901
Autoswitch On
Proactive Polling On
è Then boot the server with primary disk .

Renaming your log files in vpar4
You should also rename your log files to make it easier to find problems encountered during an
update.
1. Enter:
cd /var/adm/sw
2. As root, rename each log file. For example:
mv swagent.log swagent_old.log
3. cd /var/opt/swm
4. mv swm.log swm_old.log

3. Install the latest Update-UX bundle onto each virtual partition (use Ctrl-A to switch between consoles).
Note that this does not update the operating system, only the Update-UX bundle.

From the DVD media
To install the Update-UX product from the Operating Environment DVDs:
1. Mount the DVD :
à Insert the DVD into the DVD drive.
à Find the DVD-ROM device file name:

#ioscan -C disk -f -n -k | more

A typical device name is /dev/dsk/c1t2d0
à Create a directory under root (/). For example:

#mkdir /dvdrom

à Mount the DVD onto the new directory as a file system. For example:
#mount /dev/dsk/c1t2d0 /dvdrom

2. Using swinstall, install the latest version of the Update-UX product on the target system:
#swinstall -s /dvdrom Update-UX

NOTE: Make sure you use the correct case to install the Update-UX product (in title case).
This product contains the update-ux command (lowercase).

4. Determine if you need to change the PRI boot path and perform accordingly:
If the current nPartition’s PRI boot path currently points to a virtual partition that will be updated to only A.04.xx and not A.05.01, you will need to change the nPartition’s PRI boot path such that it points to the boot disk of a virtual partition that will be updated to A.05.01
In our Scenario, the first virtual partition vpar1 running A.04.05 (on 11.23) . so we need to change the nPartition PRI boot path and can proceed to the next step.
a. Find the nPartition partition number for the current nPartition:

#parstatus –w
The local partition number is 1
The nPartition number is 1. Record this information.

b. Find the boot path of the boot disk of a future vPars A.05.01 virtual partition. This boot path will become the nPartition’s new PRI boot path.
Since vpa4  is being updated to A.05.01, let’s chose to change the nPartition’s PRI path to the boot disk of vpa4 . Since we have chosen vpa4  as the future A.05.01 virtual partition, we need to find the boot path of vpa4 :

# vparstatus -v -p vpar4
...
IO Details]
4.0.4.1.0
5.0.9.1.0
4.0.8.1.0
5.0.14.1.0
4.0.6.1.0
5.0.4.1.0
4.0.4.1.0.4.0.0.0.0.0.0.0 BOOT
5.0.4.1.0.4.0.0.0.0.0.0.0, ALTBOOT
BOOT attribute identifies the boot path for the virtual partition vpa4 (pproxy01) as 4.0.4.1.0.4.0.0.0.0.0.0.0
Record this information.

c. Set the mode for the next nPartition reboot:
• on Integrity, set the mode to nPars for the next reboot:

# vparenv -m nPars
The remainder of the steps to change the PRI boot path will be done later, while in nPars/standalone mode.

5. For each virtual partition, except the first virtual partition, use Update-UX to install the latest OE and vPars bundle.
where target OS will be 11.31, which implies vPars A.05.xx:

run this command on vPar4:

From dvdrom:
# update-ux –p -s /dvdrom HPUX11i-VSE-OE T1335DC
# update-ux -s /dvdrom HPUX11i-VSE-OE T1335DC
NOTE Be sure that both the OE and vPars bundles are specified on the update-ux command line. When using Update-UX to update vPars, you must update in this manner, in which case
you are updating both the OS and vPars version with the same command line.

6. After the all updates for the above virtual partitions have completed, use shutdown –hy0 command to halt all the vpars.
Shutdown all the vpars in the given npar using below command

#shutdown –hy 0

7. Reboot the nPartition.
On Integrity, if you need to change the PRI boot path, reboot in nPars mode:

MON> reboot npars

8. If you need to change the PRI boot path, follow the procedure below. Otherwise, proceed to the next step.

a. Interrupt the boot up process and enter into standalone nPars (Integrity) mode:
For Integrity:
Shell> fs0:
fs0:\> ls
fs0:> cd EFI
fs0:\>cd hpux
fs0:\> hpux
HPUX> boot vmunix

b. Change the nPartition’s PRI path to the boot path of the future A.05.01 partition recorded earlier.

# parmodify –p1 -b 4.0.4.1.0.4.0
where the syntax of parmodify is
-p nPartition_number
-b primary_boot_path

c. Verify the new PRI path using parstatus:

# parstatus -p0 -V
[Partition]
Partition Number : 1
Partition Name : npar1
Status : active
IP address : 0.0.0.0
PrimaryBoot Path : 4/0/4/1/0/4.0

d. Once the PRI path has been successfully changed, set the mode to back to vPars:
# vparenv -m vPars

e. Reboot the nPartition:
# shutdown -ry 0

9. If needed (depending upon how your nPartition’s autoboot configuration is set up), interrupt the nPartition boot process and load the vPars Monitor.
Shell>map -r
Shell> fs0: select the correct file system .
fs0:\> ls
fs0:> cd EFI
fs0:\>cd hpux
fs0:\> hpux
HPUX> boot vpmon

10. Boot the virtual partitions. First we boot the updated vPar the we boot the other vPars one by one .
MON> vparload –p
When the virtual partitions are booted, they will continue and complete their update processes (the virtual partitions can be booed in any order). After this is completed, you should arrive at the login: prompt for each virtual partition. Login as root and continue to the next step.
11. Turn autoboot and autosearch settings back to their original settings that you recorded earlier above.
Vpar4 # vparmodify -p vpar4 -B auto

12. Verification of Virtual Partitions
The virtual partitions should now be running the latest vPars version. To verify this, you can login to each virtual partition and use the vparstatus command with the -P option.

#vparstatus -P

13. Verification of Correct vPars Monitor

If you changed the nPartition’s PRI boot path, you can also verify that the vPars monitor has been booted from the correct boot disk:

# vparstatus -m
Console path: No path as console is virtual
Monitor boot disk path: 0.0.6.0.0.5.0
Monitor boot filename: /stand/vpmon
Database filename: /stand/vpdb

Then insert the secondary disk .
# pvchange -a y /dev/dsk/cXtXdXs2
For example (output):
# pvchange -a y /dev/dsk/c14t0d0s2
Physical volume "/dev/dsk/c14t0d0s2" has been successfully changed.

Sync primary and secondary disk
# vgsync vg00
Set the boot path :

# setboot –p -b on

What is a Ghost Disk ? HP-UX



You may come into a situation where you have to remove a PV from a VG that has failed or not even physically connected but still recorded in the lvmtab. Such a PV is sometimes called a “ghost disk” or “phantom disk”. You can get a ghost disk if the disk has failed before VG activation, maybe because the system has been rebooted after the failure.

If you cannot use vgcfgrestore to write the original LVM header back to the new disk because a valid LVM configuration backup file (/etc/lvmconf/vgXX.conf[.old]) is missing or corrupted you have to remove that PV from the VG (vgreduce) to get a clean configuration.

NOTE: In such situations the vgcfgrestore command may fail to restore the LVM header, complaining about a ‘Mismatch between the backup file and the running kernel’. If you are 100% sure that your backup is valid you may override this check using the –R option.

In order to remove a PV from a VG you have to free it first, i.e. remove all logical extents from it. If the LVs on such a disk is not mirrored data is lost anyway. If it is mirrored you need to reduce the mirror before removing the PV.

A ghost disk is usually indicated by vgdisplay reporting more current PVs than active ones. Additionally LVM commands may complain about the missing PVs:

# vgdisplay vg01
vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c0t11d0":
The specified path does not correspond to physical volume attached to this volume group
vgdisplay: Couldn't query the list of physical volumes.
--- Volume groups ---
VG Name /dev/vg01
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 3
Open LV 3
Max PV 16
Cur PV 2 (number of PVs recorded in the lvmtab)
Act PV 1 (number of PVs recorded in the kernel)
Max PE per PV 1016
VGDA 2
PE Size (Mbytes) 4
Total PE 511
Alloc PE 38
Free PE 473
Total PVG 0


Running vgreduce with the -f option would remove all PVs that are “free”, i.e there is no LV having extents on that PV. Otherwise - if the PV is not free - vgreduce -f reports an extent map to identify the associated LVs:

# vgreduce -f vg01

 skip alternate link /dev/dsk/c1t2d2 vgreduce: Couldn't query physical volume "/dev/dsk/c0t11d0": The specified path does not correspond to physical volume attached to this volume group Not all extents are free. i.e. Out of 508 PEs, only 500 are free.

 You must free all PEs using lvreduce/lvremove before the PV can be removed.

 Example:
 lvreduce -A n -m 0 /dev/vg01/lvol1. lvremove -A n /dev/vg01/lvol1. 
Here's the map of used Pes
--- Logical extents ---
 LE LV PE Status 
1 0000 lvol1 0000 ??? 0001 lvol1 0001 ??? 0002 lvol1 0002 ??? ...
In this case lvol1 is having extents on device c0t11d0. You have to remove these extents from the PV before you are allowed to actually remove the PV from the VG. If the LV is mirrored use the command lvreduce to remove its mirrored extents. If the LV is unmirrored, data is lost anyway and you have to use lvremove to delete the LV.

Check the LV state:
# lvdisplay -v /dev/vg01/lvol1

lvdisplay: Warning: couldn't query physical volume "/dev/dsk/c0t11d0":The specified path does not correspond to physical volume attached to this volume group lvdisplay: Couldn't query the list of physical volumes.

--- Logical volumes ---
LV Name /dev/vg01/lvol1
VG Name /dev/vg01
LV Permission read/write
LV Status available/stale
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 32
Current LE 8
Allocated PE 16
HP-UX Handbook – Rev 13.00 Page 64 (of 110)
Chapter 13 LVM
October 29, 2013
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict IO Timeout (Seconds) default
--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c0t0d2 8 8

--- Logical extents ---
LE PV1 PE1 Status 1 PV2 PE2 Status 2
00000 ??? 00000 stale /dev/dsk/c0t0d2 00000 current
00001 ??? 00001 stale /dev/dsk/c0t0d2 00001 current
00002 ??? 00002 stale /dev/dsk/c0t0d2 00002 current
00003 ??? 00003 stale /dev/dsk/c0t0d2 00003 current
00004 ??? 00004 stale /dev/dsk/c0t0d2 00004 current
00005 ??? 00005 stale /dev/dsk/c0t0d2 00005 current
00006 ??? 00006 stale /dev/dsk/c0t0d2 00006 current
00007 ??? 00007 stale /dev/dsk/c0t0d2 00007 current

The PV key of a disk indicates its order in the VG. The first PV has the key 0, the second has the key 1, etc. This does not necessarily have to be the order of appearance in lvmtab altough it is usually like that, at least when a VG is initially created.
The PV key can be used to address a PV that is not attached to the VG. This usually happens if it was not accessible during activation, e.g. due to a hardware or configuration problem.

NOTE: The PV may be unattached due to some temporary problem during VG activation which is no longer present. In this case you should try to re-activate the VG to force LVM to re-scan the devices listed in lvmtab: In this example you can see, that the LV in question is mirrored. One of its PVs is not attached to the VG, so its device file is unknown to LVM and displayed as “???”. Addressing this PV is no longer possible using the device file name. Removing a PV using its PV key

# vgchange -a y vgXX or # vgchange -a e vgXX (for exclusively activated Cluster VGs)

If the problem persists follow these steps to clear the situation:


1. Obtain the PV key using the -k option of lvdisplay: 

# lvdisplay –v –k /dev/vg01/lvol1 ... ...

--- Logical extents ---
LE PV1 PE1 Status 1 PV2 PE2 Status 2
00000 0 00000 stale 1 00000 current
00001 0 00001 stale 1 00001 current
00002 0 00002 stale 1 00002 current
00003 0 00003 stale 1 00003 current
00004 0 00004 stale 1 00004 current
00005 0 00005 stale 1 00005 current
00006 0 00006 stale 1 00006 current
00007 0 00007 stale 1 00007 current

Compared to the output above the ??? have been replaced with the PV key (= 0).

NOTE: You can use the xd(1) command to display the PV key because it is stored at a fixed position in the LVM header, exactly 8222 bytes from the beginning of the disk:
# xd –j8222 -N2 /dev/rdsk/c1t6d0


2. Reduce the mirror with the obtained key as argument: # lvreduce –k –m 0 /dev/vg01/lvol1 0

3. After that the PV can be removed from the VG:

# vgreduce -f vg01
vgreduce: Couldn't query physical volume "/dev/dsk/c0t11d0":
The specified path does not correspond to physical volume attached to this volume group PV with key 0 sucessfully deleted from vg vg01 Repair done, please do the following steps.....:
1. save /etc/lvmtab to another file
2. remove /etc/lvmtab
3. use vgscan(1m) -v to re-create /etc/lvmtab
4. Perform the above steps indicated above in order to remove the PV from the lvmtab:
# mv /etc/lvmtab /etc/lvmtab.org
# vgscan –v
...
...
Scan of Physical Volumes Complete.
*** LVMTAB has been created successfully.
*** If PV links are configured in the system.
*** Do the following to resync information on disk.
*** #1. vgchange -a y
*** #2. lvlnboot -R

5. Check the results: # strings /etc/lvmtab /dev/vg01 /dev/dsk/c0t0d2 /dev/dsk/c1t2d2

6. Re-activate the VG and backup the LVM config: # vgchange -a y vg01 # vgcfgbackup vg01

vxvmconvert Failed to Convert from LVM to VxVM


ISSUE:

During a convert from LVM for non-vg00 volume to VxVM with vxvmconvert, the analysis failed with the following error message:

" Device device_name has the following bad blocks: [1] bad block number (PE# n data block bnum) alternate number Cannot convert LVM Volume Group, vgXX "

SOLUTION:

Description:
Unlike LVM, VxVM does not support bad block revectoring at the physical volume level. If there appear to be any valid bad blocks in the bad block directory of any disk used in an LVM volume group, the group cannot be converted.

Action:
You have the following choices:
Place a hardware call to have the disk replaced or have the hardware engineer use the diagnostics (if applicable for this disk type) to re-vector the block. Then clear the BBDIR as described below.

If the errors were transient, or after the disk has been replaced, clear the BBDIR as follows:

Step 1. Back up all the data associated with the physical volume.

Step 2. Make a current backup of the LVM headers, for example:
# vgcfgbackup /dev/vg01

Step 3. Close all the logical volumes associated with the volume group and then deactivate the volume group.
# vgchange -a n /dev/vg01

Step 4. Create a dummy link to the raw device, for example:
# ln /dev/rdsk/c0t0d0 /dev/rdsk/temp

Step 5. Destroy the LVM headers using pvcreate -f on the dummy link, For example:
# pvcreate -f /dev/rdsk/temp

Step 6. Remove the dummy link to the raw device
# rm /dev/rdsk/temp

Step 7. Restore the headers from the lvmconf backup
# vgcfgrestore -n /dev/vg01 /dev/rdsk/c0t0d0

Step 8. Activate the volume group and integrity check the data or recover from backup.
# vgchange -a y /dev/vg01

Now, use vxvmconvert again to analyze the conversion from LVM to VxVM

HP-UX 11i - Instant Capacity: icapmodify Fails to Add Cores to a vPar on a GiCap


Issue
A GiCap group is present with all the required sharing rights and members already configured and have previously been able to activate and deactivate cores from any member of the group; however, now trying to add two additional cores to one of the virtual partitions (vPar) and getting the following error:

# icapmodify -a 2

ERROR: 2 cores are required to fulfill this request.
Only 0 cores are available.

ERROR: Unable to satisfy the request. 3 cores are still active in
this virtual partition.

Solution
According to the vparstatus output below, the maximum and minimum number of cores that can be assigned to the vpar in question named vpar1 are 1 and 3 respectively. In addition, the number of cores currently assigned to the same vpar is 3; therefore, it has reached its maximum number of cores.

# vparstatus
[Virtual Partition]
Boot
Virtual Partition Name State Attributes Kernel Path Opts
====================== ===== ========== ======================= =====
vpar1                   Down Dyn,Manl,Nsr /stand/vmunix
vpar2                   Down Dyn,Manl,Nsr /stand/vmunix
[Virtual Partition Resource Summary]

CPU Num Num Memory Granularity
Virtual Partition Name Min/Max CPUs IO ILM CLM
============================== ======= ==== ==== ==========
vpar1                   1/ 3    3    3 1024 1024
vpar2                   1/ 4    1    3 1024 1024
...

If additional cores need to be assigned to a vpar that has already reached it maximum number of cores, this limit needs to be increased at least by the number of cores we need to add. For example, if two additional cores are going to be assigned to vpar1 above, the max number of cores needs to be set to 5. This can be acomplished by running:

# vparmodify -p vpar1 -m cpu:::1:5

After this change was applied to the target vpar, the icapmodify command succeeded in assigning the two additional cores.

Where are MC/ServiceGuard Network events logged?


RESOLUTION
MC/ServiceGuard Network events are logged in /var/adm/syslog/sylog.log

Here are some examples of these events being logged:
Feb 11 08:10:18 tom cmcld: lan0 failed
Feb 11 08:10:18 tom cmcld: Subnet 15.37.246.0 down
Feb 11 08:10:20 tom cmcld: lan0 recovered
Feb 11 08:10:20 tom cmcld: Subnet 15.37.246.0 up

Please note that the Network drivers may log lower level Network events in the nettl log file. Most of the events are self-explanatory. By default the nettl log file is /var/adm/nettl.LOG00 with older events logged in /var/adm/nettl.LOG01.

You can format the log file with the command:

/usr/sbin/netfmt –f /var/adm/nettl.LOG00 > /tmp/log00

vgextend Fails with "Verification of unique LVM disk id on each disk in the volume group failed" HP_UX

vgextend Fails with "Verification of unique LVM disk id on each disk in the volume group failed" HP_UX 


ISSUE:
I created a volume group using persistent device files, but I cannot vgextend the alternate links into the volume group. The following error message is received:

# vgextend /dev/vg02 /dev/dsk/c8t0d5 /dev/dsk/c8t0d6 /dev/dsk/c8t0d7 /dev/dsk/c8t1d0

Verification of unique LVM disk id on each disk in the volume group /dev/vg02 failed.

Following are the sets of disks having identical LVM disk id
/dev/dsk/c6t0d5 /dev/dsk/c8t0d5
/dev/dsk/c6t0d6 /dev/dsk/c8t0d6
/dev/dsk/c6t0d7 /dev/dsk/c8t0d7

/dev/dsk/c6t1d0 /dev/dsk/c8t1d0

SOLUTION:

Investigation of the error identified that the error message was due to a the version of firmware on the array.

To check the firmware version, issue the following command:


# scsimgr -v get_info -D /dev/pt/

Check for:
SPC protocol revision = 4 .

If the revision is 2, the DMX SPC needs to have a firmware upgrade.


After upgrading the firmware (requires EMC assistance), the problem was resolved.

IF ONE ROOT DISK GO BAD (FAULTY) --Hp-UX

IF ONE ROOT DISK GO BAD (FAULTY)

1.     Recognizing a Failing Disk

I/O Errors in the System Log
Often an error message in the system log file is your first indication of a disk problem.                  

In /var/adm/syslog/syslog.log, you might see the following error:


SCSI: Request Timeout -- lbolt: 329741615, dev:     1f022000

 

To map this error message to a specific disk, look under the /dev directory for a device file with a device number that matches the  printed value(022000). search for a file whose minor number matches the lower six digits of the number following dev  

#  ll /dev/*dsk | grep 022000


brw-r----- 1 bin      sys      31       0x022000     Sep     22       2002         c2t2d0
crw-r----- 1   bin      sys      188     0x022000     Sep     25       2002               c2t2d0
NOTE :- This gives you a device file(specific disk) to use for further investigation.

Confirming Disk Failure

Three-step approach to confirm that a disk has failed or is failing:
STEP 1 : Checking ioscan output
       Use the ioscan command to check the S/W state of the disk. Only disks in state    CLAIMED are currently accessible by the system. Disks in other states such as NO_HW or disks that are completely missing from the ioscan output are suspicious. If the disk is marked as CLAIMED, then its controller is responding. For example:
# ioscan –fC disk  or # ioscan –fnC disk
Class I H/W Path Driver S/W State H/W Type Description
===================================================================
disk 0 8/4.5.0 sdisk CLAIMED DEVICE SEAGATE ST34572WC
disk 1 8/4.8.0 sdisk UNCLAIMED UNKNOWN SEAGATE ST34572WC
disk 2 8/16/5.2.0 sdisk CLAIMED DEVICE TOSHIBA CD-ROM XM-5401TA
In this example the disk at hardware path 8/4.8.0 is not accessible.
If the disk has multiple hardware paths, be sure to check all the paths.
STEP 2 :   Checking disk status in diskinfo
       If the disk responds to the ioscan command, test it with the diskinfo command. The reported size must be nonzero, otherwise the device is not ready. For example:
# diskinfo /dev/rdsk/c0t5d0
SCSI describe of /dev/rdsk/c0t5d0:
vendor: SEAGATE
product id: ST34572WC

type: direct access

size: 0 Kbytes
bytes per sector: 512
In this example the size is 0, so the disk is malfunctioning.


STEP 3:    Testing the disk “dd” command
        If both ioscan and diskinfo succeed, the disk might still be failing. As a final test, try to read from the disk using the dd command. Depending on the size of the disk, a comprehensive read can be time-consuming, so you might want to read only a portion of the disk. If the disk is functioning properly, no I/O errors are reported.

For example, the following shows a successful read of the first 64 megabytes of the disk:

# dd if=/dev/rdsk/c0t5d0 of=/dev/null bs=1024k count=64

64+0 records in
64+0 records out

The following shows an unsuccessful read of the whole disk:


# dd if=/dev/rdsk/c1t3d0 of=/dev/null bs=1024k

dd read error: I/O error
0+0 records in 0+0 records out
 2.          REPLACING FAULTY DISK


# pvchange –a N

Stop the LVM to access secondary disk and remove it.
For example (output):

# pvchange -a N /dev/dsk/c14t0d0s2

Warning: Detaching a physical volume reduces the availability of data
within the logical volumes residing on that disk.
Prior to detaching a physical volume or the last available path to it,
verify that there are alternate copies of the data
available on other disks in the volume group.
If necessary, use pvchange(1M) to reverse this operation.
Physical volume "/dev/dsk/c14t0d0s2" has been successfully changed.

Check vg status--- (disk should show unavailable)

#vgdisplay –v

--- Physical volumes ---
   PV Name                /dev/dsk/c6t0d0s2
   PV Status              available                
   Total PE               4346   
   Free PE                1901   
   Autoswitch             On       
   Proactive Polling      On              

   PV Name                /dev/dsk/c14t0d0s2

   PV Status            unavailable   Search for this information in output.

   Total PE               4346   
   Free PE                1901   
   Autoswitch             On       
   Proactive Polling      On


Then remove the secondary disk and insert the new disk.


Use vi to create a partition description file by doing the following:

# vi /tmp/partitionfile

The 4 line entry for 11.23 and 11.31 should look like this:

3
EFI 500MB
HPUX 100%
HPSP 400MB

Use idisk to setup the disk partitioning using the file created above:

# idisk -wf /tmp/partitionfile /dev/rdsk/cXtXdX   è New devicefile


NOTE: There will be a prompt with a message saying the operation may be destructive and asks to continue. Be sure to answer 'yes' for the operation to be successful. If the prompt is answered with 'y' only, an error is received along with a message saying "user aborting".

 

For example (output):

# idisk /dev/rdsk/c14t0d0

idisk version: 1.32
idisk: Primary partition information not valid.
Run idisk with -r option to restore.
# idisk -wf /tmp/partitionfile /dev/rdsk/c14t0d0
idisk version: 1.32
********************** WARNING ***********************
If you continue you may destroy all data on this disk.
Do you wish to continue(yes/no)? yes

EFI Primary Header:
        Signature                 = EFI PART
        Revision                  = 0x10000
        HeaderSize                = 0x5c
        HeaderCRC32               = 0xdcef25a5
        MyLbaLo                   = 0x1
        MyLbaHi                   = 0x0
        AlternateLbaLo            = 0x1117732f
        AlternateLbaHi            = 0x0
        FirstUsableLbaLo          = 0x22
        FirstUsableLbaHi          = 0x0
        LastUsableLbaLo           = 0x1117730c
        LastUsableLbaHi           = 0x0
        Disk GUID                 = f1c3328e-4381-11e1-8001-d6217b60e588
        PartitionEntryLbaLo       = 0x2
        PartitionEntryLbaHi       = 0x0
        NumberOfPartitionEntries  = 0xc
        SizeOfPartitionEntry      = 0x80
        PartitionEntryArrayCRC32  = 0x658ec26d
Use insf to create the new device dfiles (cXtXdXs1, cXtXdX2 and cXtXdXs3)

# insf -e

Use mkboot to format and populate the newly created EFI partition:


# mkboot -e -l /dev/dsk/cXtXdX


Only when we are installing/changing disk in npar.


# mkboot -a "boot vmunix" /dev/rdsk/c2t0d0             only for npar systems


Only when we are installing/changing disk in vpar.
Change the auto file for the mirror to boot vpmon and verify the AUTO file:


# mkboot -a "boot vpmon -a" /dev/rdisk/ cXtXdX         only for vpar systems

Use standard LVM commands to restore the mirror information. Be careful to specify the s2 device file (cXtXdXs2) when performing LVM command.

# pvchange -a n /dev/dsk/cXtXdXs2


# vgcfgrestore -n vg00 /dev/rdsk/cXtXdXs2.

For example (output):

# vgcfgrestore -n vg00 /dev/rdsk/c14t0d0s2
Volume Group configuration has been restored to /dev/rdsk/c14t0d0s2


# pvchange -a y /dev/dsk/cXtXdXs2

For example (output):

# pvchange -a y /dev/dsk/c14t0d0s2
Physical volume "/dev/dsk/c14t0d0s2" has been successfully changed.


# vgchange -a y vg00

For example (output):


# vgchange -a y vg00
Volume group "vg00" has been successfully changed.
# vgsync vg00

# lvlnboot -r /dev/vg00/lvol3 /dev/vg00

# lvlnboot -b /dev/vg00/lvol1 /dev/vg00

# lvlnboot -s /dev/vg00/lvol2 /dev/vg00

# lvlnboot -d /dev/vg00/lvol2 /dev/vg00

# lvlnboot -v (to verify the results)

# vgdisplay -v/dev/vgxx (to verify the results)

Update and verify the EFI maps for each vPar:


#vparefiutil -u  
                           
Only for vpar
#vparefiutil