Oracle FS1-2 Flash Storage System
 

PLA-Support>Sun Systems>DISK>Flash Storage>SN-EStor: FSx
 

In this Document

Symptoms

Cause

Solution

References

Created from <SR 3-10166688022>

Applies to:

Symptoms

After upgrading the Flash Storage System (FS1) from 6.1.3 to 6.1.4, the serial number and model for the Pilot was missing. In the following example, this was the Pilot 2.

Cause

The file /var/state/PilotInfo.xml on the Pilot 2 was not correctly refreshed during the reboot triggered by the upgrade.

Here is an example for this file while the problem was existing:

Oracle Internal Only

There was no Pilot VPD (Vital Product Data) capability until 6.1.0 build 142. That version introduced the `ipmitool sunoem cli force "show /system"` used to gather the information, but put the 4 XXXX in the raw file.
If the ipmitool command failed [which it can since pilot_config is not the only user of ILOM data at boot] you would have the 4 XXXX syndrome.
This method of constructing the VPD file /var/state/PilotInfo.xml continued up through restricted release 6.1.3.

Release 6.1.4 changed the template used to construct the VPD file. So any system that is built at 6.1.4 or higher would not be exposed.

Solution

If you encounter this problem, we recommend you to proceed with the following steps:

1. Create a Service Request with Oracle Support. (Refer to <Document 1544005.2> My Oracle Support 'How-to' Series: How to validate your access to create a HW SR, SW SR or Cloud SR and How to Update your SR)
2. Collect a manual log set from your FS1 and send it to Oracle. (Refer to <Document 1943289.1> FS System: How to Attach a Manual Log Bundle to an Existing MOS Service Request)

Oracle Internal Only

Instructions for the Oracle support engineer:

1. Please link your SR to the unpublished <Bug 20409288>.
2. You will need to ssh to the affected Pilot.
   
   
   • If ssh is disabled on the FS1, you can use the following command to enable it:
     
     
     # fscli login -u administrator -oracleFs [FS1 ip address]
     # fscli system -modify -enableSsh [number of minutes]
      
3. Backup the file /var/state/PilotInfo.xml:
   
   
   # cd /var/state/
   # mv PilotInfo.xml Bad_PilotInfo.xml
    
   
   
4. Disable call-home:
   
   
   # fscli call_home -modify -disableEventTrigger
     
   
   
5. Reboot the Pilot:
   
   
   # init 6
    
   
   
6. Once the Pilot is back online, confirm that the serial number and model are correctly reported in the GUI and CLI:
   
   
   • For the CLI, you can use the following command:
     
     
     # fscli pilot -list
      
     
     
7. If the problem is resolved, you can remove the file /var/state/Bad_PilotInfo.xml in the pilot, and re-enable call-home with the following command:
   
   
   # fscli call_home -modify -enableEventTrigger
     

References

This solution has no attachment