Upgrade of XSCF Firmware and Maintenance

C H A P T E R 8

This chapter explains how to update the firmware and how to collect log data.

8.1 Update the XSCF Firmware

This section explains firmware update functions and how to update the firmware. The firmware update work is performed by the system administrator or a field engineer.

8.1.1 Firmware Update Overview

The firmware programs listed below are updated by the firmware update.

POST and OpenBoot PROM firmwares (hereafter collectively called the OpenBoot PROM firmware)

XSCF firmware

When updating the firmware, the new XCP firmware (see Note) is obtained from a web site (or from external media such as a CD-ROM disk) and downloaded to an arbitrary folder on a personal computer or workstation connected to the server. The firmware update sequence is: 1) XCP import in the system and 2) update.

Note - XCP: Abbreviation for the XSCF Control Package. XCP contains the control programs that configure a computing system. The XSCF firmware and the OpenBoot PROM firmware are included in the XCP file. The firmware update functions provided by XSCF are used to manage XCP.

FIGURE 8-1 is a conceptual diagram of the firmware update.

FIGURE 8-1 Conceptual Diagram of the Firmware Update

Figure showing the conceptual diagram of the firmware update.

1. XCP import

2. Update (includes application of the XSCF firmware)

Note - The OpenBoot PROM firmware is applied by a domain reboot. In the M3000 server, this function updates the OpenBoot PROM firmware which is in the flash memory of the single MBU. And the number of domains to be updated is one.

User Interfaces

The following function is used for the firmware update:

Firmware update using XSCF Web in a browser

XCP Import: Imports firmware to this system.

XCP Update: Updates the firmware to flash memory, applies the XSCF firmware, and the OpenBoot PROM firmware.

Version: Displays the firmware version.

Using the XSCF Web console, the user can easily update firmware from a browser. Also, regular maintenance and emergency firmware updates are supported. For the method of starting XSCF Web, see Chapter 9.

Firmware update using the XSCF Shell

Use the following commands to update the firmware:

getflashimage(8) command: Imports firmware to this system.

flashupdate(8) command: Downloads the firmware to flash memory and applies the XSCF firmware.

poweron(8) command and reset(8) command: Applies the OpenBoot PROM firmware.

version(8) command: Displays the firmware version.

Note - For details on these four commands, see the man pages or the XSCF Reference Manual.

8.1.2 Firmware Update Conditions and Environment

User Privileges

The firmware update can be performed with either of the following two user privileges:

platadm

fieldeng

Firmware Update Environment

The following environment is required for the firmware to update properly:

The update is performed from a browser connected to the XSCF-LAN.

The update is performed after the domain console is switched to the XSCF Shell console.

The update is performed with the maintenance terminal connected to the XSCF serial port or XSCF-LAN port.

8.1.3 Method of Delivering Firmware

Delivering the XCP Files

The XCP files are stored at the locations and in the format described below. After obtaining the XCP files, you can import XCP regardless of whether the operating system is running or stopped.

At a web site

Format: Compressed tar file (tar.gz) or Windows executable (exe)

Note - To obtain the URL of the Web site, see the description of the firmware download in the Product Notes for your server.

Note - When the operation is done by Service or Field Engineers (SEs/FEs), a
CD-ROM, DVD-ROM, or flash drive may be used.

8.1.4 Method of Checking the Firmware Version

The firmware version for this system is called the XCP version. Higher version numbers represent newer firmware. Before updating the firmware, be sure to check the XCP version in the current system. The following example shows a command that displays the XCP version:

XSCF> version -c xcp
XSCF#0 (Active)
XCP0 (Current) : 1080
XCP1 (Reserve) : 1080
XSCF#1 (Standby)
XCP0 (Current) : 1080
XCP1 (Reserve) : 1080

The XCP version number appears as xyyz by four digits, where:

x = Major firmware release number

yy = Minor release number

z = Micro release number

Note - Because micro release numbers may be updated more often than the documentation, the micro release number may appear in documents as a variable. An example might be XCP 108x.

The XSCF and OpenBoot PROM firmwares have different firmware version numbers. You can use the version(8) command or XSCF Web to display the XCP version for the system or the version of a firmware program.

In the flash memory of firmware, there are two bank fields: the current bank and the reserve bank. The firmware update is controlled by using these two banks. In the current bank, there is a firmware that the system is using now. The reserve bank is used to do the firmware update safely.

Note - The latest XCP information is released on the web site. To obtain the URL of the web site, contact your sales representative.

8.1.5 Three Steps of the Firmware Update

The firmware update for the server has three steps (XCP import, update, application) as explained below.

1. XCP import

Storing the obtained XCP data in this system is called "XCP import." The system administrator or a field engineer obtains the XCP data files from the network or external media (CD-ROM, DVD-ROM, or flash drive), then he or she imports the data file using an XSCF console from a client (personal computer or workstation) connected to the server.

Simply importing XCP does not update the firmware that is running. Also, the XCP file is imported only by the versions number of one generation.

2. Update

Writing the XSCF and OpenBoot PROM firmware programs that were imported in step 1 to flash memory in this system is called "update." Performing the download writes the XSCF firmware to the flash memory of the XSCF Unit, resets the XSCF, applies the XSCF firmware, and completes the firmware update. The OpenBoot PROM firmware is written to the flash memory on the system board. The OpenBoot PROM firmware is applied during a reboot.

Caution - IMPORTANT- Even if this system is divided into domains, the update is performed to newly write the OpenBoot PROM firmware to the flash memory on the XSB of every domain. However, unlike the XSCF firmware, just the download of this firmware does not update the OpenBoot PROM firmware that is running. To complete updating the OpenBoot PROM firmware in the target domain, the domain must be rebooted.

3. Application

Making the firmware written to flash memory in this system actually usable is called "application."

Note - The number of domains that can be updated (application) is one or more. To apply the OpenBoot PROM firmware in the target domain, be sure to reboot the domain for firmware application.

8.1.6 Features of XSCF Firmware Update

The firmware update that is managed by XSCF has the following features:

New firmware for a domain can be updated without stopping the domain. To update the OpenBoot PROM firmware, however, the target domain must be rebooted so that the firmware can be applied.

When a component is replaced, the firmware is automatically updated. However, when a component is replaced in the state of input power off (The cold replacement), the firmware is not updated automatically.

Even in a system consisting of multiple domains, firmware in a domain can be updated to the latest firmware without affecting the other domains.

Even if an error occurs during the update operation, the firmware generation management mechanism (which retains spare firmware) can prevent firmware data destruction.

8.1.7 Firmware Update Types and Timing

The firmware update includes two types: operator's update and automatic update (automatic matching of versions). In the M3000 server, automatic update is not available, so the operator’s update is needed.

TABLE 8-1 describes the firmware update types and update times.

TABLE 8-1 Firmware Update Types and Timing
Type	Description	Conditions	Update Time
Operator's update (XCP update)	Imports XCP and updates the XSCF firmware and OpenBoot PROM firmware on the XSBs belonging to all domains (including pooled domains). This is also referred to as "XCP update."	The system power is off (input power is on and all domains are stopped), or power to the domains is on. Note: The update is completed at the time of a reboot for application in all domains.	XCP update time
Automatic update (Automatic matching of versions) Note: In the M3000 server, automatic update is not available.	When a CPU/Memory Board unit (Note 1) is added or replaced, or the XSCF Unit is replaced, the firmware version of each replacement component is automatically matched to the version of the replaced component. (Note 2) However, when a component is replaced in the state of input power off (The cold replacement), the firmware is not updated automatically. When the DR function is used to add, move, or replace a system board (XSB), the firmware version is automatically matched to the firmware version in the domain that uses the system board.	The system power is off (input power is on and all domains are stopped), or power to the domains is on. In the system with redundant XSCF Units, If you replace an XSCF Unit by using the maintenance guidance, the firmware version of the replacement XSCF Unit is matched to the firmware version of the replaced XSCF Unit. In CPU/Memory Board unit addition or replacement, the target domain need not be rebooted for application of the OpenBoot PROM firmware. However, when the domain is powered off, the number of versions is matched by the startup of the domain.	Time of CPU/Memory Board unit addition or replacement. Or time of replacement of an XSCF Unit that is configured redundantly Time of addition, move, or replacement of a system board by the DR function

Note - (1) Corresponds to a Motherboard unit in the M4000/M5000 servers. (The same is true for the description below.) Also, turn off the input power before replacing the Motherboard unit.

Note - (2) The replacement of the XSCF Unit and the version matching is performed by FEs. When both XSCF Units are replaced in the systems with redundant XSCF Units (the M8000/M9000 servers), or when in the M4000/M5000 servers, or when a Motherboard unit is replaced (an XSCF Unit is replaced) in the M3000 server, the firmware version cannot be automatically set to match the version of the replaced unit. Perform the operator's update for the XCP version.

8.1.8 Firmware Update for Redundant XSCF Units

In a system with redundant XSCF Units, you have only to connect to the XSCF Unit on the active side and update the firmware. The firmware upgrade is performed first on the XSCF Unit on the standby side and then on the active side automatically. Due to resetting the XSCF and switching the networks of the XSCF Units on the active and standby sides, the network is disconnected at this time. Therefore, the user must log in again. For details, see Section 8.1.10, Firmware Update Procedure

In a system with redundant XSCF Units, if the system is operating with only the active XSCF Unit, such as because of a failure, the update of all firmware is suppressed.

8.1.9 Ensuring Proper Operation After a Firmware Update

Supported Hardware

When an improvement is made to the hardware such as Motherboard unit, CPU/Memory Board unit, CPU module or XSCF Unit, the firmware update must be performed by using the XCP data which supporting the new hardware function.

See the latest version of the Product Notes for your server, for specific information about minimum softwares and firmware requirements, when new hardware is supported.

Note - If data for an older version of XCP is used for the firmware update of a system that is running, system operation cannot be guaranteed.

Making Versions Agree With Each Other

XSCF automatically sets firmware versions to match each other as follows:

When power to a domain is turned on, the versions on the system boards in the domain are automatically set to match each other.

When a system board is moved to a domain by the DR function, the version on the board is automatically matched to the version in the destination domain.

When a maintenance component is replaced or added, the version is automatically matched to the version of the firmware currently running.

8.1.10 Firmware Update Procedure

TABLE 8-2 outlines the firmware update tasks. Detailed descriptions are provided at the link destinations of each task item.

Note - Depending on the XCP version and system configuration, firmware update procedures and requirements might be slightly different. For information about specific firmware update procedures and requirements, refer to the Product Note about your server.

TABLE 8-2 Firmware Update Tasks
Firmware Update Task Item	Outline	Task time
Updating XCP From the Network	Obtain the XCP files from the appropriate web site, and use XSCF to import XCP. Use XSCF Web or the XSCF Shell for the firmware update. Reboot the system for application to all domains. Note: If the system has redundant XSCF Units, the XSCF Units are switched while the update is in progress.	In the system with a XSCF Unit; About 45 minutes In the system with redundant XSCF Units; About 120 minutes (Excludes the time for component replacement work)
Updating XCP From External Media (When the XCP file is copied onto external media such as a CD-ROM.)	Imports XCP from the CD-ROM disk by using XSCF. Use the XSCF Web or the XSCF Shell for the firmware update. The rest of the task is the same as updating XCP from the network.	In the system with a XSCF Unit; About 45 minutes In the system with redundant XSCF Units; About 120 minutes (Excludes the time for component replacement work)
Confirming That the OpenBoot PROM Firmware is Updated When a CMU/MBU Is Added or Replaced	The firmware update is automatically performed. Confirm the version of the OpenBoot PROM firmware in the update target domain. This function is available when you are using the M4000/M5000/M8000/M9000 servers. In the M3000 server, when a Motherboard unit is replaced, the operator must match the number of the firmware versions.	About 5 minutes (Excludes the time for component replacement work)
Confirming That the XSCF Firmware is Updated When an XSCF Unit Is Replaced (There Are Redundant XSCF Units)	The firmware update is automatically performed by using the maintenance guidance for FE. Confirm the version of the updated XCP. This function is available when you are using M8000/M9000 servers. Note: When a component is replaced in the state of main line switch off (the cold replacement), the firmware is not updated automatically. The operator must match the number of the versions.	About 5 minutes (Excludes the time for component replacement work)
Confirming That the XSCF Firmware Is Updated When the XSCF Unit Is Replaced (in a System With a Single XSCF Unit or Both Replacement in a System With Redundant XSCF Units)	The firmware is not updated automatically. The operator must match the number of the firmware versions. This function is available when you are using M4000/M5000/M8000/M9000 servers.	In the system with a XSCF Unit; about 20 minutes In the system with redundant XSCF Units; about 40 minutes (Excludes the time for component replacement work)
Confirming That the XSCF Firmware Is Updated When the MBU Is Replaced (in the M3000 server)	The firmware is not updated automatically. The operator must match the number of OpenBoot PROM and XSCF firmware versions. This function is available when you are using M3000 servers.	About 20 minutes (Excludes the time for component replacement work)

Updating XCP From the Network

File preparation:

1. Download the XCP files from a public site to an arbitrary folder on a personal computer or workstation connected to the server.

In the public site, there will be the XCP file (the firmware program (tar.gz)), the MIB definition file, and a document concerning the XCP. There are three types of firmware program files (tar.gz) as described below:

The firmware program for M3000 servers (the file name begins with IKXCP).

The firmware program for M4000/M5000 servers (the file name begins with FFXCP).

The firmware program for M8000/M9000 servers (the file name begins with DCXCP).

When you import the firmware (the XCP importing), choose the appropriate firmware program for your system.

2. Confirm the XCP version.

To confirm the XCP version, see the figure of a four-digit number that exists in the firmware program (tar.gz) file name. The latest XCP information is released on a web site. To obtain the URL of the web site, see the description of the firmware download in the Product Notes for your server.

Command operation

1. Log in to XSCF Shell.

2. Import XCP.

a. Use the getflashimage(8) command to confirm the list of the firmware program files (tar.gz) that are still on the system.

XSCF> getflashimage -l
Existing versions:
        Version                Size  Date
        FFXCP1080.tar.gz   51298982  Thu Jan 15 20:09:09 JST 2009

b. Use the getflashimage(8) command to specify the firmware program (tar.gz) file and import XCP to the system.
(The update is not performed at this point.)

<Example> Login a remote ftp server specifying the user name and host name that requires authentication password, then, import the new 1082 version firmware program (tar.gz). 
XSCF> getflashimage -u yyyyy ftp://imgserver/img/FFXCP1082.tar.gz 
Existing versions:
        Version                Size  Date
        FFXCP1080.tar.gz   51298982  Thu Jan 15 20:09:09 JST 2009
Warning: About to delete old versions. 
Continue? [y|n]: y 
Removing FFXCP1080.tar.gz. 
Password: [not echoed] 
  0MB received
  1MB received
  2MB received
  ...
  40MB received
Download successful: 41470 Kbytes in 46 secs (940.250 Kbytes/sec)
MD5: 683fb5240e4937948dd6ad83b4a99669

c. If complete message, "Download successful: ..." and "MD5: ..." are displayed, the XCP import has ended. Use the getflashimage(8) command with -l option to confirm the imported version.

Note - After importing, if “Error: File is invalid or corrupt” message is displayed, it means the XCP file that imported is not a correct file. There is a possibility of either obtaining an illegal XCP file or that the XCP file was falsified by unauthorized access after the customer downloaded the XCP file.

3. Perform the firmware update.

The XSCF firmware is downloaded and applied, and the OpenBoot PROM firmware is downloaded.

a. Use the version(8) command to display the current firmware version.

XSCF> version -c xcp -v
XSCF#0 (Active)
XCP0 (Current): 1080
OpenBoot PROM : 02.07.0000
XSCF          : 01.08.0001
XCP1 (Reserve): 1010
OpenBoot PROM : 02.07.0000
XSCF          : 01.08.0001
OpenBoot PROM BACKUP
#0: 02.03.0000
#1: 02.07.0000

b. Use the flashupdate(8) command to confirm whether to be able to update the new firmware version. If the "XCP update is possible with domains up" message is displayed, you can update the firmware

XSCF> flashupdate -c check -m xcp -s 1082

Note - If the XCP firmware version is 1050 or before, and if the “XCP update enabled during system powered on state” message is displayed, you can update the firmware.

Note - If the "XCP update requires all domains to be rebooted (Previous OpenBoot PROM update has not been completed)" message is displayed, you cannot update the firmware because previous OpenBoot PROM firmware update has not been completed. Perform the firmware update again after rebooting all domains.

c. Use the flashupdate(8) command to update the firmware.
In the system with redundant XSCF Units, before updating the firmware, perform the showhardconf(8) command and check the Status of the XSCF Unit 0/1, which is Active or Standby.

<Example> Update XCP from an early version, 1080, to the newer 1082 version.
XSCF> flashupdate -c update -m xcp -s 1082
The XSCF will be reset. Continue? [y|n] :y
XCP update is started (XCP version=1082:last version=1080)
OpenBoot PROM update is started (OpenBoot PROM version=02090000)
OpenBoot PROM update has been completed (OpenBoot PROM version=02090000)
XSCF update is started (XSCFU=0,bank=1,XCP version=1082:last version=1080)
XSCF download is started (XSCFU=0,bank=1,XCP version=1082:last
version=1080, Firmware Element ID=00:version=01080001:last version=01080000)
XSCF download has been completed (XSCFU=0,bank=1,XCP version=1082:last
version=1080, Firmware Element ID=00:version=01080001:last version=01080000)
...
XSCF download is started (XSCFU=0,bank=1,XCP version=1082:last
version=1080, Firmware Element ID=07:version=01080004:last version=01080000)
XSCF download has been completed (XSCFU=0,bank=1,XCP version=1082:last
version=1080, Firmware Element ID=07:version=01080004:last version=01080000)
XSCF update has been completed (XSCFU=0,bank=1,XCP version=1082:last
version=1080)
XCP update is started (XCP version=1082:last version=1080)
OpenBoot PROM update is started (OpenBoot PROM version=02090000)
OpenBoot PROM update has been completed (OpenBoot PROM version=02090000)
XSCF update is started (XSCFU=0,bank=0,XCP version=1082:last version=1080)
XSCF download is started (XSCFU=0,bank=0,XCP version=1082:last
version=1080, Firmware Element ID=00:version=01080001:last version=01080000)
XSCF download has been completed (XSCFU=0,bank=0,XCP version=1082:last
version=1080, Firmware Element ID=00:version=01080001:last version=01080000)
...
XSCF download is started (XSCFU=0,bank=0,XCP version=1082:last
version=1080, Firmware Element ID=07:version=01080004:last version=01080000)
XSCF download has been completed (XSCFU=0,bank=0,XCP version=1082:last
version=1080, Firmware Element ID=07:version=01080004:last version=01080000)
XSCF update has been completed (XSCFU=0,bank=0,XCP version=1082:last
version=1080)
XSCF is rebooting to update the reserve bank

Note - The display might be different according to XCP version and system configuration.

At this time, the XSCF will reset and the XSCF session will disconnect, so please connect the XSCF again. Only the application of the XSCF firmware is completed.

Note - The work described below applies to a system with redundant XSCF Units.

i) Before updating the firmware, perform the showhardconf(8) command and check the Status of the XSCF Unit 0/1, which is Active or Standby.

ii) Perform the firmware update in order, beginning with the standby side and then the active side automatically. After the update on the standby side is completed, the active and standby sides are switched. At this time, the XSCF reset is done and the XSCF session is disconnected.

iii) Re-connect the XSCF and log in again.

iv) XSCF firmware update is completed.

v) When the firmware update completes, the active and the standby states of the XSCF unit have become the opposite of original state. For instance, if the firmware update is executed on XSCFU#0, when completing the command, XSCFU#1 would become the active side. To switch the XSCF, execute the switchscf (8) command. To confirm the switching between XSCFs, execute the showhardconf (8) command and check the Status of the XSCF Unit 0/1, which is Active or Standby.
<Example>
XSCF> switchscf -t StandbyThe XSCF unit switch between the Active and Standby states. Continue? [y|n] :y

d. To confirm that the XSCF firmware update has finished, use the showlogs(8) command with the monitor option. Confirm no abnormality is found during the update. If the "XCP update has been completed" message is displayed in each XSCF Unit, the firmware update has completed.


XSCF> showlogs monitor
:
Jun 20 07:25:48 FF1-1-0 monitor_msg: SCF:XCP update has been completed (XCP version=1082)

4. To complete the update of the OpenBoot PROM firmware, restart the domain.

5. Confirm that the version of the system firmware that is running is that of the firmware applied at the XSCF Shell command line by using the version(8) command.

Web browser operation

For information about using the XSCF Web, see Chapter 9.

1. Start the XSCF Web.

https://manual.host /(Specify the host name or IP address of XSCF)

2. The login window of the XSCF Web console is displayed. Please enter an XSCF user account and password.

3. Select [Utility]-[Firmware Update] to display the menu.

4. Import XCP.

a. Display the XCP import window.

b. Following instructions in the window, specify the firmware program (tar.gz) file and import XCP to the system.
(The update is not performed at this point.)

5. If complete message is displayed, the XCP importing has ended. Perform the firmware update.

The XSCF firmware is downloaded and applied, and the OpenBoot PROM firmware is downloaded.

a. Display the XCP update window. (The version of the imported XCP firmware and the version of the firmware currently running has already displayed in the screen.)

b. Make a selection for the firmware version check. Confirm whether or not it is possible to update to the new firmware version.

c. Make a selection for the firmware update. Following instructions in the window, update the firmware.
At this time, the XSCF will reset and the XSCF session will disconnect, so please connect the XSCF again. Only the application of the XSCF firmware is completed.

Note - In a system with redundant XSCF Units:

i) Perform the firmware update in order, beginning with the standby side and then the active side automatically. After the update on the standby side is completed, the active and standby sides are switched. At this time, the XSCF reset is done and the XSCF session is disconnected.

ii) Re-connect the XSCF and log in again.

iii) XSCF firmware update is completed.

iv) To switch the XSCF, select [Utility]-[Switch Over].

d. Refer to the Monitor message log to confirm that the XSCF firmware update has finished.

6. To complete the update of the OpenBoot PROM firmware, restart the domain.

7. Confirm that the version of the system firmware that is running is that of the firmware applied from the XSCF Web console.

Updating XCP From External Media

1. Insert the external media with the XCP file into the drive. Insert the external media into a drive connected to the network that XSCF has access to. If necessary, copy the XCP file to an arbitrary folder.

2. Confirm the XCP version in the XCP file (tar.gz) of external media. The latest XCP information is released on external media or a web site. To obtain the URL of the web site, see the description of the firmware download in the Product Notes for your server.

3. Perform the same steps in Updating XCP From the Network.

Confirming That the OpenBoot PROM Firmware is Updated When a CMU/MBU Is Added or Replaced

Note - This function is not available when you are using the M3000 server. When a MBU is replaced, you must match the number of the firmware versions. See Confirming That the XSCF Firmware Is Updated When the MBU Is Replaced (in the M3000 server)

1. After a CMU/MBU addition or replacement task and an allocation to a domain have completed, turn on power to the domain. The update of the OpenBoot PROM firmware is automatically performed at this time (automatic matching of versions).

2. Confirm that the firmware version of the target domain agrees with the version of the XSB firmware allocated to the added or replacement CMU/MBU.

Command operation

a. Execute the version(8) command, and confirm it.

XSCF> version -c cmu 
DomainID  0: 02.09.0000
DomainID  1: 02.09.0000
      :
DomainID  3: 02.09.0000

Web browser operation

a. Display the "Firmware Update" menu.

b. Display the OpenBoot PROM firmware version, and confirm it.

Confirming That the XSCF Firmware is Updated When an XSCF Unit Is Replaced (There Are Redundant XSCF Units)

a. Operation in State of the Input Power On

1. After doing an XSCF Unit replacement task by using the maintenance guidance for FEs, the version of the XSCF firmware is automatically set to match the appropriate firmware.

2. Confirm the firmware version of replaced XSCF Unit.

Note - When a component is replaced in the state of input power off (a cold replacement), the firmware is not updated automatically. The operator must match the number of versions.

b. Operation in State of the Input Power Off

The procedures below explain the firmware update when the replacement of one XSCF Unit is done. When you replace both XSCF Units, see "Confirming That the XSCF Firmware Is Updated When the XSCF Unit Is Replaced (in a System With a Single XSCF Unit or Both Replacement in a System With Redundant XSCF Units)".

Command operation

1. Turn on power to the server after completing XSCF Unit replacement task.

2. If the replacement unit and the replaced unit have different versions, a message is displayed such as the following.

XCP version of Panel EEPROM and XSCF FMEM mismatched,
 
        Panel EEPROM=1080, XSCF FMEM=1090

3. Confirm the firmware version by using the version(8) command. If you find an unmatched version of the replaced XSCF Unit, make the replaced XSCF unit version match the current system version using the flashupdate(8) command.

XSCF> version -c xscf
XSCF#0 (Active ) 
01.08.0001(Reserve) 01.08.0001(Current) 
XSCF#1 (Standby) 
01.08.0001(Current) 01.08.0001(Reserve)

XSCF> flashupdate -c sync

4. Confirm the firmware version again.

Note - The sync option is only used at the active XSCF Unit. When the firmware on the standby site is applied, the XSCF reset of the standby site is done. Then even if the XSCF session is disconnected, the active XSCF Unit has no impact on.

Web browser operation

1. Repeat Step 1 and Step 2 of the Command operation. Then login to the XSCF on the XSCF Web.

2. Display the firmware update menu.

3. Display the XSCF firmware version, and confirm it.

4. If you find an unmatched version of the replaced XSCF Unit, select the XCP sync. In the window, match the version of the current firmware.

5. Display the XCP version and XSCF firmware version, and confirm them.

Confirming That the XSCF Firmware Is Updated When the XSCF Unit Is Replaced (in a System With a Single XSCF Unit or Both Replacement in a System With Redundant XSCF Units)

1. Turn on power to the server after completing the XSCF Unit replacement task.

2. If the replacement unit and the replaced unit have different versions, a message is displayed such as the following. In this case, the firmware is not updated automatically. The operator must perform a update to match the number of the firmware versions.

XCP version of Panel EEPROM and XSCF FMEM mismatched,
 
        Panel EEPROM=1080, XSCF FMEM=1090

3. When you update, follow the procedure in Updating XCP From External Media or Updating XCP From the Network to update XCP, and confirm the version.

Confirming That the XSCF Firmware Is Updated When the MBU Is Replaced (in the M3000 server)

1. Turn on power to the server after completing the Motherboard unit replacement task.

XCP version of Panel EEPROM and XSCF FMEM mismatched,
 
        Panel EEPROM=1080, XSCF FMEM=1090

3. When you update, follow the procedure in Updating XCP From External Media or Updating XCP From the Network to update XCP, and confirm the version.

8.1.11 If an Error Occurs During XSCF Firmware Update

If the system hangs or any of the messages shown below is output during the firmware update, the XSCF Unit on the faulty side cannot be used and is treated as a faulty component.

Try the firmware update again when an error occurs while updating the XSCF firmware. The second attempt may succeed where the first failed.

Case where the XSCF Unit is redundantly configured (on M8000/M9000 servers)

Error involving a failed write or reset operation on the standby or active side

Case where there is one XSCF Unit (on M3000/M4000/M5000 servers)

Error involved a failed write or reset operation

8.1.12 Frequently Asked Questions

Q: Is there any problem in executing reboot twice when applying the OpenBoot PROM firmware?

There is no problem.

Q: In cases with redundant XSCF Units, why are the XSCF Units on the active and standby sides switched while the update is in progress?

XSCF on the active side has control for updating firmware on the XSCF Unit on the standby side. When the firmware update of the standby side is completed, the standby side that has new firmware is switched to the active side. Then, the firmware on the standby XSCF Unit (formerly the active XSCF Unit) is updated in turn.

Q: Can the update of the OpenBoot PROM firmware be applied to all domains at one time?

Yes, it can. By specifying all domains in the poweron(8) command, the new firmware can be applied simultaneously to all the domains.

8.2 Collecting XSCF Logs

Log information for the XSCF firmware is used for investigating hardware or firmware faults. XSCF log information can be viewed by the system administrator, domain administrators, and FEs.

8.2.1 Log Types and Reference Commands

You can view XSCF log information from the XSCF console after logging in to XSCF. When the log archiving function is enabled, logs are stored on the archive host (see Section 8.2.2, Method of Collecting the Log Information). The logs include the following types:

Logs containing fault information

Other logs

Logs Containing Fault Information

If a failure occurs in the system, the system and XSCF collects some fault information logs. TABLE 8-3 lists the types of logs that are collected, descriptions, and reference methods. For details on commands, see the XSCF Reference Manual and the man page.

TABLE 8-3 Logs Containing Fault Information
Type	Description	Size (Entry Size)	Output/Display Destination (Standard Storage Period) Archiving	Reference Method
Fault management log (FM log)	Log for error events, notifications and faults occurred in server. The display form of the log is interchangeable on the Oracle Solaris OS.	About 200 generations (Variable-length)	Domain, XSCF (Amount for about 1 month) Archived (Note)	`fmdump`(8) `fmdump`(1M)
XSCF error log	Log for error events, notifications and faults occurred in server. Log information is the same as the FM log. The display form of the log is peculiar to the platform.	About 200 generations (Variable-length)	Domain, XSCF (Amount for about 1 month) Archived	`showlogs`(8) XSCF Web
System log	Log for recording output Oracle Solaris OS messages. If a failure occurs, an outline of the failure is output.		Domain	Oracle Solaris OS commands are used to refer to the logs.
Monitor message log	Log for recording messages, from the XSCF firmware, reporting abnormalities	512KB, About 10000 lines	XSCF	`showlogs`(8) XSCF Web

Note - Archived: Indicates log entries are replicated (backed up) on the archive host, if log archiving is enabled. The logs displayed by the Oracle Solaris OS commands are not archived.

Other Logs

TABLE 8-4 outlines other logs collected for XSCF log information.

TABLE 8-4 Other Logs
Type	Description	Size (Entry Size)	Standard Storage Period Archiving	Reference Method
Power log	Log for recording power events of the main unit	1920 generations (M8000/M9000 servers) 720 generations (M3000/M4000/M5000 servers) ( x16B )	About 1 month Archived	`showlogs`(8) XSCF Web
Event log	Log for recording system operations, operator panel operations, and events reported to the operating system	4096 generations ( x48B )	About 1 month Archived	`showlogs`(8) XSCF Web
Console log	Log that is recorded as a console message log if the XSCF console is specified as the output destination of the Oracle Solaris OS console. When the input power is turned off, the log is clear.	512KB /domain, About 10000 lines/domain	Amount for about 1 week Archived	`showlogs`(8) XSCF Web
Panic log	Console log for a panic occurrence	64KB (About 1200 lines)	Amount for 1 time Archived	`showlogs`(8) XSCF Web
IPL log	Log for the period from power on to completion of Oracle Solaris OS startup	32KB/domain, About 600 lines/domain	Amount for 1 time Archived	`showlogs`(8) XSCF Web
Audit log	Log for XSCF audits	4MB	About 1 month Archived	`viewaudit`(8) XSCF Web
Active Directory log	Log for Active Directory authentication and authorization diagnostic messages	250KB (About 3000 lines)	Not Archived	`showad`(8) XSCF Web
LDAP/SSL log	Log for LDAP/SSL authentication and authorization diagnostic messages	250KB (About 3000 lines)	Not Archived	`showldapssl`(8) XSCF Web
Temperature and humidity history log	Log containing a history of the temperature and humidity of the main unit environment The humidity history is displayed only in the high-end server.	16384 generations (x16B) (Every 10 minutes)	About 6 months Archived	`showlogs`(8) XSCF Web

Note - The table is read in the same way as TABLE 8-3. For examples of logs, see Appendix B.

Note - When the log becomes full, the log data is overwritten, beginning with the oldest log.

8.2.2 Method of Collecting the Log Information

The field engineers and authorized service personnel collect the log information. Also, the system administrator might collect the log information.

To download the log information, execute the snapshot(8) command with some options in the XSCF Shell. When the command is executed, all XSCF log information is saved at the specified location.

Note - The download information by using the snapshot(8) command does not include log archives. The archived logs are stored on the archive host. The log archives can be accessed by logging in to the archive host.

The log can be saved in the device using one of the following two methods.

The configuration information can be saved and restored when a USB device has been connected to the USB connector mounted on the XSCF Unit front panel of the M4000/M5000/M8000/M9000 servers or on the rear panel of the M3000 server.

The log data is transmitted through the network with an encryption protocol.

Note - The USB device should only be formatted using the FAT32 file system. Please ask authorized service personnel about the USB capacity and the handling of USB devices.

Note - The snapshot(8) command can encrypt collected data by specifying an option. If you collect the data, be sure to ask the authorized service personnel to collect only the log file, the encryption information, and the method of sending the log file.

The following is the procedure for saving logs.

Saving the Logs by Connecting the USB Device for Exclusive Use to the Front Panel of the XSCF Unit

Web browser operation

1. Select the snapshot (Note) menu for saves of the logs menu and display the saving operation page.

2. Connect a USB device to the USB connector mounted on the XSCF Unit panel.

3. In the window, select the USB device on the XSCF Unit panel.

4. Set the encryption password used for encrypting the output log file.

5. Execute the data transfer. When the data transfer is complete, please contact authorized service personnel.

Note - The snapshot menu may be displayed as “Data Collector”.

Command operation

1. Connect a USB device to the USB connector mounted on the XSCF Unit panel.

2. Perform the snapshot(8) command and specify the local USB device on the XSCF Unit for the output file (see Note).

XSCF> snapshot -d usb0

3. When the data transfer is complete, please contact authorized service personnel.

Note - For details on using the snapshot(8) command, including how to enable encryption, see the man page or the XSCF Reference Manual.

Saving the Logs to a Specified Target Directory Over a Network

Web browser operation

1. Select the snapshot menu for saving the log menu and display the saving operation page.

2. In the window, select the download button and specify the target directory.

3. Execute the data transfer. When the data transfer is complete, please contact authorized service personnel.

Command operation

1. Perform the snapshot(8) command using a public key, specifying the target directory, and specifying the encryption password for the output file.

XSCF> snapshot -t joe@jupiter.west:/home/joe/logs/x
:

2. When the data transfer is complete, please contact authorized service personnel.

Note - For detail of snapshot(8) command, including how to enable encryption, see the man page or the XSCF Reference Manual.

Caution - IMPORTANT- When the XSCF Unit is the redundant configuration, log in to the standby side and collect the log in the same way.

The form of the collected log file is as follows.

File name :	The file name is generated automatically at XSCF IP address and the log taking out time. So, the log file cannot be generated in the file name of the user specification.
File format :	zip