Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-1575239.1
Update Date:2018-04-20
Keywords:

Solution Type  Problem Resolution Sure

Solution  1575239.1 :   Exachk Reports "FAIL Storage Server Check One or more Exadata storage server does not meet system model number requirement"  


Related Items
  • Exadata X5-2 Eighth Rack
  •  
  • Exadata X3-2 Hardware
  •  
Related Categories
  • PLA-Support>Eng Systems>Exadata/ODA/SSC>Oracle Exadata>DB: Exadata_EST
  •  




Applies to:

Exadata X3-2 Hardware - Version All Versions to All Versions [Release All Releases]
Exadata X5-2 Eighth Rack
Information in this document applies to any platform.

Symptoms

Exachk reports the error below, even though the make and model number is identical with others systems in the same rack.

Example:

"FAIL Storage Server Check One or more Exadata storage server does not meet system model number requirement Node_Name"

Running the /SP system_description output for this node, we see:

-> show /SP system_description

/SP

Properties:

system_description = SUN FIRE X4270 M3, ILOM v3.1.2.12, r74388

However, all the other X3-2L nodes in the same rack (which have a status of PASS) appear to have the exact same output:

 

-> show /SP system_description


/SP

Properties:

system_description = SUN FIRE X4270 M3, ILOM v3.1.2.12, r74388

 

Cause

This is not an Exacheck issue.  The root cause has been attributed to the response from the ILOM on certain commands outputs which are either incorrectly formatted, or timed out during the logic pass.

During the reporting pass, the ILOM manages to respond with something that makes sense or before a timeout, so we see the correct data in the report.

 

Solution

You can re-execute either the specific command as described in the "view" section of the exachck, or re-run exachk.

-> reset /SP -script
-> show /SP system_description

 

If issue persists, reset the ILOM on the affected Node.  Then rerun exachk or the ilom command.

If the manual command and/or the subsequent exachk output validates that there is no issue, then you can ignore the "false" result.

 


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback