Hi all,

  we are running some tests with oracle RAC.  we have 4 nodes (v40z's
with S10U1) that are sharing two storage devices with fully redundant
paths (2 HBAs, 2 FC switches, 2 3510s).  As part of the tests we need to
inject faults one of the switches (powercycle).  The 3510's contain only
oracle related data.  When the switch comes back up oracle instructs the
nodes to reboot.  The problem we have is that only one nodes comes up. 
The other 3 nodes give me this msg in the console and refuse to boot.  I
tried the suggested fix (svcadm clear system/boot-archive) which didn't
work.  We have no idea how to

a) avoid this problem,
b) fix it. 

Have you seen this before?  any advise?  why is it happening?  is ti a bug?

 thanks in advance for any help,

  Fernando

WARNING - The following files in / differ from the boot archive:
    /etc/path_to_inst
    /etc/devices/devid_cache
The recommended action is to reboot and select "Solaris failsafe"
option from the boot menu. Then follow prompts to update the
boot archive.
To continue booting at your own risk, clear the service:
# svcadm clear system/boot-archive

Feb 14 16:39:20 svc.startd[7]: svc:/system/boot-archive:default: Method
"/lib/svc/method/boot-archive" failed with exit status 95.
[ system/boot-archive:default failed fatally (see 'svcs -x' for details) ]
Requesting System Maintenance Mode
(See /lib/svc/share/README for more information.)
Console login service(s) cannot run

Root password for system maintenance (control-d to bypass): Hostname:
clear20


-- 
<http://www.sun.com>    * Fernando Castano *
Staff engineer, MDE

*Sun Microsystems, Inc.*
260 Constitution Drive
Menlo Park, CA 94025 US
Phone x88904/+1 650 786 8904
Email

-- 
<http://www.sun.com>    * Fernando Castano *
Staff engineer, MDE

*Sun Microsystems, Inc.*
260 Constitution Drive
Menlo Park, CA 94025 US
Phone x88904/+1 650 786 8904
Email Fernando.Castano at Sun.COM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20060214/9b03f075/attachment.html>

Reply via email to