Logs

[John Forbes_3]

Just want to know other interpretations on the posted syslog.log entries below.

Thanks
John

Nov 24 01:45:13 online vmunix: WARNING: Logical volume for Dump expected but not found.
Nov 24 01:45:13 online vmunix: Swap device table: (start & size given in 512-byte blocks)
Nov 24 01:45:13 online vmunix: entry 0 - major is 64, minor is 0x2; start = 0, size = 2097152
Nov 24 01:45:13 online vmunix: Defaulting dump to primary swap
Nov 24 01:45:13 online vmunix: WARNING: Could not find HPA for dump device 0xffffffff
Nov 24 01:45:13 online vmunix: WARNING: Could not use primary swap for dump. Dump is disabled.
Nov 24 01:45:13 online vmunix: netisr real-time priority reset to 100

[Sridhar Bhaskarla]

Hi John,

Post your 'lvlnboot -v' output. Looks like you have configured a seperate dump logical volume that is not available anymore. It tried to default to primary swap but couldn't as it might not be configured for dump in the BDRA. BDRA defines the root,boot, swap and dump volumes. For ex., lvol1 for boot, lvol3 for root, lvol2 for primary swap (and usually as dump).

Your 'lvlnboot -v' should clear the things up.

-Sri

[John Forbes_3]

Hi Sri,
Here's the output.

online:/# lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c4t6d0 (10/0.6.0) -- Boot Disk
/dev/dsk/c4t5d0 (10/0.5.0)
/dev/dsk/c7t6d0 (10/8.6.0) -- Boot Disk
/dev/dsk/c7t5d0 (10/8.5.0)
/dev/dsk/c4t4d0 (10/0.4.0)
/dev/dsk/c4t3d0 (10/0.3.0)
/dev/dsk/c7t4d0 (10/8.4.0)
/dev/dsk/c7t3d0 (10/8.3.0)
Boot: lvol1 on: /dev/dsk/c4t6d0
/dev/dsk/c7t6d0
Root: lvol3 on: /dev/dsk/c4t6d0
/dev/dsk/c7t6d0
Swap: lvol2 on: /dev/dsk/c4t6d0
/dev/dsk/c7t6d0
Dump: lvol2 on: /dev/dsk/c4t6d0, 0

[Sridhar Bhaskarla]

Hi,

Wow.. you have got a big vg00 (atleast with many disks).

Did you boot from the alternate path (10/8.6.0) now than original?. If so, run 'lvlnboot -d /dev/vg00/lvol2' and it should take care of it. Since dump is not mirrored, booting from alternate path might have resulted in this warning. You can confirm the dump configuration using 'crashconf' command.

Otherwise, look at /dev/dsk/c4t6d0 and see if there are any errors. 'pvdisplay /dev/dsk/c4t6d0' shouldn't show any 'stale' entries. To confirm the issues do 'dd if=/dev/rdsk/c4t6d0 of=/dev/null bs=1024k' and it shouldn't give any errors.

-Sri

[Steven E. Protter]

Thats a lot of disks in vg00. I'd be interested in seeing a bdf output to see if the filesystmes are sized reasonably.

As a general rule its not a good idea to put a lof of non-boot data and applications in vg00. Its best to seperate those. The reason is you can back up your system with make_tape_recovery

This utility is very good at copying boot configuration and giving you a bootable tape. Its not very good at, as in it can't back up open database files and such. Its a waste of processing time to do that. Other tools should be used and non-boot data really should be in another volume group.

It appears that you set up separate swap and dump files and now due to the missing dump file the system is defaulting to swap.

You actually don't need a seperate swap and dump file.

Based on your lvlnboot -v configuration I agree with the prior analysis provided to this point with regards to configuration.

It would be interesting to see the top part of pvdisplay -v on the disks in the boot configuration.

If Sri is right there may be stale extents caused by the alternate boot, or the failure of a disk. That may have triggered this issue as can a rezoning of any fiber switches between you and your disks.

SEP

[John Forbes_3]

Hi Sri,
I haven't run the lvlnboot -d /dev/vg00/lvol2' command cause there are alot of users currently connected in this server. Would it trigger a reboot? If not, I'll run it anyway. I'll just wait for your advise.

Thanks

Hi SEP,
Below is the output. Thanks.

online:/# pvdisplay /dev/dsk/c4t6d0
--- Physical volumes ---
PV Name /dev/dsk/c4t6d0
VG Name /dev/vg00
PV Status available
Allocatable yes
VGDA 2
Cur LV 7
PE Size (Mbytes) 4
Total PE 1023
Free PE 0
Allocated PE 1023
Stale PE 0


online:/# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 409600 197346 199161 50% /
/dev/vg00/lvol1 199381 22802 156640 13% /stand
/dev/vg00/lvol8 819200 442209 353687 56% /var
/dev/vg00/crash 4186112 299739 3643522 8% /var/adm/crash
/dev/vg00/lvol7 819200 433730 361419 55% /usr
/dev/vg00/lvol6 638976 123706 485087 20% /tmp
/dev/vg00/bscs 1024000 712850 291735 71% /oracle8
/dev/vg00/oracle 2560000 1500314 993516 60% /oracle
/dev/vg00/lvol5 819200 564686 238662 70% /opt
/dev/vg00/lvol4 2058240 659956 1311705 33% /home
/dev/vgbillimage/bimage
26492928 8833281 16589743 35% /billimage
/dev/vgbscs/dbs1 8716288 7650990 1005015 88% /dbs1
/dev/vgbscs/dbs2 7733248 7192872 506652 93% /dbs2
/dev/vgbscs/dbs3 7733248 7649309 80166 99% /dbs3
/dev/vgbscs/lvol1 20480000 1335401 17948320 7% /bscs_db_backup
/dev/vgbscs/lvol2 14860288 2932030 11182825 21% /ora_arch_bscs
/dev/vgbscs/dbs4 20635648 20349290 268525 99% /dbs4
/dev/vgbscs/lvol3 20480000 16988283 3291509 84% /dbs5
/dev/vgbscs/dbs6 20480000 18651009 1714741 92% /dbs6

[Elmar P. Kolkman]

lvlnboot will not reboot the system.

And having oracle on vg00 is NOT a good idea. But moving it now can be troublesome. And it seems you only have the software on vg00, not the data.
Just let a make_tape_recovery ignore the oracle directories and backup those seperately. The same holds for, for instance, /var/adm/crash: who wants that on an ignite tape anyway...