Oracle Serial Number in EEPROM (SNEEP) provides a software-accessible Chassis Serial Number (CSN) for all Oracle Solaris hardware platforms.
SNEEP uses the system EEPROM for persistent storage of the Chassis Serial Number and other important user-defined data such as asset information, contract ID, or the serial numbers of attached storage devices.
The presence of the software-accessible serial number and other service-related information can significantly simplify activities related to system service and asset management.
Without SNEEP, only a subset of the Solaris-based hardware platforms have a mechanism to maintain a software-accessible serial number. Among those platforms, there is a wide variety of mechanisms for this, making consistent access to this information difficult.
SNEEP provides one simple and consistent interface to the management of this information on all Solaris hosts, domains, and zones. SNEEP can also reference and maintain the serial number in the configuration files for the Oracle Explorer Data Collector.
The following topics are discussed:
Additional Oracle SNEEP Resources
You can find additional information about Oracle SNEEP in the My Oracle Support knowledgebase, including:
Frequently Asked Questions about SNEEP (Doc ID 1294842.1)
Log in to My Oracle Support at:
https://support.oracle.com
To access the man page of Oracle SNEEP, you can add the location of the SNEEP man page to the MANPATH environment variable, or you can indicate the location of the SNEEP man page explicitly in the man command. The man page is located in:
For Solaris 8, 9, and 10, the path is:
/opt/SUNWsneep/man
For Solaris 11 and higher, the path is:
/usr/lib/sneep/man
The man page for Oracle SNEEP is in section 1m. For example, to access the SNEEP man page on Solaris 11, run:
man -M /usr/lib/sneep/man -s 1m sneep
Or, if the MANPATH environment variable is set, the command would be:
man -s 1m sneep
SNEEP is included in the Oracle Services Tools Bundle (STB). See Download and Install Oracle Services Tools Bundle for instructions to download and install STB.
For support to SNEEP, you can submit a service request through My Oracle Support:
https://support.oracle.com
If your hardware includes the serial number in its EEPROM, then you can view it with the following command:
sneep -t hostname,serial,model
If your hardware does not already store the serial number in EEPROM, then you can use SNEEP to include it. You will need to first obtain the serial number and manually enter it into EEPROM.
On most Sun hardware, the serial number is always located on a physical tag somewhere on the machine. The Sun System Handbook tells exactly where to find it for all Sun machines. The handbook can be accessed at My Oracle Support (click the Knowledge tab and then select Sun System Handbook in the left-hand navigation):
https://support.oracle.com
The data sheet (usually yellow or orange), which was delivered with your machine, shows the serial number and system configuration.
WARNING:
The decimal number reported in the SPARC boot banner as the serial number when the machine is powered on is NOT the true serial number - it is the decimal form of the "host id". The host id is ordinarily seen in hexadecimal as the output of the Solaris hostid command.
Many x86/x64 platforms provide hardware support for the serial number which is accessible using smbios or ipmitool. If possible, SNEEP will get the serial from these data sources and will use it to reload the simulated EEPROM automatically.
While x86 PC platforms do not have an EEPROM, Solaris x86 has an EEPROM emulation which is managed in a file by the eeprom command:
/boot/solaris/bootenv.rc
By default, the simulated EEPROM does not have an nvramrc variable, but eeprom is willing to create one for SNEEP.
Because Solaris has this simulated EEPROM, you can use SNEEP for the same tags and in the same way that you use it on other systems. Just be aware that the values are not really stored in EEPROM and are "lost" if the file system is badly damaged or recreated.
If you have been using Oracle Explorer Data Collector, then the SNEEP backup file will be saved as part of any Explorer files which you may have archived. Restoring that file (etc/default/SUNWSNEEP) will immediately allow SNEEP to retrieve the values and reload the simulated EEPROM.
You can use SNEEP to retrieve serial number information or you can use SNEEP to add such information to EEPROM. You do not need root access to retrieve the information; however, you may need root or superuser access to add the information to EEPROM, depending on the hardware.
To retrieve serial number information from EEPROM using SNEEP, run:
sneep
Follow the procedures below to use SNEEP to store serial number and other information in EEPROM.
Note:
SNEEP does not validate the serial number, manufacturing date and location, etc., information. However, it does make an effort to ensure that it is approximately the right length and does not have any obviously invalid characters in it.SNEEP uses the Open Boot Prom (OBP) nvramrc variable to store a specially formatted print command for each tag/value pair. These commands may look odd because the OBP programming language is FORTH and the <print> command in FORTH is <.">. For example:
." ChassisSerialNumber ABCD1234 " cr
The eeprom command is used very carefully to store and retrieve these strings, taking care to preserve any other nvramrc contents.
It is possible to use the OBP oem-banner variable to store the serial number or other information. This variable has the advantage that it is not erased when the OBP defaults are restored, but it has very limited size. The limited size makes it difficult to manage multiple data items.
In addition, when the oem-banner variable is set, the system administrator loses the ability to get the Ethernet MAC address from the default OBP banner. This can be a very real disadvantage when working with a new system, or trying to debug a network-boot problem.
Another data item useful in many Data Center environments is the location of each machine on the Data Center floor, often specified as a grid coordinate like "B6". This would be stored and then retrieved using something like this:
$ sneep -t GRIDLOCATION -s B6 $ sneep -t GRIDLOCATION B6
When opening a service case on external storage attached to a system, Oracle requires the serial number of the storage, not the system. Assume that there are two StorEdge 3510 arrays on a machine using controller 6, targets 2 and 4. For example:
$ sneep -t SE3510_c6t2_PSN -s 085581 $ sneep -t SE3510_c6t4_PSN -s 002D11
Storing other tags depends on what else is in the nvramrc, the length of the tags and values, and on the specific hardware platform. Different platforms use different EEPROM chips. Smaller EEPROM (300 bytes) could store 10 SNEEP tag/value pairs if the average size of each was approximately 30 bytes. Newer machines tend to have a larger EEPROM, around 4000 bytes.
If there are other items in the nvramrc variable (for example, devalias device alias entries), then these reduce the amount of space available for SNEEP tags.
SNEEP limits your total nvramrc usage to a conservative amount appropriate for your hardware platform, unless more than that is already in use. If that is the case, then you can use no more than is already in use, unless you override this safety limit with the -F (force) option.
A data item is removed by setting it a null value using a pair of quotes with nothing between them:
$ sneep -t GRIDLOCATION -s B6 $ sneep -t GRIDLOCATION B6 $ sneep -t GRIDLOCATION -s "" $ sneep -t GRIDLOCATION unknown $
It is possible to share SNEEP over NFS; however, SNEEP is properly installed by means of a pkgadd, but technically, it does not have to be installed in order to be used. For example, you can run it directly from the subdirectory in the expanded package if you wish to do so. So yes, SNEEP can be used from an NFS mount point.
However, if it is not installed, the system startup links are not installed, and you will not have the boot-time automatic data integrity checking, automatic recovery, and automatic update of the optional Oracle Explorer plug-in.
In some environments, having these features can significantly reduce the time and effort required for maintenance of the serial number. It depends on whether your platform provide hardware support for the serial number, and/or how common it is to overwrite the Explorer configuration, or to reset the EEPROM.
Note:
Flash archives often include the configuration files from the flash source machine, and installing these files through the flash process has the same effect as overwriting them.In the absence of hardware-supported serial number, the flashed machine will report the serial of the flash source machine until corrected manually with the sneep -s command.
In the global zone, SNEEP acts just as it would on any other Solaris domain. There are a few differences with non-global zones:
Since SNEEP R2.5_1.79, the pkgadd command will not automatically add the SNEEP package to non-global zones. It is recommended that the SUNWSNEEP package be added to each non-global zone individually to preserve "administrative consistency" so that the same procedures can be used to retrieve the serial number and other tags without regard for the type of domain or zone. The end-user should not need to know this kind of detail.
Non-global zones cannot update the EEPROM.
Non-global zones can read the EEPROM data. As long as the data stored for the zone is the same as the data already in EEPROM, then the EEPROM will be used. If the data to be stored for the zone is different from the data in EEPROM, or if the SNEEP tag used in a non-global zone is absent from the EEPROM, the data will be stored in the SNEEP backup file in the non-global zone. In this way the system eeprom is used as much as possible, but it can be supplemented or overridden as needed by the SNEEP backup file in a non-global zone.
x86/x64 platforms have no true eeprom and non-global zones lack the openprom driver for the missing hardware. Non-global zones cannot read data from the global zone's simulated EEPROM. On these platforms, the SNEEP backup file has to function as the EEPROM. All SNEEP data for the non-global zone is stored in the SNEEP backup file. No SNEEP data will be available unless it has been explicitly set in the non-global zone using "sneep [-t tag] -s <setting>". For administrative consistency (so that you can use SNEEP the same way in every domain and zone) we recommend that when you install SNEEP in each non-global zone, you set the serial number and any other tags useful in your environment.
SNEEP tags are not persistent across OS reload.
A side effect of the eeprom handling in non-global zones is that SNEEP tags in these zones which are not also present in the hardware EEPROM are not persistent in cases where the Operating System is replaced or the zone is recreated.
Upgrades implemented by patching will not affect SNEEP tags because the SNEEP backup file is not disturbed.
File systems inherited from the global zone.
If you are installing or configuring SNEEP in a sparse non-global zone which inherits file systems from the global zone, you may see messages indicating that the installer was unable to create files in the inherited (read-only) file system.
In the normal case, this will not affect SNEEP as long as SNEEP is installed in the global zone using the corresponding place in the file system of the global zone. We recommend that you install SNEEP into the global zone first, so that the installer can see that the SNEEP files are already in place.
Example 1: default case: /usr is inherited, /opt is not SNEEP installs properly in its own /opt. SNEEP cannot create a link to itself in /usr/sbin. However, a /usr/sbin/SNEEP link created in the global zone can be used in the non-global zone.
Example 2: /usr is inherited, /opt is also inherited SNEEP cannot be installed in the read-only /opt. SNEEP cannot create a link to itself in /usr/sbin. However, /opt/SUNWSNEEP and a /usr/sbin/SNEEP link created in the global zone can be used in the non-global zone just as though the installation had been successful.
Generally, the Fujitsu PRIMEPOWER platform requires you to have special privilege to read its serial number. However, once the serial number has been set into EEPROM by SNEEP, you can get it back from EEPROM without special permissions.
Nevertheless, you will need root permission to get the actual serial number:
fserial
Once you have the serial number, then use SNEEP to enter it into EEPROM:
sneep
If the serial has been retrieved previously by SNEEP using fserial as the root user, and saved into the EEPROM, then it will be reported correctly. Otherwise, you might be seeing a value (from an Explorer file, for example) which is different from the true value which would be reported to the root user.