Forum Discussion

Manfred_Ratzke's avatar
Manfred_Ratzke
Level 4
15 years ago
Solved

Server stays for hours during boot when waiting for Veritas

Veritas did found troubles with a SAN T3 so it did close its connection to the T3. Now during boot we have issues that the server will NOT boot if we not send a control-c at steps during boot process 1.) when it comes to VxVM starting special volumes (swapvol roolvol var site) Configuring /dev and /devices VxVM general startup --> at this position it stays for hours and not coming back I only can do a control-c buth then it does not find all SAN T3 connections later on... what could this be ? at the end of our investigation we think it is maybe a possibility to rebuilt/restore the Veritas DB ??
business continuity
Configuring
Error messages
Storage Foundation
  • Marianne's avatar
    Marianne
    15 years ago
    Have you had a look at /var/adm/messages yet?
    Disk and/or path errors will be logged there.

    probe-scsi-all is a good idea - not to 'get clean paths' but to validate and check connectivity.
    After probe-scsi-all, boot as follows:
    boot -rv

    The verbose boot will show exactly how devices are being scanned during boot and you will be able to see where it gets stuck.

7 Replies

  • Gaurav_S's avatar
    Gaurav_S
    Moderator
    15 years ago
    what is version of OS ?

    have u tried un-encapsulating disk & boot the server  ?  need to diagnose if its just encapsulation (private region issue) or something else...

    Gaurav
  • Manfred_Ratzke's avatar
    Manfred_Ratzke
    Level 4
    15 years ago
    Version is Solaris 8 , and no I have not tried to un-encapsulate the disk.

    In the meantime we can boot the machine but Veritas still has issues in finding all pathnames or let me say in working correctly.

    After a boot I see just:
      root   132     1  0 18:11:55 ?        0:03 vxconfigd -k
        root   282     1  0 09:48:47 ?        0:02 /opt/VRTSob/bin/vxsvc -r /opt/VRTSob/config/Registry
        root  4953  4567  0 14:16:58 pts/2    0:00 grep vx
  • ScottK's avatar
    ScottK
    Level 5
    15 years ago
    What VxVM version do you have?
    Old versions of VxVM would spend substantial time checking each ASL/APM to see if it was connected to an array (but minutes, not hours).
    This was fixed in a more recent version (5.0MP3 perhaps?). Prior versions can be tuned by removing ASLs you aren't using.
  • Manfred_Ratzke's avatar
    Manfred_Ratzke
    Level 4
    15 years ago
    we are using VxVM 3.5, all others are already on V5 , but this one is 3.5 with Solaris 8

    The only other idea I had is to bring it down in single user mode and do a probe-scsi-all to get clean scsi pathes maybe that would help ??
  • Marianne's avatar
    Marianne
    Level 6
    15 years ago
    Have you had a look at /var/adm/messages yet?
    Disk and/or path errors will be logged there.

    probe-scsi-all is a good idea - not to 'get clean paths' but to validate and check connectivity.
    After probe-scsi-all, boot as follows:
    boot -rv

    The verbose boot will show exactly how devices are being scanned during boot and you will be able to see where it gets stuck.
  • Gaurav_S's avatar
    Gaurav_S
    Moderator
    15 years ago

    I agree with boot -v, will be good to see where exactly is getting stuck....
  • Marianne's avatar
    Marianne
    Level 6
    15 years ago
    Experience had taught us that 'Veritas' is waiting for the devices, not the O/S 'waiting for Veritas'...