Asset ID: |
1-71-1006214.1 |
Update Date: | 2018-01-17 |
Keywords: | |
Solution Type
Technical Instruction Sure
Solution
1006214.1
:
Sun Fire[TM] 12K/15K/E20K/E25K Servers: How to Replace a System Board Using Dynamic Reconfiguration
Related Items |
- Sun Fire 15K Server
- Sun Fire E20K Server
- Sun Fire E25K Server
- Sun Fire 12K Server
|
Related Categories |
- PLA-Support>Sun Systems>SPARC>Enterprise>SN-SPARC: SF-Exxk
- _Old GCS Categories>Sun Microsystems>Servers>High-End Servers
|
PreviouslyPublishedAs
208696
Applies to:
Sun Fire E25K Server - Version All Versions and later
Sun Fire 12K Server - Version All Versions and later
Sun Fire 15K Server - Version All Versions and later
Sun Fire E20K Server - Version All Versions and later
Sun SPARC Sun OS
***Checked for relevance on 15-Jan-2014***
Goal
This document provides methods for replacing system boards on a running domain:
- Method 1 utilizes the deleteboard and addboard commands on the System Controller.
- Method 2 uses the cfgadm command within the domain.
- Method 3 uses the rcfgadm (remote cfgadm) command on the System Controller.
Note: When working on a security hardened system "Method 2" must be used.
Solution
How to Replace a System Board Using Dynamic Reconfiguration
Method 1
This method uses the System Controller to replace the system board.
For this method, the System Controller issues all the commands.
1) Logically remove the board (unconfigures, disconnects, and powers off the board).
/opt/SUNWSMS/bin/deleteboard -c unassign SB#
2) Physically remove the board.
It is safe to remove the board when the amber LED is on.
Note: Ensure the removed message is logged in the platform messages before following step 3.
3) Physically install a new board.
4) Power on a new board:
/opt/SUNWSMS/bin/poweron SB#
5) Match firmware to existing boards:
/opt/SUNWSMS/bin/flashupdate -f /opt/SUNWSMS/hostobjs/sgcpu.flash -v -y SB#
6) Power off the new board:
/opt/SUNWSMS/bin/poweroff SB#
7) Logically bring the board back into the system:
/opt/SUNWSMS/bin/addboard -d domain -c configure SB#
The board is now back in the system, and running the Solaris Operating System.
From the domain, verify with prtdiag.
__________________________________________
Method 2
Method 2 replaces the system board from within the domain. For this method, the domain issues most of the commands. However, the System Controller issues two of the commands.
1) Logically remove the board ( unconfigures , disconnects, and powers off the board):
/usr/sbin/cfgadm -v -c disconnect SB#
2) Physically remove the board.
It is safe to remove the board when the amber LED is on.
Note: Ensure the removed message is logged in the platform messages before following step 3.
3) Physically install the new board.
4) Issue the command on the System Controller to power on the new board:
/opt/SUNWSMS/bin/poweron SB#
5) Issue the command on the System Controller to match the firmware to existing boards:
/opt/SUNWSMS/bin/flashupdate -f /opt/SUNWSMS/hostobjs/sgcpu.flash -v -y SB#
6) Issue the command on the System Controller to power off the new board:
/opt/SUNWSMS/bin/poweroff SB#
7) Logically bring the board back into the system:
/usr/sbin/cfgadm -v -c configure SB#
The board is now back in the system, and running the Solaris Operating System.
From the domain, verify with prtdiag.
__________________________________________
Method 3
Method 3 uses the System Controller, which issues the cfgadm command, to replace the system board. This method is similar to Method 2, except the domain needs to be specified with the -d option.
1 ) Logically remove the board ( unconfigures , disconnects, and powers off the board):
/opt/SUNWSMS/bin/rcfgadm -d domain -v -c disconnect SB#
2) Physically remove the board.
It is safe to remove the board when the amber light is on.
Note: Ensure the removed message is logged in the platform messages before following step 3.
3) Physically install the new board.
4) Power on the new board:
/opt/SUNWSMS/bin/poweron SB#
5) Match firmware to existing boards:
/opt/SUNWSMS/bin/flashupdate -f
/opt/SUNWSMS/hostobjs/sgcpu.flash -v -y SB#
6) Power off the new board:
/opt/SUNWSMS/bin/poweroff SB#
7) Logically bring the board back into the system:
/opt/SUNWSMS/bin/rcfgadm -d domain -v -c configure SB#
The board is now back in the system, and running Solaris Operating System. From the domain, verify with prtdiag.
NOTE: For all three methods above, be aware of kernel cage changes affecting DR that were introduced with Solaris 9 KU patch 118558-05.
Reference: 1012349.1 Kernel Cage Splitting Overview
Internal Section
Reference the following documents for more information:
1012349.1 Kernel Cage Splitting Overview
1001149.1 System Boards could experience POST Failure if Board Replacement Procedure is not correctly followed.
Keywords: DR, 12K, 15K, flashupdate, addboard, deleteboard, cfgadm. rcfgadm, Sun Fire, 20K, 25K
Previously Published As 76047
Product_uuid
29e4659c-0a18-11d6-9fa1-e67bbc033df8|Sun Fire 15K Server
077fd4c5-df8f-4320-ad69-7d01603a674d|Sun Fire 12K Server
d842dd03-059b-11d8-84cb-080020a9ed93|Sun Fire E25K Server
1404a2d3-059a-11d8-84cb-080020a9ed93|Sun Fire E20K Server
References
<NOTE:1001149.1> - USIV+ (Panther and Jaguar) System Boards could experience POST Failure if Board Replacement Procedure is not correctly followed
<NOTE:1012349.1> - Kernel Cage Splitting Overview
Attachments
This solution has no attachment