cancel
Showing results for 
Search instead for 
Did you mean: 

Server stays for hours during boot when waiting for Veritas

Manfred_Ratzke
Level 4
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 ??
1 ACCEPTED SOLUTION

Accepted Solutions

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
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.

View solution in original post

7 REPLIES 7

Gaurav_S
Moderator
Moderator
   VIP    Certified
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
Level 4
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
Level 5
Employee
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
Level 4
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
Moderator
Moderator
Partner    VIP    Accredited Certified
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
Moderator
Moderator
   VIP    Certified

I agree with boot -v, will be good to see where exactly is getting stuck....

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
Experience had taught us that 'Veritas' is waiting for the devices, not the O/S 'waiting for Veritas'...