SNEEP FAQ

Frequently Asked Questions about SNEEP

Updated from the original sneep 2.6 sneep_FAQ.txt 1.29 05/09/08 22:49:44

What is sneep ?
What is the current version of sneep?
Where can I get a current copy of sneep
What support is provided for sneep ?
How can I file an RFE (Request For Enhancement)
How can I be notified of updates?
How much space is required for installing sneep?
Why is my serial "unknown"?
Where can I find my system serial number?
Which Systems have the serial in Hardware?
Why does sneep take so long sometimes
Strange Veritas things in EEPROM nvramrc
Sneep Presentations

Does sneep require special permissions?
Do I need root access on Fujitsu PRIMEPOWER
Does sneep validate the serial?
Can the Serial Number be Read Only?
Where and how is the serial number stored in EEPROM ?
How do I store something other than the serial number
How do I remove or erase a sneep tag and value ?
Are my settings lost if I restore the eeprom defaults
Are my settings lost if I update OBP firmware?
Will sneep work with use-nvramrc?=false ?

How many other tags can I store with sneep?
What if I store too many things?
Is there an EEPROM on x86/x64 platforms?
What differences are there when using sneep with
Can we share sneep over NFS?
Why did sneep report "Bad String" ?

What is the current version of sneep?

The current version is 2.7, although you should verify this
at the sneep download site in case this page needs updating.

What is sneep ?

SNEEP - Serial Number in EEPROM

Sneep provides a software-accessible Chassis Serial Number (CSN)
for all Sun 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 Sun 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 Sun's "explorer" and "CST"
(Configuration Service Tracker) products,
and can create a special tracking event in CST
when the serial number is set or discovered.
This reduces the effort required to manage these tools.

Where can I get a current copy of sneep?

Sneep is included in the Services Tools Bundle (STB) beginning with STB 2.0 .

Please visit the STB website at http://www.sun.com/service/stb to get sneep, explorer,
and other essential Sun service tools in one easy-to-install bundle.

Sneep is available separately from http://www.sun.com/sneep

and from the Sun Download Center at http://www.sun.com/download

• Category ->
  • Systems Administration/Systems Management
    • Sneep

or

• Downloads A-Z
  • S
    • Sneep

or

• Enter "sneep" in the "Search the Download Center" box.

or (for Sun employees only)

• Sun internal Sneep site

Sneep Presentations

Are there any presentations available for sneep
which I can use to explain to my team mates why we need sneep and what it does?

Yes.
PDF and Office versions are available from the sneep FAQ at
http://wikis.sun.com/display/sneep/SneepPresentations

The SUNWsneep package Documentation directory also contains
the presentation PDF files.

The package Documentation directory is included in the
downloaded package file. Extract the contents:

             $  zcat SUNWsneepX_RY.tar.Z | tar xvf -

The documentation is available in
SUNWsneep/reloc/Docs
After package installation, the same documents are available in
/opt/SUNWsneep/Docs

What support is provided for sneep ?

How can I file an RFE (Request For Enhancement)?

Contract customers can place service calls for sneep support
using normal Sun support channels such as 1-800-USA4SUN,
online service portals, etc.

The sneep support team will will acknowledge cases opened for
support requests and escalations within one business day.

This is the only mechanism for problem investigation and
Requests For Enhancement, so that these requests can be properly
tracked and resolved.

What email resources are available for sneep?

To learn about releases, features, and any possible issues,
PLEASE SUBSCRIBE to the sneep-announce electronic mailing list at sun.com .

Send your request to join sneep-announce to the sneep-support alias at sun.com.
[ Sorry - having the actual email addresses using "@" just attracts spam ]

Your email address will never be used for any other purpose,
and messages on the alias are very infrequent.

Sun employees may subscribe customers to this alias
(at the customers' request) using Netadmin.

How much space is required for installing sneep?

Sneep requires less than 1 MB space to install.

Unknown Serial

I loaded sneep on my system and when I ran it,
sneep said that the serial was "unknown".
Why doesn't sneep know what it is?

Most of the older Sun platforms have no way to know or report
their serial number until after they have been manually sneeped.

Most of the newer Sun platforms natively provide
serial number data through some hardware-based mechanism which can be read by sneep,
but there are a variety of ways in which this data is provided.
A partial list of these platforms is available on the Hardware Serial page.

While sneep is able to take advantage of many of the mechanisms
which provide "hardware" serial number support,
at this time, Sneep does not know how to find serial data on every
platform which can provide it in some way.

We are adding support for more of these methods and platforms
as quickly as we can.

If you do not have the latest sneep update, your version may not
know how to get the serial number from your machine.
A newer update of sneep might be able to do this.

There is also the possibility that your machine is one of the
platforms for which it is always necessary that the user inform
sneep of the serial number of the machine using

sneep -s serialnumber

This should only need to be done one time, and after that, sneep will
make it very easy for the user to get the serial number any time that
it is needed.

Where can I find my system serial number?

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 http://sunsolve.sun.com/handbook_pub .

Someone may have the original data sheet (usually yellow or orange),
delivered with the machine. The data sheet shows
the serial number and system configuration.
Or, the serial may have been recorded in a spreadsheet somewhere.

Note that 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

Which Systems have the serial in Hardware?

A list of platforms for which sneep can locate a hardware-based serial number
can be found on the Hardware Serial page.

Slow Response

When I run sneep on some of my machines, it responds immediately,
but on other machines it takes much longer.
Why?

Some Sun platforms provide the product serial number in the
output of the "prtdiag" command. prtdiag communicates with
the Platform Information and Control Library (PICL) daemon,
and "picld" may need to communicate with the system controller
or ILOM to get current hardware information.

This communication may take a few seconds. (15 is not uncommon)

If sneep does not respond for a minute or more, the likely cause
is that "picld" is not yet ready, or perhaps never started.

Sneep may wait for picld to respond, retrying prtdiag several times
before giving up. By default there will be messages in the system log
/var/adm/messages indicating these retries.

On Solaris 10, you can find out if picld is enabled and functioning
by checking the picl service.

It should look something like this:

               $ svcs picl
                STATE          STIME    FMRI
                online          8:10:48 svc:/system/picl:default

Prior to Solaris 10, you can verify that the "picld" process is running,
but that does not necessarily mean that it is functioning properly.

                $ ps -ef | egrep 'PI[D]|picl[d]' 
                  UID   PID  PPID  C    STIME TTY      TIME CMD}}
                 root   296     1  0   Jan 11 ?        2:26 /usr/lib/picl/picld

Strange Veritas things in EEPROM nvramrc

I use Veritas VxVM (tm) to manage my storage volumes, and after I made a
change to the root volume, I was using sneep and noticed that the
eeprom nvramrc looked very strange - everything was flattened onto
one long line. What is wrong and how do I fix it?

You are seeing the effect of a change made to VxVM's handling
of the eeprom nvramrc. This change has been returned to normal
with recent VxVM "Rolling Patches" for their Maintenance Packs (MP).
Versions of sneep before update 1.79 were not prepared for this
change, and could lose track of the device alias names for the
root volume, which VxVM stores in the eeprom nvramrc.
This could even cause a system to fail to boot without manual assistance.

Sneep update 1.92 and above are not bothered by this change,
and can even repair the nvramrc if you either set a value with sneep,
or wait for the automatic repair at the next reboot.

IT IS VERY IMPORTANT TO UPGRADE TO AT LEAST SNEEP UPDATE 1.92

Usually, the easiest value to set is the serial number,
although you could make up any tag and value to set

                sneep                   # get the serial number
                sneep -s serialnumber   # set it again to correct the nvramrc

        or

                sneep -t anything -s anyvalue   # make a change to nvramrc
                sneep -t anything -s ""         # delete the made-up entry

If "sneep -T" reveals any strange sneep tags made accidentally by
sneep releases lower than 1.92, ( tags such as "devalias" or "cr" )
you can remove them by setting them to an empty value -

Upgrade to sneep update 1.92 or newer, then remove them
by setting them to a null value.

                   $ sneep -t cr -s ""
                   $ sneep -t devalias -s ""

Does sneep require special permissions?

Superuser permission is required to set any values in the
eeprom and system configuration files, but in general, any user can
retrieve the values.

There are exceptions to this of course -

The Fujitsu PRIMEPOWER platform wants you to
have special privilege to read its serial number,
but once the serial number has been set into eeprom by sneep,
you can get it back without special permissions.
There is more detail on this later in this FAQ in the
section on Fujitsu PRIMEPOWER.

To read the serial number on the F15000/F25000 System Controller,
you may need superuser or sms-svc privilege.

Validation of Serial, etc.

Does sneep validate the serial number, manufacturing date and location, etc.?

No.
There are wide variations in the format used for serial number
and many different platforms. While it is possible to decode
a value intended for use as a serial number, it cannot truly
be validated.

Sneep does make an effort to ensure that it is approximately the right
length and does not have any obviously invalid characters in it.

Can the Serial Number be Read Only?

The serial number should be read-only.
Can sneep prevent changes to it?

Not really.
Sneep is a simple utility which depends on the services of the
"eeprom" command and the semantics of Open Boot PROM variables.
While sneep could refuse to make changes to the serial once it has
been set, there is nothing to prevent a user from directly using
the "eeprom" command or the OBP "nvedit" commands to alter the data.

In addition, some platforms (especially non-Sun x86/x64 machines)
may report the serial number incorrectly, and on those platforms,
it is necessary to be able to override the hardware-provided serial.
Sneep is the only way to do this that we know of.

However, there is no obvious reason why anyone should go to the
trouble of changing the serial number once it has been saved with sneep.
Having it available is a convenience, not a requirement or a
license in itself. Changing the value provides no real
advantage to the user.

Even so, root permission is required to make the change in
Solaris, and sneep will log any such change in syslog.
Common data-center practices such as restriction of root access
and the use of centralized system logging will in many cases
make any changes easy to audit and relatively difficult to hide.

There have been discussions regarding changes which could be made
to OBP to make the serial number read-only.
If having a writable serial number someday proves to be a problem,
that issue will be addressed.
For now, we prefer to Keep It Simple.

Where and how is the serial number stored in EEPROM ?

sneep uses the 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 <."> e.g.

               ." ChassisSerialNumber ABCD1234 " cr

The "eeprom" command is used very carefully to store and retrieve
these strings, taking care to preserve any other nvramrc contents.

Some people have used the OBP "oem-banner" variable to store the
serial number or other information. oem-banner 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 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.

How do I store something other than the serial number using sneep ?

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, Sun 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

                $ sneep -t SE3510_c6t2_PSN -s 085581
                $ sneep -t SE3510_c6t4_PSN -s 002D11

How many other tags can I store with sneep?

That 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.
The smallest eeprom we have seen (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
(e.g "devalias" device alias entries) 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.

What happens if I override the size limit of the eeprom nvramrc ?

By default, sneep will prevent you from using too much nvram,
but most platforms provide more nvram capacity than sneep will
allow you to consume (just to be safe).
If you are certain that there is more available on your
particular platform, you can override sneep. If you need a few
more bytes than sneep allows by default, there is no danger.

However, if you exceed the true maximum capacity of the nvramrc,
some SPARC systems will show no immediate effect, while others
will drop into OpenBootProm.
After that, the system may not boot until the eeprom defaults
are restored.

                ( OBP> set-defaults )

A Solaris x86 system may not have an immediate reaction,
but may fail to boot later.

As these are very serious consequences, it is Strongly Recommended
that you do NOT override the safety limits. If you do so,
you are entirely responsible for any system outage or other damages.
Sneep takes care to notify you of this.

How do I remove or erase a sneep tag and value ?

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
               $

Are my settings lost if I restore the eeprom defaults or replace the eeprom?

No.
Sneep maintains a backup file /etc/default/SUNWsneep in which
it keeps a copy of all settings. In case OBP defaults have
been restored or if the eeprom has been relaced without
preserving the contents, sneep automatically restores the
sneep eeprom settings from the backup file when the system is
rebooted.
Alternatively, the data can be recovered simply by asking for
it with sneep, and then setting the returned value again with
sneep.

Sneep has options designed to make it easy to recover data
with very little effort, and under most circumstances it will
be able to automatically recover the data at the next system boot.
When this is done at system startup, sneep will log
a message to tell you if the eeprom is not consistent with
the backup and whether or not it was recovered.

See the manual page for the usage of -T, -d, and -P.
The User Guide contains a detailed example of data recovery
procedures and options.

Are my settings lost if I update OBP firmware?

No.
It is possible to lose the eeprom settings in an OBP firmware
update, but while it once was common, these updates have been
very reliable and safe for several years.

Of course, if there is a problem, sneep will automatically
recover the values from the backup.

Some of our systems have "use-nvramrc?=false" . Will sneep still work ?

Yes.
use-nvramrc? controls whether or not OBP executes commands
from nvramrc during the boot process.
Sneep can find the values in nvramrc even if OBP never uses them.

The only noticeable difference is that with use-nvramrc?=true ,
the serial number (and any other tags) will print during boot,
and with use-nvramrc?=false , they will not.

Is there an EEPROM on x86/x64 platforms?

h.6 x86 PC platforms do not have an eeprom.
What does sneep use on Solaris x86?

Solaris x86 has an eeprom emulation which is managed in a file
by the "eeprom" command. [Unless something has changed,
the filename is /boot/solaris/bootenv.rc.
By default, the simulated eeprom does not have an "nvramrc" variable,
but "eeprom" is willing to create one for sneep.

Note that 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.

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. Note that if you have been using the "explorer"
tool, 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.

Zones

What differences are there when using sneep with Solaris 10 zones ?

In the global zone, sneep acts just as it would on any
other Solaris domain, and there should be no surprises.

There are a few differences with non-global zones

1) Since sneep R2.5_1.79, pkgadd will not automatically add
the sneep package to non-global zones.
For administrative consistency, it is recommended that
the SUNWsneep package be added to each non-global zone
individually.

2) Non-global zones cannot update the EEPROM.

SPARC
Non-global zones can read the EEPROM data.
As long as the 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 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

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.

ALL PLATFORMS

1) 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.

2) Filesystems inherited from the global zone

If you are installing or configuring sneep in a
sparse non-global zone which inherits filesystems from
the global zone, you may see messages indicating that
the installer was unable to create files in the inherited
(read-only) filesystem.

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 filesystem 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.

Sneep over NFS

Can we install SUNWsneep on a single server and then share it
to other systems using NFS, as we have done for other tools?

Yes, but...

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 explorer plugin.

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 and CST configurations, or to reset the eeprom.

[ Note that 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 "sneep -s" ]

Why did sneep report "Bad String" ?

I tried sneep and it said "Bad String" and refused to do anything.
What is wrong?

You probably have an old version of sneep and are using a
locale or language setting which involves "UTF-8" .
The default 'tr' program used in sneep did not work in UTF-8 locales.
This is no longer a problem after sneep 2.5_R1.75.

Sneep and "root" on Fujitsu PRIMEPOWER

I ran sneep as a non-root user and along with the serial number got this message :

"Please run sneep as root to ensure correct serial number from fserial data source"
What does this mean, and is my serial number incorrect?

Your serial is probably correct, but on your platform, only the root user
can be sure. This message occurs only on machines like the Fujitsu
PRIMEPOWER series, when sneep (2.6 or newer) is attempting to use the
"fserial" data source supported on these machines. The serial number
on these machines can only be collected by fserial as the root user.
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.