Key Users
  Product Detail
  Automated Brochure
  Automated Demos
  Press Releases
  Newsletter
  Brochure
  Testimonials
  Customers
  Analyst Reviews
  Live Demo Request
  ROI

 


 
 
 
    > Newsletter > December 2006 > Ask Al
 
   
 

Ask Al

Question #1
I have noticed that the On-Line! Detective has OpenBoot PROM commands that I have never seen documented anywhere else. Can you tell me where and how you obtain these commands?

Answer:
There are a number of useful commands hidden within the OpenBoot PROM. Finding the commands is relatively easy but the challenge is learning how to use them. If you want to see all commands in the OpenBoot PROM, simply type “words” at the “ok” prompt:

ok words

Be prepared to see thousands of commands scroll by if you do this. A more manageable method of scraping the OBP for useful commands is to narrow your search. Think about the OBP commands that you currently use and expand on that.

For example, the probe-scsi command is very useful OBP command. But this command only probes the on-board SCSI controller for devices. How can we probe additional SCSI controllers?

The probe-scsi-all command was documented by Sun long before it was cited in reference manuals. Logic dictates that if probe-scsi probes the SCSI Bus, then what else can be probed within the system? This is where the sifting command comes in handy. From the "ok" prompt, try the following example to identify the various commands that contain the string "probe." Use the OpenBoot sifting command, as follows:

ok sifting probe

The system responds with this:

(f006c444) probe-all
(f006bf14) probe-pci-slot
(f006baa4) probe-scsi-all
(f0060de8) probe-pci
. . . <output has been truncated>

The sifting command, also called a sifting dump, searches every OpenBoot PROM command that contains the specified string. From the example above, we see there are several different commands that contain the word "probe."

The challenge of using undocumented commands is trying to guess their syntax. Try using the command without any syntax. If that produces meaningful information, then you have just revealed an undocumented command. Some commands require some context sensitive syntax; otherwise, the command will just return a null, some type of error or if you're lucky a hint of what the syntax should be.

You will be surprised at how many undocumented commands are hidden within the OBP. The content of the OBP varies because of OBP revisions and part numbers. If you want to see whether an OBP contains a specific command seen on another system simply type "sifting (command name)." Typing part of the command name often produces better results. For example, typing "sifting prob" not only displays all commands containing probe but also probing, probelist, etc.

Try searching the following keywords by using the sifting command at the "ok" prompt.

"probe"
"." (period)
"test"
"show"
"speed"
"cpu"
"dev"
"stat"

If you can remember at least a portion of the command, you can use the OBP sifting command to get a list of matching Forth command words. For example, suppose you used the test-nets command some time ago and now you can't remember anything except "test". Type "sifting test" for a listing of all Forth vocabulary entries that have any match on "test." The list should jog your memory enough to recognize the test-nets command.

Learning to use the sifting command will effectively enhance your troubleshooting ability and add another tool to your arsenal of troubleshooting techniques.

Question #2
I'm working on a system and having a hard time determining if I'm having a hardware problem or if it's a software bug. Can you give me some guidelines on how to separate a hardware problem from a software bug? I may need to add a patch so can you give me a quick primer on patches as well?

Answer:
Here are some common diagnostic questions which can be used to help isolate the problem:

  • What is the system hardware, model number, and serial number?
  • What Operating System release level are you running? ("uname -a")
  • What Patches have been applied? ("showrev -p")
  • Have there been any recent modifications to the system or the computing environment? Think this over carefully. Even small changes to the environment, such as changes in other client/servers or network loads can uncover dormant problems in a system
  • Does the system power up and pass self diagnostics, resulting in "ok" prompt? If not, the system has detected a hardware problem and hardware replacement is required.
  • If the system does not pass self test, take note of any messages.
  • Do the Power Supply LEDs indicate proper power?
  • Do the Front Panel Status LEDs indicate any errors?
  • Do the Board Status LEDs indicate any errors?
  • When the machine is booted, does fsck report file system damage? If so, run fsck several times on the partition that was damaged. If messages persist, the drive may need to be replaced and restored from backup.
  • Did you replace the system's kernel, or remake it?
  • Is the system hanging or experiencing panics?
  • What was the panic message displayed on the system?
  • If the system requires a reset, were you able to reset the system using L1-A reset or did you have to power cycle the system?
  • Were there any power outages or power spikes? Check amerage loading per building circuit and check for other power equipment which could produce a noisy or dirty power signature. This may include heaters, too many systems on a circuit, power motors, or UPS. If power problems are indicated, consider doing a power sample analysis or power monitoring.
  • Are there core files available? (ls -R/var/crash)
  • If no savecore was created, can savecore be enabled? To enable savecore, uncomment the savecore commands in the startup file. For SunOS or BSD Unix systems the startup file is /etc/rc.local. For Solaris the startup file is /etc/init.d/sysetup.
  • Are you able to get output from the dmesg command or /var/adm/messages files?
  • For system hangs, check for any disk or tape drive "in use" lights that are on solid. This indicates a bus error, possible drive or controller failure.
  • What type of console is connected to the system? Frame Buffer or ASCII Terminal via serial interface?
  • What revision level of boot proms are installed?
  • Can you access this system from another system (telnet, rlogin, rsh)
  • If the system has a mouse, does the mouse cursor move on the screen when you move the mouse?
  • Does the "Caps Lock" light come on when you press "Caps Lock" on the keyboard?

Obtaining Patches
Patches were generally distributed as compressed tar or zip files and include the generic Korn shell scripts, installpatch and backoutpatch (to remove the patch), and a readme File describing the patch and the problems it fixes. The readme file includes a list of files replaced with the patch, the bug IDs and descriptions and any special installation instructions that may be required. Generally patches can be downloaded from the WWW (sunsolve.sun.com with a service agreement) or they are also available on CDROM from Sun. Sun's current policy on public and private patches can be reviewed by going to http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access . For information on Anonymous FTP policies see http://sunsolve.sun.com/search/document.do?assetkey=1-9-82023-1.

There are two patch collections:

  • Public - Available free at www.sun.com, public patches are a subset of Contract patches. They include patches that Sun has determined are critical to customer operations, and therefore Sun makes these patches publicly available at no charge.
  • Contract Services - Requires a software support contract with Sun or a third party vendor. Customers with a software support contract may download all public and private patches.

Different Patch Interactions
The likelihood of different patches replacing or otherwise affecting the same executable is not high, unless one of the patches supersedes the other. Patches will change over time. It can be frustrating to determine not only whether you've applied a certain patch, but also whether the latest version was applied. Make sure to apply patches in the proper order. The order in which patches are installed can make a difference. Always install the latest dash number i.e. patch 1234567-05 indicates that the patch number is 1234567, revision 05.

Patch Naming Convention
Patches have names like 123456-08, where 123456 is the patch number and the 08 is the version. If you've installed 123456-08, you don't want to reapply 123456-07. You could replace an executable with an older one. If patches are obtained from SunSolve, or a site that properly maintains current patches, only the latest patches will be available. If you maintain a collection of patches for updating your internal systems, make sure you keep the collection as up-to-date as possible, especially if individual users might be getting patches both from this collection and from outside. Again, the order in which patches are installed is important.

Adding Patches
Patches are installed by using the patchadd command. There are a number of command line options that can be used to modify the way a patch is installed. Below is a list of the patchadd switches.

Patchadd Parameters
Parameter Description
-R Specifies a patch is to be installed to a bootable root image of a diskless client or AutoClient. The path to the client's root image must follow the -R parameter. For example, patchadd -R /export/root/client /var/spool/patch/11316-01 will apply patch 11316-01 to a Solaris 8 x86 diskless client that uses a root image stored under the /export/root/client directory on the current system.
-S To apply a patch to an operating system (OS) service, use the -S command-line argument and specify the service.
-C Use the -C switch to install a patch to a image used to install the OS over the network (mini root), The pathname to the net install image must also be specified
-M Multiple patches can be installed by using the patchadd command with the -M command-line argument and by specifying a directory where all the patches are located and a list of the patch numbers.
-d When installing a patch do not backup original state. If this switch is used you will not be able to backput of the patch.

Regardless of the type of system configuration being patched, the patchadd command is typically executed locally on the system where the software being patched resides (the target directory). However, you can install patches remotely over the network if the target directory can be accessed through Network File System (NFS) services.

If the patch is on a CD-ROM, you can install it directly from the CD-ROM. A patch downloaded from the Sun Web or FTP site must reside on a system hard disk. The area where patches are stored before they are installed is referred to as the spool directory.

Although patches have no required spool directory, the most commonly used location is the /var/spool/patch directory. However, you can use any location on the system that has adequate free space.

If a patch was obtained via download, chances are that it was zipped (compressed) to make it easier and quicker to download. Some patches (mainly for SPARC platforms) are compressed with the gzip command and have filenames ending with the .gz suffix. Others are compressed with the zip command and have filenames ending with the .zip suffix. The zip command is used for both SPARC and Intel x86 platforms. After the compressed file has been expanded You then use the patchadd command to install the patch. Because patches have no default spool directory, you must specify the full pathname to the patch as a command-line argument. The following example shows the installation of the x86 find command patch on a standalone system:
# patchadd 111926-01
 
Checking installed patches...
Verifying sufficient filesystem capacity (dry run method)...
Installing patch packages...
 
Patch number 111926-01 has been successfully installed.
See /var/sadm/patch/111926-01/log for details
 
Patch packages installed:
SUNWcsu

Do you have a question you'd like to see answered in a future issue of eKnowledge? Email Allen at: askal@stsolutions.com