Skip to main content
  1. Home >
  2. Products >
  3. Computing Products >
  4. Servers >
  5. Fujitsu SPARC servers >
  6. Downloads >
  7. User Manuals >
  8. Fujitsu SPARC M12 and Fujitsu M10/SPARC M10 System Operation and Administration Guide >
  9. 16.5.2 Updating XCP on a Building Block Configuration System With Multiple XSCFs

Contents

  1. Preface
  2. Chapter 1 Understanding an Overview of the SPARC M12/M10
    1.  1.1 Basics of the SPARC M12/M10
    2. Click 1.2 Basics of the XSCF Firmware
    3. Click 1.3 Network Configuration
    4.  1.4 Basics of Hypervisor
    5.  1.5 Basics of Oracle VM Server for SPARC
    6.  1.6 Basics of OpenBoot PROM
  3. Chapter 2 Logging In/Out of the XSCF
    1. Click 2.1 Connecting the System Management Terminal
    2. Click 2.2 Logging In to the XSCF Shell
    3.  2.3 Logging Out from the XSCF Shell
    4. Click 2.4 Logging In to XSCF Web
    5.  2.5 Logging Out From XSCF Web
    6.  2.6 Number of Connectable Users
  4. Chapter 3 Configuring the System
    1. Click 3.1 Preliminary Work for XSCF Setup
    2. Click 3.2 Understanding the Contents of the XSCF Firmware Settings
    3.  3.3 Setting Up From the XSCF Shell
    4.  3.4 Setting Up From XSCF Web
    5. Click 3.5 Creating/Managing XSCF Users
    6. Click 3.6 Setting the XSCF Time/Date
    7. Click 3.7 Configuring the SSH/Telnet Service for Login to the XSCF
    8. Click 3.8 Configuring the HTTPS Service for Login to the XSCF
    9. Click 3.9 Configuring the XSCF Network
    10. Click 3.10 Configuring Auditing to Strengthen XSCF Security
  5. Chapter 4 Configuring the System to Suit the Usage Type
    1. Click 4.1 Setting/Checking the System Altitude
    2. Click 4.2 Controlling System Start
    3. Click 4.3 Enabling/Disabling Dual Power Feed
    4. Click 4.4 Reducing Power Consumption
    5. Click 4.5 Connecting a DVD Drive
    6. Click 4.6 Using Remote Storage
  6. Chapter 5 CPU Activation
    1.  5.1 Basic Concepts of CPU Activation
    2.  5.2 CPU Activation Key
    3. Click 5.3 Adding CPU Core Resources
    4. Click 5.4 Deleting CPU Core Resources
    5. Click 5.5 Moving CPU Core Resources
    6. Click 5.6 Displaying CPU Activation Information
    7. Click 5.7 Saving/Restoring CPU Activation Keys
    8. Click 5.8 Troubleshooting CPU Activation Errors
    9.  5.9 Important Notes about CPU Activation
  7. Chapter 6 Starting/Stopping the System
    1. Click 6.1 Starting the System
    2. Click 6.2 Stopping the System
    3.  6.3 Rebooting the System
    4.  6.4 Suppressing Starting Oracle Solaris at Power-on
  8. Chapter 7 Controlling Physical Partitions
    1.  7.1 Configuring a Physical Partition
    2. Click 7.2 Setting the Physical Partition Operation Mode
    3.  7.3 Powering On a Physical Partition
    4.  7.4 Powering Off a Physical Partition
    5.  7.5 Changing the Configuration of a Physical Partition
  9. Chapter 8 Controlling Logical Domains
    1.  8.1 Configuring a Logical Domain
    2. Click 8.2 Configuring the Oracle Solaris Kernel Zone
    3. Click 8.3 Switching to the Control Domain Console From the XSCF Shell
    4. Click 8.4 Returning to the XSCF Shell From the Control Domain Console
    5.  8.5 Starting a Logical Domain
    6.  8.6 Shutting Down a Logical Domain
    7. Click 8.7 Ordered Shutdown of Logical Domains
    8.  8.8 Checking CPU Activation Information
    9. Click 8.9 Setting the OpenBoot PROM Environment Variables of the Control Domain
    10. Click 8.10 Domain Console Logging Function
    11.  8.11 Changing the Configuration of a Logical Domain
    12.  8.12 Setting the Logical Domain Time
    13. Click 8.13 Collecting a Hypervisor Dump File
    14. Click 8.14 Managing Logical Domain Resources Associated with CPU Sockets
    15. Click 8.15 Setting the Physical Partition Dynamic Reconfiguration Policy
    16. Click 8.16 Setting the Maximum Page Size of a Logical Domain
  10. Chapter 9 Managing the Systems Daily
  11. Chapter 10 Preparing/Taking Action for Failures
    1.  10.1 Learning about Troubleshooting and Related Functions
    2. Click 10.2 Receiving Notification by E-mail When a Failure Occurs
    3. Click 10.3 Monitoring/Managing the System Status With the SNMP Agent
    4. Click 10.4 Monitoring the System
    5.  10.5 Understanding the Failure Degradation Mechanism
    6. Click 10.6 Checking Failed Hardware Resources
    7. Click 10.7 Setting Automatic Replacement of Failed CPU Cores
    8.  10.8 Setting Recovery Mode
    9.  10.9 Setting Up a Redundant Component Configuration
    10. Click 10.10 Saving/Restoring XSCF Settings Information
    11. Click 10.11 Saving/Restoring Logical Domain Configuration Information in the XSCF
    12. Click 10.12 Saving/Restoring Logical Domain Configuration Information in an XML File
    13. Click 10.13 Saving/Restoring the OpenBoot PROM Environment Variables
    14.  10.14 Saving/Restoring the Contents of a Hard Disk
    15.  10.15 Resetting a Logical Domain
    16. Click 10.16 Causing a Panic in a Logical Domain
    17.  10.17 Resetting a Physical Partition
    18. Click 10.18 Returning the Server to the State at Factory Shipment
    19.  10.19 Collecting a Crash Dump File Using Deferred Dump
  12. Chapter 11 Checking the System Status
    1. Click 11.1 Checking the System Configuration/Status
    2. Click 11.2 Checking a Physical Partition
  13. Chapter 12 Checking Logs and Messages
    1. Click 12.1 Checking a Log Saved by the XSCF
    2. Click 12.2 Checking Warning and Notification Messages
  14. Chapter 13 Switching to Locked Mode/Service Mode
    1.  13.1 Understanding the Differences Between Locked Mode and Service Mode
    2.  13.2 Switching the Operating Mode
  15. Chapter 14 Configuring a Highly Reliable System
    1. Click 14.1 Configuring Memory Mirroring
    2. Click 14.2 Configuring Hardware RAID
    3.  14.3 Using the LDAP Service
    4.  14.4 Using SAN Boot
    5.  14.5 Using iSCSI
    6. Click 14.6 Remote Power Management for the SPARC M12/M10 and I/O Devices
    7.  14.7 Using an Uninterruptible Power Supply
    8. Click 14.8 Using Verified Boot
  16. Chapter 15 Expanding the System Configuration
    1.  15.1 Changing the Virtual CPU Configuration
    2.  15.2 Changing the Memory Configuration
    3. Click 15.3 Dynamic Reconfiguration Function for PCIe Endpoint Devices
    4. Click 15.4 Using the PCI Expansion Unit
    5.  15.5 Expanding the SPARC M12-2S/M10-4S
  17. Chapter 16 Updating the XCP Firmware
    1. Click 16.1 Basics of Firmware Update
    2. Click 16.2 Before Updating Firmware
    3.  16.3 Update Flow
    4.  16.4 Preparing an XCP Image File
    5. Click 16.5 Updating Firmware
    6.  16.6 Updating Firmware From XSCF Web
    7. Click 16.7 Firmware Version Matching with Parts Addition/Replacement
    8.  16.8 Trouble During Firmware Update
    9.  16.9 FAQ Relating to Firmware Update
  18. Chapter 17 Updating Oracle Solaris and Oracle VM Server for SPARC
  19. Chapter 18 Troubleshooting
    1.  18.1 Troubleshooting for the XSCF
    2.  18.2 Precautions Concerning Using the RESET Switch
    3.  18.3 Frequently Asked Questions / FAQ
    4.  18.4 System Troubleshooting With the XSCF
  20. Appendix A Lists of SPARC M12/M10 System Device Paths
    1.  A.1 SPARC M12-1 Device Paths
    2. Click A.2 SPARC M12-2 Device Paths
    3. Click A.3 SPARC M12-2S Device Paths
    4.  A.4 SPARC M10-1 Device Paths
    5. Click A.5 SPARC M10-4 Device Paths
    6. Click A.6 SPARC M10-4S Device Paths
  21. Appendix B Identifying an SAS2 Device Based on a WWN
    1.  B.1 World Wide Name (WWN) Syntax
    2.  B.2 Overview of probe-scsi-all Command Output
    3. Click B.3 Identifying a Disk Slot by Using the probe-scsi-all Command
    4. Click B.4 Identifying Disk Slot
  22. Appendix C List of the XSCF Web Pages
    1.  C.1 Overview of the Pages
    2.  C.2 Understanding the Menu Configuration
    3. Click C.3 Available Pages
  23. Appendix D XSCF MIB Information
    1.  D.1 MIB Object Identification
    2.  D.2 Standard MIB
    3. Click D.3 Extended MIB
    4.  D.4 Traps
  24. Appendix E SPARC M12/M10 System-specific Functions of Oracle VM Server for SPARC
    1.  E.1 Ordered Shutdown of Logical Domains
    2.  E.2 CPU Activation Support
    3. Click E.3 Checking Failed Resources
    4.  E.4 Automatic Replacement of Failed CPUs
    5.  E.5 Hypervisor Dump
    6.  E.6 Domain Console Logging Function
    7.  E.7 CPU Socket Restrictions
  25. Appendix F SAS2IRCU Utility Command Examples
    1.  F.1 Displaying a List of SAS Controllers Recognized by sas2ircu
    2.  F.2 Displaying the Information of a Hardware RAID Volume
    3.  F.3 Adding a Hardware RAID Volume
    4.  F.4 Displaying the Configuration Status of a Hardware RAID Volume
    5.  F.5 Creating a Hot Spare of a Hardware RAID Volume
    6.  F.6 Deleting a Hot Spare of a Hardware RAID Volume
    7.  F.7 Deleting a Hardware RAID Volume
    8.  F.8 Identifying the Faulty Disk Drive of a Hardware RAID Volume
  26. Appendix G SPARC M12-1/M10-1 XSCF Startup Mode Function
    1. Click G.1 Function Overview
    2. Click G.2 Restrictions and Notes
    3.  G.3 Configuration Procedure
  27. Appendix H OpenBoot PROM Environment Variables and Commands
    1.  H.1 SCSI Device Display
    2.  H.2 Unsupported OpenBoot PROM Environment Variables
    3.  H.3 Unsupported OpenBoot PROM Commands
    4.  H.4 Behavior With the Security Mode Enabled
  28. Appendix I How to Specify the Boot Device
    1.  I.1 Device Path of the Internal Storage
    2.  I.2 Method of Specification With a PHY Number
    3.  I.3 Method of Specification With a Target ID
    4.  I.4 Method of Specification With an SAS Address
    5.  I.5 Method of Specification With a Volume Device Name
    6.  I.6 Notes About the Device Alias net of the SPARC M12 Without On-Board LAN
  29. Appendix J Lists of DVD Drive Aliases
    1. Click J.1 External DVD Drive Aliases
    2. Click J.2 Remote Storage DVD Drive Aliases
  30. Appendix K CPU Activation Interim Permit
    1.  K.1 What is the CPU Activation Interim Permit?
    2.  K.2 Terms of Use of the CPU Activation Interim Permit and Precautions
    3. Click K.3 Related Commands
    4. Click K.4 Flows and Procedures for Using a CPU Activation Interim Permit
    5. Click K.5 Event Notification of the CPU Activation Interim Permit
    6. Click K.6 Other Important Notes

16.5.2 Updating XCP on a Building Block Configuration System With Multiple XSCFs


16.5.2 Updating XCP on a Building Block Configuration System With Multiple XSCFs
  1. Log in to the master XSCF.
  2. Execute the showhardconf command, and confirm that Status is Normal for both the master XSCF and standby XSCF.
  1. The following shows examples of the SPARC M10-4S.
XSCF> showhardconf
SPARC M10-4S;
+ Serial:2081230011; Operator_Panel_Switch:Locked;
+ System_Power:Off; System_Phase:Cabinet Power Off;
Partition#0 PPAR_Status:Powered Off;
Partition#1 PPAR_Status:Powered Off;
BB#00 Status:Normal; Role:Master; Ver:2003h; Serial:2081231002;
+ FRU-Part-Number:CA07361-D202 A1
:
BB#01 Status:Normal; Role:Standby Ver:0101h; Serial:7867000297;
+ FRU-Part-Number:CA20393-B50X A2 ;
  1. Execute the version command to check the version of the firmware in operation.
Note - The firmware can be updated from XCP 3xxx to XCP 3xxx or from XCP 4xxx to XCP 4xxx. Do not update the firmware from XCP 3xxx to XCP 4xxx or from XCP 4xxx to XCP 3xxx.
XSCF> version -c xcp -v
BB#00-XSCF#0 (Master)
XCP0 (Current): 2041
CMU : 02.04.0001
POST : 1.42.0
OpenBoot PROM : 4.34.0+1.16.0
Hypervisor : 0.26.9
XSCF : 02.04.0001
XCP1 (Reserve): 2041
CMU : 02.04.0001
POST : 1.42.0
OpenBoot PROM : 4.34.0+1.16.0
Hypervisor : 0.26.9
XSCF : 02.04.0001
BB#01-XSCF#0 (Standby)
XCP0 (Reserve): 2041
CMU : 02.04.0001
POST : 1.42.0
OpenBoot PROM : 4.34.0+1.16.0
Hypervisor : 0.26.9
XSCF : 02.04.0001
XCP1 (Current): 2041
CMU : 02.04.0001
POST : 1.42.0
OpenBoot PROM : 4.34.0+1.16.0
Hypervisor : 0.26.9
XSCF : 02.04.0001
CMU BACKUP
#0: 02.04.0001
#1: ..
  1. For the SPARC M12-2S, there is no reserve bank of the CMU firmware. The following shows a display example.
XSCF# version -c xcp -v
BB#00-XSCF#0 (Standby)
XCP0 (Reserve): 3010
XSCF : 03.01.0000
XCP1 (Current): 3010
XSCF : 03.01.0000
CMU : 03.01.0000
POST :
OpenBoot PROM :
Hypervisor :
BB#01-XSCF#0 (Master)
XCP0 (Reserve): 3010
XSCF : 03.01.0000
XCP1 (Current): 3010
XSCF : 03.01.0000
CMU : 03.01.0000
POST :
OpenBoot PROM :
Hypervisor :
CMU BACKUP
#0: 03.01.0000
#1: ..
XSCF#
  1. Execute the getflashimage command to import the XCP image file.
    The following example imports the XSCF image file from a USB device connected to a USB port (where "MAINTENANCE ONLY" is printed) on the XSCF unit panel (rear panel) of the master XSCF.
XSCF> getflashimage file:///media/usb_msd/xxxx/BBXCP2044.tar.gz
Existing versions:
Version Size Date
BBXCP2041.tar.gz 90004045 Tue Apr 09 04:40:12 JST 2013
Mounted USB device
0MB received
1MB received
...
44MB received
45MB received
Download successful: 46827 Kbytes in 109 secs (430.094 Kbytes/sec)
Checking file...
MD5: e619e6dd367c888507427e58cdb8e0a4
XSCF>
  1. XCP image file importing is completed when the normal end messages "Download successful: ..." and "MD5: ..." appear.
Note - If the following error occurs during XCP import, there may be a problem with the XCP file: "Error: File is invalid or corrupt." Check the XCP file.
The possible cause, for example, is that an unauthorized XCP image file was obtained or that the XCP image file downloaded by the customer was subsequently changed through unauthorized access. In such cases, obtain the correct XCP image file and import XCP again.
Note - If a message such as "An internal error has occurred" or "Error: insufficient free space" appears during XCP import, an XSCF firmware error or parts failure may have occurred. In this case, see "16.8 Trouble During Firmware Update" and solve the problem.
  1. Use the getflashimage -l command to check the version of the imported XCP image file.
XSCF> getflashimage -l
Existing versions:
Version Size Date
BBXCP2044.tar.gz 90005045 Wed May 29 09:11:40 JST 2013
  1. Execute the flashupdate -c check command to check whether the imported XCP image file can be used for the update.
    Immediately after executing the flashupdate command, execute the showresult command. If the returned end value is 0, you can use the file for the update.
XSCF> flashupdate -c check -m xcp -s 2044
XSCF> showresult
0
XSCF>
  1. Execute the flashupdate command to update the firmware.
Note - The update takes about 60 minutes.
Note - To safely update the firmware, do not perform power operations for physical partitions and do not reboot the XSCF during the work (steps 7 to 11). For details, see "16.2.1 Notes on Update."
Note - If a message such as "An internal error has occurred" or "Internal error" appears during firmware update, an XSCF firmware error or parts failure may have occurred. In this case, see "16.8 Trouble During Firmware Update" and solve the problem.
XSCF> flashupdate -c update -m xcp -s 2044
The XSCF will be reset. Continue? [y|n] :y
XCP update is started. [3600sec]
0..... 30..... 60..... 90.....120.....150.....180.....210.....240.....-
270.....300.....330.....360.....390.....420.....450.....480.....510.....|

540.....570.....600.....630.....660.....690.....720.....750.....780.....-

810.....840.....870.....900.....930

:
  1. Here, the XSCF is rebooted, the XSCF session is disconnected.
    At this point in time, the XCP firmware update is not yet complete.
  2. Connect to the master XSCF again.
    Immediately after the XSCF reboot, the states of the master and standby XSCFs are reversed from their original states. For example, when the firmware update is executed with BB-ID number 0 on master XSCF, reconnecting to XSCF will change the status of BB-ID number 1 to master and BB-ID number 0 to standby. In this example, the master XSCF (BB-ID 1) is connected.
Note - For customers who have set the takeover IP address, the machines are automatically connected to the master XSCF when connected using the takeover IP address.
  1. Execute the showbbstatus command, and confirm that you are logged in to the master XSCF. If you are logged in to the standby XSCF, reconnect to the master XSCF.
Note - If the firmware is updated to version XCP 2050 or later, when the XCP firmware update is completed, the switched master/standby XSCF will return to the original state. In such cases, connect to the master XSCF again because the XSCF is rebooted and the XSCF session is disconnected.
XSCF> showbbstatus
BB#01 (Master)
  1. Execute the showlogs monitor command to check the completion of the XCP firmware update.
XSCF> showlogs monitor
May 29 09:38:05 M10-4S-0 Event: SCF:XCP update is started (XCP version=2044:last version=2041)
May 29 09:40:31 M10-4S-0 Event: SCF:XSCF update is started (BBID=0, bank=0)
May 29 09:40:46 M10-4S-0 Event: SCF:XSCF update is started (BBID=1, bank=0)
May 29 09:41:03 M10-4S-0 Event: SCF:XSCF writing is performed (BBID=0, XSCF version=02040004)
May 29 09:41:12 M10-4S-0 Event: SCF:XSCF writing is performed (BBID=1, XSCF version=02040004)
May 29 09:48:18 M10-4S-0 Event: SCF:XSCF update has been completed (BBID=0, bank=0)
May 29 09:50:39 M10-4S-0 Event: SCF:XSCF update has been completed (BBID=1, bank=0)
May 29 09:50:41 M10-4S-0 Event: SCF:XSCF bank apply has been completed (BBID=1, bank=0, XCP version=2044:last version=2041)
May 29 10:01:50 M10-4S-0 Event: SCF:XSCF bank apply has been completed (BBID=0, bank=0, XCP version=2044:last version=2041)
May 29 10:01:51 M10-4S-0 Event: SCF:Change Master Start(BB#01)
May 29 10:03:26 M10-4S-1 Event: SCF:Change Master Complete(BB#01)
May 29 10:05:00 M10-4S-1 Event: SCF:Standby XSCF Ready (BBID#00)
May 29 10:12:56 M10-4S-1 Event: SCF:XSCF update is started (BBID=1, bank=1)
May 29 10:13:23 M10-4S-1 Event: SCF:XSCF update is started (BBID=0, bank=1)
May 29 10:13:24 M10-4S-1 Event: SCF:XSCF writing is performed (BBID=0, XSCF version=02040004)
May 29 10:13:42 M10-4S-1 Event: SCF:XSCF writing is performed (BBID=1, XSCF version=02040004)
May 29 10:20:22 M10-4S-1 Event: SCF:XSCF update has been completed (BBID=0, bank=1)
May 29 10:23:34 M10-4S-1 Event: SCF:XSCF update has been completed (BBID=1, bank=1)
May 29 10:24:42 M10-4S-1 Event: SCF:CMU update is started (BBID=0)
May 29 10:24:58 M10-4S-1 Event: SCF:CMU writing is performed (BBID=0, CMU version=02040004)
May 29 10:25:44 M10-4S-1 Event: SCF:CMU update is started (BBID=1)
May 29 10:25:46 M10-4S-1 Event: SCF:CMU writing is performed (BBID=1, CMU version=02040004)
May 29 10:26:44 M10-4S-1 Event: SCF:CMU update has been completed (BBID=0)
May 29 10:27:51 M10-4S-1 Event: SCF:CMU update has been completed (BBID=1)
May 29 10:29:30 M10-4S-1 Event: SCF:CMU update is started (BBID=0)
May 29 10:29:36 M10-4S-1 Event: SCF:CMU writing is performed (BBID=0, CMU version=02040004)
May 29 10:29:45 M10-4S-1 Event: SCF:CMU update is started (BBID=1)
May 29 10:30:04 M10-4S-1 Event: SCF:CMU writing is performed (BBID=1, CMU version=02040004)
May 29 10:31:18 M10-4S-1 Event: SCF:CMU update has been completed (BBID=0)
May 29 10:31:51 M10-4S-1 Event: SCF:CMU update has been completed (BBID=1)
May 29 10:32:38 M10-4S-1 Event: SCF:XCP update has been completed (XCP version=2044:last version=2041)
May 29 10:32:39 M10-4S-1 Event: SCF:This XSCF will be switched back to standby mode after completion of firmware update
May 29 10:32:39 M10-4S-1 Event: SCF:Change Master Start(BB#00)
May 29 10:33:29 M10-4S-1 Event: SCF:Change Master Complete(BB#00)
May 29 10:42:29 M10-4S-1 Event: SCF:Standby XSCF Ready (BBID#01)
  1. The following example displays messages on the SPARC M12-2S.
XSCF> showlogs monitor
Apr 5 06:51:06 M12-2S-1 Event: SCF:XCP update is started (XCP version=3010:last version=3009)
Apr 5 07:01:41 M12-2S-1 Event: SCF:Updating XCP:Preparing to update XSCF (BBID=1, bank=1)
Apr 5 07:03:46 M12-2S-1 Event: SCF:Updating XCP:Updating XSCF (BBID=1, XSCF version=03010000)
Apr 5 07:03:54 M12-2S-1 Event: SCF:Updating XCP:XSCF updated (BBID=1, bank=1)
Apr 5 07:06:58 M12-2S-1 Event: SCF:Updating XCP:Preparing to update XSCF (BBID=0, bank=0)
Apr 5 07:09:22 M12-2S-1 Event: SCF:Updating XCP:Updating XSCF (BBID=0, XSCF version=03010000)  
Apr 5 07:10:39 M12-2S-1 Event: SCF:Updating XCP:XSCF updated (BBID=0, bank=0)
Apr 5 07:12:50 M12-2S-1 Event: SCF:Updating XCP:XSCF bank has changed (BBID=1, bank=1, XCP version=3010:last version=3009)
Apr 5 07:20:06 M12-2S-1 Event: SCF:Updating XCP:XSCF bank has changed (BBID=0, bank=0, XCP version=3010:last version=3009)
Apr 5 07:21:27 M12-2S-1 Event: SCF:Change Master Start(BB#01)
Apr 5 07:22:28 M12-2S-2 Event: SCF:Standby XSCF Ready(BB#01)
Apr 5 07:24:05 M12-2S-2 Event: SCF:Change Master Complete(BB#01)
Apr 5 07:30:08 M12-2S-2 Event: SCF:Updating XCP:Preparing to update XSCF (BBID=1, bank=0)
Apr 5 07:30:35 M12-2S-2 Event: SCF:Updating XCP:Preparing to update XSCF (BBID=0, bank=0)
Apr 5 07:34:41 M12-2S-2 Event: SCF:Standby XSCF Ready(BB#00)
Apr 5 07:35:21 M12-2S-2 Event: SCF:Updating XCP:Updating XSCF (BBID=0, XSCF version=03010000)
Apr 5 07:40:32 M12-2S-2 Event: SCF:Updating XCP:XSCF updated (BBID=0, bank=1)
Apr 5 07:40:39 M12-2S-2 Event: SCF:Updating XCP:Updating XSCF (BBID=1, XSCF version=03010000)
Apr 5 07:45:49 M12-2S-2 Event: SCF:Updating XCP:XSCF updated (BBID=1, bank=0)
Apr 5 07:46:18 M12-2S-2 Event: SCF:Updating XCP:Preparing to update CMU (BBID=0)  
Apr 5 07:46:41 M12-2S-2 Event: SCF:Updating XCP:Updating CMU (BBID=0, CMU version=03010000)  
Apr 5 07:48:21 M12-2S-2 Event: SCF:Updating XCP:CMU updated (BBID=0)
Apr 5 07:49:00 M12-2S-2 Event: SCF:Updating XCP:Preparing to update CMU (BBID=1)
Apr 5 07:49:30 M12-2S-2 Event: SCF:Updating XCP:Updating CMU (BBID=1, CMU version=03010000)
Apr 5 07:51:24 M12-2S-2 Event: SCF:Updating XCP:CMU updated (BBID=1)
Apr 5 07:51:25 M12-2S-2 Event: SCF:XCP update has been completed (XCP version=3010:last version=3009)
Apr 5 07:51:26 M12-2S-2 Event: SCF:This XSCF will be switched back to standby mode after completion of firmware update
Apr 5 07:51:57 M12-2S-1 Event: SCF:Change Master Complete(BB#00)
If the message "XCP update has been completed" appears, the XCP firmware update has completed.
Note - A message similar to "XSCF update has been completed" or "CMU update has been completed" will appear on the SPARC M10. However, the update of all the XCP firmware will not have completed by the time the message appears.
Note - To safely update the firmware, do not perform power operations for physical partitions, reboot the XSCF, etc. until you have confirmed the "XCP update has been completed" message on the completion of the XCP firmware update. For details, see "16.2.1 Notes on Update."
  1. If the message "XCP update has been completed" does not appear, the update is not yet complete. Execute the showlogs monitor command again to check the completion of the update.
    Usually, the update is completed about 40 minutes after an XSCF reboot.


    - If the power of the physical partition is on

    The update of the target CMU firmware has not yet begun at the point in time where the flashupdate command is executed and update completion is checked. Therefore, the message does not appear for the CMU firmware. The update of the target CMU firmware begins when the physical partition is powered off and on in step 13.


    - If the firmware is updated to version XCP 2050 or later

    After the firmware update is completed, the master and standby XSCFs are automatically switched. The automatic switching takes about 10 minutes.
  1. If the messages "This XSCF will be switched back to standby mode after completion of firmware update," "Change Master Complete," and "Standby XSCF Ready" appear, the switching has been completed.

    To check the completion of the switching, execute the showhardconf command, and confirm that Status is Normal for both the master XSCF and standby XSCF.
XSCF> showhardconf
SPARC M10-4S;
+ Serial:2081230011; Operator_Panel_Switch:Locked;
+ System_Power:Off; System_Phase:Cabinet Power Off;
Partition#0 PPAR_Status:Powered Off;
Partition#1 PPAR_Status:Powered Off;
BB#00 Status:Normal; Role:Master; Ver:2003h; Serial:2081231002;
+ FRU-Part-Number:CA07361-D202 A1
:
BB#01 Status:Normal; Role:Standby Ver:0101h; Serial:7867000297;
+ FRU-Part-Number:CA20393-B50X A2 ;
  1. After confirming that the switching has completed, go to step 12. 
Note - If execution of the showhardconf command displays "Cannot communicate with the other XSCF. Check the other XSCF's state.", the switching of the master and standby XSCFs has not been completed. Execute the showhardconf command again to check the completion of the switching.
Note - Firmware update processing switches the master and standby XSCFs twice. As a result, the XSCF where you executed the flashupdate command returns to being the master XSCF. Switching the master and standby XSCFs may disconnect the XSCF session. If the XSCF session is disconnected, reconnect.
Note - Do not perform power operations for physical partitions, reboot the XSCF, etc. until the switching of the master and standby XSCFs has completed. For details, see "16.2.1 Notes on Update."
  1. - If the firmware is updated to version XCP 2044 or earlier
Firmware update processing switches the master and standby XSCFs. As a result, the other XSCF paired with the XSCF where you executed the flashupdate command becomes the master XSCF.
  1. Execute the switchscf command to return the master and standby XSCFs to their pre-update states.
Note - When updating the firmware to version XCP 2050 or later, you do not have to perform this work because the XSCFs have already been switched.
XSCF> switchscf -t Standby
The XSCF unit switch between the Active and Standby states.
Continue? [y|n] :y
  1. Since an XSCF reboot disconnects the XSCF session, the master XSCF is connected again.

    To check the completion of the switching, execute the showhardconf command, and confirm that Status is Normal for both the master XSCF and standby XSCF.
XSCF> showhardconf
SPARC M10-4S;
+ Serial:2081230011; Operator_Panel_Switch:Locked;
+ System_Power:Off; System_Phase:Cabinet Power Off;
Partition#0 PPAR_Status:Powered Off;
Partition#1 PPAR_Status:Powered Off;
BB#00 Status:Normal; Role:Master; Ver:2003h; Serial:2081231002;
+ FRU-Part-Number:CA07361-D202 A1
:
BB#01 Status:Normal; Role:Standby Ver:0101h; Serial:7867000297;
+ FRU-Part-Number:CA20393-B50X A2 ;
Note - If execution of the showhardconf command displays "Cannot communicate with the other XSCF. Check the other XSCF's state.", the switching of the master and standby XSCFs has not been completed. Execute the showhardconf command again to check the completion of the switching.
  1. Set the XSCF time.
    If the XSCF time has shifted, the logical domain time may shift when the physical partition is powered on.
    For details on how to set the XSCF time, see "6.1.2 Setting the XSCF Time Before System Startup."
  1. To complete the CMU firmware update when the power of the physical partition is on, power off and on the physical partition.
    If the power of the physical partition is off, go to step 14.
Note - In the case of a logical domain configuration, execute the ldm add-spconfig command of Oracle VM Server for SPARC in the control domain to save the latest configuration information in the XSCF before powering off the physical partition.
For details, see "6.2.2 Saving the Logical Domain Configuration Information before System Stop" and "10.11.1 Saving/Displaying Logical Domain Configuration Information."
  1. If the power of the physical partition is on, execute the poweroff command to power off the physical partition.
XSCF> poweroff -p xx
  1. Execute the showpparstatus power command, and confirm that the power of the physical partition is off.
XSCF> showpparstatus -p xx
PPAR-ID PPAR Status
xx Powered Off
  1. Execute the poweron command to power on the physical partition.
XSCF> poweron -p xx
  1. Execute the showpparstatus command, and confirm that PPAR Status is "Running."
XSCF> showpparstatus -p xx
PPAR-ID PPAR Status
xx Running
  1. Execute the version command, and confirm that the firmware version is up to date.
XSCF> version -c xcp -v
BB#00-XSCF#0 (Master)
XCP0 (Reserve): 2044
CMU : 02.04.0004
POST : 1.43.0
OpenBoot PROM : 4.34.0+1.19.0
Hypervisor : 0.27.3
XSCF : 02.04.0004
XCP1 (Current): 2044
CMU : 02.04.0004
POST : 1.43.0
OpenBoot PROM : 4.34.0+1.19.0
Hypervisor : 0.27.3
XSCF : 02.04.0004
BB#01-XSCF#0 (Standby)
XCP0 (Current): 2044
CMU : 02.04.0004
POST : 1.43.0
OpenBoot PROM : 4.34.0+1.19.0
Hypervisor : 0.27.3
XSCF : 02.04.0004
XCP1 (Reserve): 2044
CMU : 02.04.0004
POST : 1.43.0
OpenBoot PROM : 4.34.0+1.19.0
Hypervisor : 0.27.3
XSCF : 02.04.0004
CMU BACKUP
#0: 02.04.0004
#1: ..
Note - On the SPARC M10, if firmware is updated by powering on the physical partition, only the current bank of the CMU firmware is updated.
With the CMU firmware, where control is handled only by the current bank, there is no problem with an outdated version of the reserve bank.
If the firmware is updated by stopping the power of a physical partition, then both the reserve bank and current bank of the CMU firmware are updated.
For the CMU firmware version that corresponds to the XCP version, see "Existing XCP Firmware Versions and Support Information" in the latest Product Notes for your server.

Top of Page