vmunix

[Tom Spence_1]

Hi guys,

I read from syslog.log and wasn't sure if it is okay or not? Here is:

Sep 11 09:41:31 vmunix: LVM: PV 0 has been returned to vg[0].
Sep 11 09:41:31 vmunix: LVM: PV 1 has been returned to vg[0].

Thanks.

[unixdaddy]

It seems that two of your disks in vg00 have had a problem, but have recovered. I'd checck to see if these messages are one off's in the syslog or whether they are repeated. If they are repeated then you may have disk problem otherwise keep an eye on it. Is the system mirrored and do you have some good backups, you may need them.

[Tom Spence_1]

Yeah thought so cuz I had to reboot after it hangs! No, system mirrored. Yes I do have a good backups. Ok, I have about 10 unused hard drives. So if I copy from vg00 to vgxx then how can I set up the server for read at vgxx as boot up?

Thanks!
Tom

[Paula J Frazer-Campbell]

Hi

Man mkboot is what I believe you require.

Paula

[Paula J Frazer-Campbell · Accepted solution]

Hi

This may help :-


1 mkboot /dev/rdsk/xyz

2 mkboot -a "hpux (;0) /stand/vmunix" /dev/rdsk/xyz

-a auto_file_string If the -a option is specified, mkboot
creates an autoexecute file AUTO on
device, if none exists. mkboot deposits
auto_file_string in that file. If this
string contains spaces, it must be quoted
so that it is a single parameter.

or use

3 mkboot -a "hpux -lq /stand/vmunix" /dev/rdsk/xyz



Paula

[unixdaddy]

Ensure you have a copy of your LVM/filesystem configuration. if the machine is see the attached document. If the machine isn't up you'll need to replace the disk do a minimal install, recreate LVM/Configuration and restore. Let me know if you need any more info.

[unixdaddy]

Also use the setboot command to get it to boot from the new disk at boot time.

[Cheryl Griffin]

PV 0 means the first disk in the volume group, of vg[0] which is vg00. PV 1 is the second disk.

If the messages include a hex such as dev_t=0x1f07c400, you can interpret this to a device by:
# ll /dev/dsk |grep 07c400
which is the minor number, 0x1f is the major number which should be 31 and correlates to the disk driver in the kernel (# lsdev 31)

The messages do not necessarily mean that you have a bad disk.

If this is a 11.00 system check for the scsi patch PHKL_18543; 10.20 systems it was PHKL_16751.
# check_patches (for 11.00)
# swlist -l fileset -a state |grep 18543
or
# swlist -l fileset -a state |grep 16751

If the disks are in an array, you need to check the timeout with pvdisplay. If the timeout says default, increase it to 180-300. This gives more time for the array to move the data around, helps with I/O.
# pvchange -t 300 /dev/dsk/c0t0d0

If the device has 2 controllers, you might consider spreading the load between the controllers to balance the I/O.

You can test the disk with dd to help determine if this is actual a HW error.
# dd if=/dev/dsk/cXdXtX of=/dev/null bs=1024
HW problems: Look for IO errors, the number of blocks read in do not match was is read out, the command hangs or immediately produces an error. This command may take awhile depending on the size disk. For really large disks, you may want to skip this check in lieu of using STM (Diagnostics).

Cheryl

[Tom Spence_1]

Hi Cheryl Griffin,

Glad to have you... Okay, I read what you want me to do by following your instruction...

PV 0 means the first disk in the volume group, of vg[0] which is vg00. PV 1 is the second disk.

> Okay I understand...

If the messages include a hex such as dev_t=0x1f07c400, you can interpret this to a device by:
# ll /dev/dsk |grep 07c400
which is the minor number, 0x1f is the major number which should be 31 and correlates to the disk driver in the kernel (# lsdev 31)

> I looked at syslog.log and it said (look not too good):
Sep 18 06:50:29 burns vmunix: Error writing VGDA [1] to disk H/W path 4.6.0 (err
or = 5)
Sep 18 06:50:29 burns vmunix: LVM: vg[10]: pvnum=0 (dev_t=0x1c006000) is MISSING
Sep 18 06:50:29 burns vmunix: LVM: Lost quorum in vg[10], too many PVs missing!

The messages do not necessarily mean that you have a bad disk.

> Good! Save my neck!

If this is a 11.00 system check for the scsi patch PHKL_18543; 10.20 systems it was PHKL_16751.
# check_patches (for 11.00)
# swlist -l fileset -a state |grep 18543
or
# swlist -l fileset -a state |grep 16751

> I am using 10.20. Don't see scsi patch (PHKL_16751) by using swlist command

If the disks are in an array, you need to check the timeout with pvdisplay. If the timeout says default, increase it to 180-300. This gives more time for the array to move the data around, helps with I/O.
# pvchange -t 300 /dev/dsk/c0t0d0

> Yes it is default... I'll change from default to 300

If the device has 2 controllers, you might consider spreading the load between the controllers to balance the I/O.

> It hasn't 2 controllers! Whew!

You can test the disk with dd to help determine if this is actual a HW error.
# dd if=/dev/dsk/cXdXtX of=/dev/null bs=1024
HW problems: Look for IO errors, the number of blocks read in do not match was is read out, the command hangs or immediately produces an error. This command may take awhile depending on the size disk. For really large disks, you may want to skip this check in lieu of using STM (Diagnostics).

> I'll do that later after you reply to see if I need to fix something...

Thank you soooo much.

Tom