How to update product serial number on systems which implement Top Level Identifier functionality

Asset ID:	1-71-1280913.1
Update Date:	2011-04-06
Keywords:

Solution Type Technical Instruction Sure

Solution 1280913.1 : How to update product serial number on systems which implement Top Level Identifier functionality

Applies to:

Sun Fire X4170 M2 Server - Version: Not Applicable and later   [Release: N/A and later ]
SPARC T3-1 - Version: Not Applicable and later    [Release: N/A and later]
SPARC T3-4 - Version: Not Applicable and later    [Release: N/A and later]
SPARC T3-1B - Version: Not Applicable and later    [Release: N/A and later]
SPARC T3-2 - Version: Not Applicable and later    [Release: N/A and later]
Information in this document applies to any platform.

Goal

Oracle Confidential (INTERNAL). Do not distribute to customers

Description
This document describes the Top Level Identifier (TLI) functionality and how this functionality is used to update product serial numbers on systems which implement the feature.

Solution

What is Top Level Identifier?
Top Level Identifier functionality was created to provide a common method to store and update FRUID top level identifier information, of primary importance being the product serial number. On systems prior to TLI systems, there were a number of different tools used to update serial numbers depending on the platform. This led to confusion about what tool to use, as well as causing unwarranted difficulty to Field Service since most of these historical tools required an escalation mode password since the release of ILOM 3.x. TLI addresses this by providing automatic updating of product serial numbers in certain cases, and a service mode command for updating the product serial number in most remaining cases. Only in extraordinary circumstances is an escalation mode password required.

When TLI is implemented, physical locations (referred to as containers) are determined on the product to store the TLI data. If a product is able to provide it, the desire is at least three containers represented by a Primary and two Backup containers. The location for the Primary container is intended to be on a FRU which has lower likelihood of replacement. The location for Backup containers is intended to be different from the Primary and from each other if possible. The goal of this is to reduce the opportunity for all, or a majority, of containers being replaced at the same time. The number of Backup containers must be even to declare a majority, which means that if a product does not provide two backups, automatic updating can not be performed, and the service mode command will need to be utilized.

Automatic Product Serial Number Update
If the product provides a Primary container and at least two Backup containers on distinct FRUs, and the FRU containing one of the Backup containers is replaced, then the product is able to declare a majority and automatically update the product serial number into the replacement FRU. When the replacement FRU is brought into service, the Backup container will be updated automatically and no further Service action is required to update the product serial number.

You can use the showpsnc command in the Restricted service shell to display the TLI container locations and contents. See knowledge article 1302296.1 for more details on how to enter and use Restricted shell.

[(restricted_shell) t3-1-sp:~]$ showpsnc

Primary: fruid:///SYS/PDB

Backup 1: file:///persist/psnc_backup1.xml

Backup 2: fruid:///SYS/CONNBD



Element           | Primary           | Backup 1          | Backup 2          

------------------+-------------------+-------------------+-------------------

Container Status    Valid               Valid               Valid              

PPN                 4702897-1           4702897-1           4702897-1          

PSN                 1039BDR07E          1039BDR07E          1039BDR07E         

MACADDR             00:21:28:A6:7A:FA   00:21:28:A6:7A:FA   00:21:28:A6:7A:FA  

HOSTID              85a67afa            85a67afa            85a67afa

This example is from a T3-1 system where there is a Primary and two Backup containers on three separate FRUs.

If the FRU containing the Primary container is replaced, the system will not be able to declare a majority even if two Backup containers are available. In this situation the following warning will be seen on the Web interface and just after login to the CLI interface:

Warning: Product identification data missing. System may not function properly. Service must update product identification data. Contact Service immediately.

In this scenario you will follow the process below in Manual Product Serial Number Update.

Manual Product Serial Number Update
In other scenarios where there is at least one container which still contains valid TLI information, a service mode command copypsnc can be used to update the product serial number. See knowledge article 1019946.1 for more details on how to enter service mode.

-> copypsnc
Number of arguments is incorrect.
Usage:
copypsnc: <src> <dest>
where <src> is PRIMARY|BACKUP1|BACKUP2
      <dest> is PRIMARY|BACKUP1|BACKUP2
PRIMARY: fruid:///SYS/PDB
BACKUP1: file:///persist/psnc_backup1.xml
BACKUP2: fruid:///SYS/CONNBD

-> copypsnc BACKUP1 PRIMARY

The copypsnc command produces no output upon success.

Last Resort Product Serial Number Update
If all TLI containers on all FRUs are replaced, or the system only has a single container by design as indicated by showpsnc, or there is some need to change the product serial number to something other than is represented by the current TLI containers, there is an escalation mode command setpsnc which can be utilized. See the same knowledge article above for more details on how to enter escalation mode.

bash-2.05b# setpsnc -h
Usage: setpsnc [OPTIONS] [PRIMARY|BACKUP1|BACKUP2]
Options:
    -h/--help
    -s/--psn <product serial number>
    -p/--ppn <product part number>
    -m/--macaddr <MAC address>
    -i/--hostid <HOSTID>

setpsnc with no options will update the primary container by first presenting to you the current values of the data, where you can update, or press enter to accept what is there with no changes.

bash-2.05b# setpsnc
Reading fruid:///SYS/MB...
PPN ['541-4197-04']: 
PSN ['1026NND09J']: 
MACADDR ['00:21:28:7F:66:34']: 
HOSTID [0x857f6634]: 

PPN                 541-4197-04        
PSN                 1026NND09J         
MACADDR             00:21:28:7F:66:34  
HOSTID              857f6634           
Is the above correct? (y|n) [n]: y
Writing fruid:///SYS/MB...
You will need to reboot the SP for these changes to take fully effect.
bash-2.05b#

You can specify a specific container as follows:

bash-2.05b# setpsnc backup1
Reading file:///persist/psnc_backup1.xml...
PPN ['541-4197-04']: 
PSN ['1026NND09J']: 
MACADDR ['00:21:28:7F:66:34']: 
HOSTID [0x857f6634]: 

PPN                 541-4197-04        
PSN                 1026NND09J         
MACADDR             00:21:28:7F:66:34  
HOSTID              857f6634           
Is the above correct? (y|n) [n]: y
Writing file:///persist/psnc_backup1.xml...
You will need to reboot the SP for these changes to take fully effect.
bash-2.05b#

or you can just update a specific data in a specific container as follows:

bash-2.05b# setpsnc -s 1026NND09J backup1
Reading file:///persist/psnc_backup1.xml...

PPN                 541-4197-04        
PSN                 1026NND09J         
MACADDR             00:21:28:7F:66:34  
HOSTID              857f6634           
Writing file:///persist/psnc_backup1.xml...
You will need to reboot the SP for these changes to take fully effect.
bash-2.05b#

Attachments

This solution has no attachment