Sue Userguide 3.32

Solaris Utility Environment (SUE)
Version 3.32 User's Guide
John Cecere
Dana Fagerstrom
Sun Services
November 12, 2010
Oracle Proprietary – Internal and Authorized Partner use only

Table of Contents
1 Solaris Utility Environment vs. Diagnostic Boot CD............................................................4
2 Overview............................................................................................................................. 5
3 SUE release types.............................................................................................................. 7
3.1 SUE CD.......................................................................................................................... 7
3.2 SUE dual boot DVD........................................................................................................7
3.3 SUE++............................................................................................................................ 7
4 Boot process....................................................................................................................... 8
4.1 Boot options....................................................................................................................8
4.2 SPARC............................................................................................................................8
4.3 x86/x64........................................................................................................................... 8
4.4 Booting SUE entirely in memory.................................................................................... 9
4.5 System Configuration................................................................................................... 10
4.6 getroot.......................................................................................................................... 12
4.7 SNEEP (SPARC only).................................................................................................. 13
4.8 SunAlert 102139...........................................................................................................13
4.9 Setting the dump device...............................................................................................13
5 Text menus........................................................................................................................ 15
5.1 Main menu....................................................................................................................15
5.2 Firmware menu (SPARC)............................................................................................. 17
5.3 Firmware menu (x86)................................................................................................... 19
6 SunVTS............................................................................................................................. 20
7 Firmware........................................................................................................................... 21
7.1 Disk Firmware...............................................................................................................21
7.1.1SunAlert 103174...................................................................................................... 22
7.2 Upgrading OBP/POST................................................................................................. 24
7.3 Fibre Channel HBA firmware........................................................................................26
7.3.1Dependencies.......................................................................................................... 27
7.3.2Fin 1081 and the JNI SEEPROM.............................................................................27
7.4 V880/890 disk backplane............................................................................................. 28
7.5 ALOM Firmware............................................................................................................29
7.6 RSC firmware............................................................................................................... 31
7.7 v1280/2900/Netra 1280................................................................................................31
7.8 LSI controller firmware................................................................................................. 32
7.9 Jasper 320 LVD SCSI controller...................................................................................32
7.10 sun4v system firmware...............................................................................................32
7.11 Adaptec SAS RAID controller (Cougar/Prometheus)................................................. 36
7.12 Serengeti firmware..................................................................................................... 36
7.13 Auto Firmware Check................................................................................................. 37
8 Veritas Volume Manager................................................................................................... 38
9 Solaris Volume Manager................................................................................................... 41
10 ZFS..................................................................................................................................42
11 Creating a Network Boot Image...................................................................................... 44
11.1 Setting up a boot server............................................................................................. 44
11.2 Dual boot DVD............................................................................................................45
11.3 Hands-off booting....................................................................................................... 46
11.4 WAN booting (SPARC only)....................................................................................... 48
12 USB Flash Drive booting (x86 only)................................................................................50
12.1 Creating a bootable SUE flash drive.......................................................................... 50
12.2 Booting the flash drive................................................................................................51
Oracle Proprietary – Internal and Authorized Partner use only 2

13 ECC Utilities for SPARC (cediag, findaft, fin954)............................................................52
13.1 findaft.......................................................................................................................... 52
13.2 findUE......................................................................................................................... 52
13.3 findfma........................................................................................................................ 52
13.4 ECC errors and /etc/system....................................................................................... 53
14 Device path decoder....................................................................................................... 54
15 devfsadm.........................................................................................................................55
16 DtraceToolkit................................................................................................................... 56
17 scrubber.......................................................................................................................... 58
18 Online documentation..................................................................................................... 59
19 LDOMS (SPARC only).................................................................................................... 60
20 SUE++ Interface..............................................................................................................61
20.1 X configuration............................................................................................................61
20.2 Remote access...........................................................................................................62
20.3 Logging in................................................................................................................... 62
20.4 Main tab......................................................................................................................63
20.4.1 Sun System Handbook......................................................................................... 63
20.4.2 Shared Shell..........................................................................................................64
20.5 Firmware tab...............................................................................................................64
20.6 Start/Stop tab..............................................................................................................65
20.7 ECC Utilities tab (SPARC only).................................................................................. 65
20.8 System Control tab..................................................................................................... 66
20.9 System info tab...........................................................................................................66
Appendix A - Troubleshooting................................................................................................... 67
Appendix B – Image contents...................................................................................................71

1 ► Solaris Utility Environment vs. Diagnostic Boot CD
The Solaris Utility Environment (SUE) was previously called the Diagnostic Boot CD. There
were several reasons for the name change. First and foremost was to remove any reference
to a particular type of media (CD). The Solaris Utility Environment can be a network boot
image, CD, DVD, or even a USB flash boot image, so it seemed that Diagnostic Boot CD was
something of a misnomer.
Another reason for the name change was to remove the word diagnostic. Diagnostics are one
aspect of the environment, but it doesn't cover everything that the image is capable of. The
environment contains volume manager drivers, firmware upgrade utilities, and anything else
we could think of that would be useful in a situation where the root disk might need repairing,
or some form of maintenance needed to be performed with the root disk out of the way.
Besides the software application versions, some of the major differences between SUE and
DBCD are:
• SUE is based on Solaris 10, DBCD is based on Solaris 9
• Ability to control how the system configures itself on boot
• SUE has an x86/x64 version, DBCD does not.
• Boot scripts for DBCD were hacked versions of the installation scripts for Solaris 9. The
boot scripts in SUE have been written from scratch

2 ► Overview
The Solaris Utility Environment (SUE) is a bootable Solaris CD with a number of diagnostic
tools and utility programs installed on it. It creates a platform from where diagnostics (such as
SunVTS) can be run and troubleshooting can be performed on a system without involving the
root disk. The intent of this document is to explain how to use the Solaris Utility Environment,
not to provide a tutorial on any of the externally obtained software contained on it.
The goal of SUE is simple: reduce service time. To achieve this goal, it provides the following
advantages:
• Allows diagnosis and troubleshooting to be performed without the variable of the

loaded OS.
• Provides a platform for repairing the loaded OS when the OS won't boot. OS disks
under Veritas Volume Manager or Solaris Volume Manager control are easily
handled, as the drivers needed to access the components (volumes, plexes,
metadevices, etc.) of these volume managers are included on the image.
• Provides a diagnostic environment for SSEs and FEs to boot when the customer
won't let them install software on their root disk.
• Provides a platform for running diagnostics on systems prior to an OS being loaded.
The Solaris Utility Environment used to be based on the miniroot found on slice 1 of the
Solaris 10 Software 1 of 4 CD. However, due to changes in the format of the CD (mainly on
x86) it's now become a simpler process create the miniroot from scratch by performing a
Solaris installation. After doing this base Solaris installation, a number of configuration files
have been modified and extra software has been added (see Appendix B). When using SUE,
keep in mind that the version of Solaris that's installed on the root disk of your system is
irrelevant to the version of Solaris on this image. There's no reason to have a Solaris 2.6
Solaris Utility Environment just because Solaris 2.6 is installed on your machine. It makes
much more sense to run Sun's latest OS with the latest diagnostic software, as long as it's
supported on the hardware.
As mentioned above, one of the advantages of SUE is the ability to run diagnostics outside of
the context of the installed OS. This removes the variable of the installed OS as the source of
any problems encountered while performing troubleshooting. If a problem is encountered
while booted off of the installed root disk that doesn't surface when booted off SUE, then the
issue most likely lies somewhere in the realm of downrev patches or misconfiguration of the
installed OS. Being able to run diagnostics without the installed root disk also provides the
ability to run them before the OS is actually installed on a machine.
Every effort is made to keep the patch set current on the image. Releases are generally made
once or twice per quarter, and the OS and product patches used are those from the latest EIS
CD/DVD available at build time. Firmware patches are taken straight from Sunsolve, but the
mechanism for maintaining the patch list and revisions is the same that EIS uses. However,
the list of firmware patches on SUE is not as comprehensive as the list on EIS. SUE currently
contains disk, FC-HBA, most OBP/flash and a few other miscellaneous firmware patches. The
criteria for deciding which firmware patches will make it on to SUE is directly related to how
difficult (or impossible) it would be to attempt loading that firmware from the OS disk.

After booting SUE a menu will be presented. This menu is run inside an open source program
called screen. Screen allows for multiple terminal sessions within one terminal window, so it's
possible to run several things simultaneously from the console, with the ability to switch
between them. See Section 5.1 for more details on screen.

3 ► SUE release types
The table below lists the various release types of SUE.
Name Media type GUI interface ? Platform(s)

SUE CD no SPARC
SUE CD no x86
SUE dual boot DVD DVD no SPARC and x86
SUE++ DVD yes SPARC
SUE++ DVD yes x86
3.1 SUE CD
A SUE CD image is specific to the platform it is needed for. There is a single CD image for
SPARC and one for x86. These images contain all the basic functionality described in this
user guide. The functionality that they don't provide is listed in the section(s) on SUE++.
Essentially there is no GUI environment on these images.
3.2 SUE dual boot DVD

The dual boot DVD is really just a concatenation of the SPARC and x86 CD images. The
functionality is the same as for standard SUE, with the exception that only one disk (a DVD)
is needed to boot on either environment. DVD media is needed because of the space used
by concatenating two CD images together.
3.3 SUE++
SUE++ is an enhanced SUE environment. Besides the basic functionality of SUE, it also has
the following:
● GUI interface. Accessible directly on the console or over the network using VNC
(virtual network computing).
● Simple to use browser interface (Opera web browser).
● Local copy of the Sun System Handbook.
● Context sensitive help functionality.
● Access to Shared Shell (if networking is configured).
● All Solaris man pages
See section 20 for more information on the GUI interface.

4 ► Boot process
4.1 Boot options
The following table lists the available boot options for SUE
Table 1- boot options

Option Platform Description
Causes SUE to perform an auto configuration during the boot process.
This auto configuration is the same one performed when booting the
autocfg All standard Solaris CD/DVD. It probes the network looking for it's
configuration, and any configuration information that it can't discover, it
prompts the user for.
Causes SUE to run the manual system configuration program during
the boot process. This is a perl script that prompts for name, IP
mancfg All address, and subnet mask for each interface, as well as default route
and DNS information.
Causes SUE to boot without performing a system and network
nocfg All configuration. This boot option will still prompt for a terminal type and
hostname.
Synonym for autocfg with the addition of attempting to take default
answers for any of the SUE specific boot questions. This is here to
install All allow for a hands off SUE boot using the traditional jumpstart methods.
See section 11.3 for details.
Boot the OBP/flash image for <platform name>. This is for performing
-F obp_archive -D /flash/<platform SPARC OBP/flash upgrades. The platform name must be the same name
name> returned via uname -i on the host being booted. See the section on
Upgrading OBP/POST for supported platforms for this function.
Tell SUE to attempt booting the entire image in memory. If this isn't
fsinmem x86 possible, a warning message will be generated.
4.2 SPARC
On SPARC systems, you can boot SUE from OBP using valid commands in the table above.
The format for booting from the OK prompt is:
boot <device> - <boot option>
Where <device> is an OBP device path or alias (e.g. cdrom) and <boot option> is one of
the boot options listed above. Please note that there is a space dash space between the
boot device and boot option. Also, don't boot single user mode. SUE is not very useful when
booted in single user mode.
4.3 x86/x64
When SUE is initially booted on x86, the following menu will be displayed on whatever is
defined as the console device.

GNU GRUB version 0.95 (537K lower / 2095552K upper memory)
+-------------------------------------------------------------------------+
| Solaris Utility Environment |
| Solaris Utility Environment (ttya) |
| Solaris Utility Environment (ttyb) |
| Memtest86 |
| Memtest86 (ttya) |
| |
| |
| |
| |
| |
| |
+-------------------------------------------------------------------------+
It's possible that the console device has been redirected to a serial port in the BIOS. If that's
the case, then you will need to select the appropriate menu item for that serial port. If you
select the wrong console device, SUE will not boot and the system will most likely just hang.
The last two options are for memtest86. This is an open source memory tester for Intel
architecture machines. It is commonly found on Linux boot CDs as well. You can use it to run
various memory tests on the system. More information on memtest86 can be found at
http://www.memtest86.com
To boot with any of the boot options described in section 4.1, it will be necessary to manually
edit the GRUB menu item that's being used to boot. To do this:
● Arrow to the desired GRUB menu item (e.g. Solaris Utility Environment - 64 bit)
● hit e (for edit)
● hit e again
● You will be positioned at the end of the kernel line in the menu item. Type a space,
then a - (dash), then another space.
● Type in the boot option (e.g. mancfg). Multiple boot options can be entered as long as
they are separated with spaces.
● Hit enter
● Type b (for boot)
On x86 systems, the miniroot will load into memory and the kernel will boot off of it. After the
kernel loads and SMF starts, the first thing it will do is to locate and mount the /usr and /opt
filesystems. /usr and /opt are kept as separate filesystems on SUE to keep the size of the
miniroot down. The main reason for doing this is that the maximum size of a compressed
miniroot that can be net booted is ~93MB. This is due to a limitation in tftp.
If, for some reason, the startup script is unable to mount the /usr or /opt, an error message
will be displayed and the system will drop to a shell prompt. This should never happen for a
CD/DVD boot, but it's possible for network booting if the boot server has the incorrect setting
for install_media in menu.lst. See section 11 and Appendix A for more information.
4.4 Booting SUE entirely in memory

If the system being booted is capable of holding the entire SUE image in memory (plus
200MB), you will be provided with the option to do so. There are two ways to have SUE load
entirely in memory. The first is to use the fsinmem option mentioned in section 4.1. The
second is to type m at the following prompt after the kernel loads:

Hit 'm' to load SUE in memory
This prompt is timed. If m is not entered within 5 seconds, then SUE will boot normally, i.e.,
the miniroot will load and filesystems will be mounted from the boot device.
If the fsinmem option is used or m is entered at the above prompt, the following message will
be displayed:
Loading SUE image in memory. This may take a while
The boot process will then proceed to copy /usr and /opt into a tmpfs (memory) and lofs
mount them from there.
The main advantage of booting SUE entirely into memory is that, after the boot is complete,
the device used for booting (CD, DVD, USB flash drive, or network cable) can be completely
removed or disconnected. This leaves that boot device free to boot other systems while the
first system can run anything that SUE is capable of.
The disadvantage of booting entirely in memory is that it takes longer, since it has to read the
entire contents of the filesystems into memory from whatever media is being booted. For a
USB flash boot or network boot, this amount of time is only an extra minute or so, but for a
CD or DVD boot, this can take a long time depending on how fast the drive is.
The option to boot entirely in memory will only be offered if there is enough memory on the
system. SUE will calculate this at the beginning of the boot process. If there isn't enough
memory, the prompt above won't be displayed. If the fsinmem boot option was provided in
GRUB and there isn't enough memory to perform it, the following warning will be displayed
and SUE will boot normally, mounting the filesystems directly from the boot device:
In memory mode requested but not enough memory to load image.
4.5 System Configuration

If no configuration option was given as a boot option, the configuration option will be
prompted for:
Select the type of configuration to perform
1 Auto system configuration

2 Manual system configuration
3 No system configuration
h Help
Enter option:
Selecting No system configuration will cause the system to continue to boot without any
network information. It will, however, still ask for a terminal type and hostname.

The auto configuration option will run the same configuration programs (sysidnet, sysidkrb5,
sysidns, sysidsys, sysidroot) that booting the standard Solaris installation CD/DVD runs when
it boots. It auto-detects the network environment using a number of different protocols such
as RARP, DHCP, and bootparams. The auto configuration can be a little disconcerting to the
user because the standard Solaris installation CD/DVD runs this autoconfiguration right
before it runs it's installation program. In fact, the auto configuration even displays a title bar
of The Solaris Installation Program. However, SUE will never attempt to install Solaris. The
installation program, as well as the installation packages have been removed from the image.
The manual configuration option provides the ability to do a simple IPv4 network
configuration, without searching the network for configuration information. A series of
questions are asked and the answers to them are used to run some basic networking
commands. Currently, the information that a manual configuration will prompt for and
configure is:
• Terminal type
• hostname, IP address, subnet mask for each interface
• default router
• DNS domain and nameservers
Below is an example of running a manual configuration for an interface. In this case, SUE
discovered the existence of interfaces eri0 and ge0. This discovery process amounts to
plumbing all the interfaces on a system and does not attempt the (very lengthy) process of
trying to RARP each one like the auto configuration does.
The first thing that is prompted for is the terminal type:
Enter terminal type [vt100]:
You may enter any terminal type that Solaris understands at this prompt. The terminal type
will be verified against the terminfo database. Hitting the enter key at this prompt will select
the default of vt100. After the terminal type selection is complete, the network configuration
will start.
Bringing up network configuration...
** Manual network configuration starting **
RARP boot interface is eri0
Searching for network interfaces: [eri0] [ge0] done
Process interface eri0 ([y]/n/q) ? y

Name: sselab1
IP address: 129.154.57.125
Subnet mask: 255.255.255.0
Is this correct ([y]/n/q) ?
If enter or y is pressed, it will accept the input parameters. A response of n will cause the
program to prompt for the information for this interface again. A q response will exit the
manual configuration program.
On network boots, the interface that was used to perform the boot will already have been
configured to some degree. In the case of an already configured interface, the current
configuration will be provided as the default response. For the example above in a network
boot, the following dialog will be displayed:
Process interface eri0 ([y]/n/q) ? y

Name [sselab1]: <enter>
IP address [129.154.57.125]: <enter>
Subnet mask [255.255.0.0]: 255.255.255.0
Information entered for eri0:
Name: sselab1
IP address: 129.154.57.125
Subnet mask: 255.255.255.0
Is this correct ([y]/n/q) ?
In this case, only the subnet mask was changed. Enter was pressed for the name and IP
address, causing the program to take the shown defaults.
The manual configuration will also prompt for a default route. You can either provide one (or
another one) or hit enter to skip adding a default route:
Default route (hit enter for none):
A check is done on the default route against the IP address and subnet masks of all the
configured interfaces. If the default route doesn't make sense (i.e., it's not on a local network),
the program won't accept it and will display the message:
Error: Default route is not local to any interface.
Invalid default route
Also, if there is already a default route present, the following message will be displayed
before prompting for one:
Notice: Default route of 129.154.57.228 already present in routing table
If, at any point 'q' is selected, you will be prompted with:
Start over or quit ([s]/q) ?
Answering this question with an 's' will cause the manual configuration to start from the
beginning. Answering 'q' will cause it to terminate, leaving the system unconfigured.
4.6 getroot
A perl script called getroot is run towards the end of the boot process. The purpose of this
script is to collect information about the system boot device (defined in OBP as boot-device).
It does this through the use of the Solaris commands eeprom, prtconf, prtvtoc, and fstyp. The
getroot program creates two files if it's successful. The files are /tmp/.rootdev and
/tmp/.swapdev. These files contain the Solaris device paths for these devices. There are
several reasons for doing this:
• The swap device may be needed if there is not enough memory on the host to load /opt
• Other programs may need to extract information from the normal root filesystem of the host
(if possible).
• The swap device can be used as a dedicated dump device for the life of the SUE boot.
• Certain diagnostic programs are far more useful if used to parse the system logs on the
OS disk, rather than those from booting SUE.
The running of getroot is completely transparent to the user.

4.7 SNEEP (SPARC only)
In addition to SunVTS, SUE will also always try to load SNEEP. SNEEP is a utility to save the
system serial number to NVRAM.. The SUE boot process will run SNEEP to make sure that
the system serial number is present in NVRAM. If not, the following prompt will be displayed:
Serial number has not been set with SNEEP.
Enter system serial number (hit enter to skip):
It is strongly suggested that you enter the system serial number at this prompt to keep a
record of it for future service issues (explorer will extract this data when run). Just hitting enter
will bypass this and continue the boot process without programming the serial number.
If the system serial number was already previously entered with SNEEP, only the following
message will be displayed:
Retrieving SNEEP data...done.
If the 'install' option was given as a boot argument, SNEEP will not be run.
4.8 SunAlert 102139

A quick check is done to see if SunAlert 102139 is applicable to the system that you're
booting the SUE CD/DVD on. This SunAlert has to do with incorrect data blocks being
returned from a disk in the DVD-ROM drive. If it determines that your system is susceptible to
this issue, it will display the following message:
WARNING: This system is affected by SunAlert 102139.
Please upgrade the firmware on the DVD drive with patch 120364.
Refer to Sunsolve for additional information.
If you see this message, refer to the SunAlert and the patch for instructions. The patch is a
firmware upgrade for the affected DVD-ROM drive. Since you can't perform this upgrade
while the SUE CD/DVD is in this drive, the patch is not included on SUE and no utilities exist
on SUE to perform the upgrade. You'll need to boot off of another device and upgrade the
DVD-ROM drive from there. SUE will merely print the warning message and continue on.
4.9 Setting the dump device

The last step of the boot process is to ask whether or not to set a system dump device.This is
done by running a script called setdump that asks whether or not one wants to set a dump
device for the duration SUE session:
Would you like to set the dump device to:
/devices/pci@1f,0/pci@1,1/scsi@2/sd@1,0:b (y/n/[?]) ?

The device that setdump chooses as a potential dump device is taken from the file
/tmp/.swapdev, which was created by the getroot script (see section 4.6 above and Appendix
B). If /tmp/.swapdev is populated, the device listed in it has been identified as the primary
swap device of the boot disk. If you answer the above question with a y response, this device
will be used as a dump device in the case of a system panic. This allows the retrieval of a
kernel core file should the host panic while booted off the SUE. Entering a carriage return to
this question produces the following explanation:
This is asking if you want to define a dump device for this system while
booted off the Solaris Utility Environment. The device displayed is the first swap
partition (tag swap, flags wu) that was found on the disks listed in the
boot-device parameter in OBP. Setting this will give you the ability to
get a kernel core dump in the event the system crashes while booted off
this image (e.g. if SunVTS induces a hardware failure that causes a panic).
However, if your intention is to upgrade the firmware on any of the
components of the device listed (hba, disk, fc backplane, etc.), answer
this question 'no' to avoid 'must be sole user' or 'busy' errors during
the firmware upgrade process. If you set the dump device and then decide
later that you need to do a firmware upgrade on some component of it, you
can try to clear the dump device via /usr/sue/bin/cleardump.
Once a dump device is set, it's not possible to unset it via dumpadm. The only way to unset a
dump device is to activate it as a swap device, then delete the swap device. This is what the
cleardump script mentioned above does. On systems with low memory where the option is
chosen to increase the amount of virtual memory by adding a swap partition, the dump device
is set automatically when the swap partition is activated and can't be unset, even with the
cleardump script.
As mentioned in the message above, if you need to upgrade firmware on a system, be sure
that setting a dump device won't interfere with it. For example, if you need to upgrade the
firmware on a disk, or the HBA that the disk is connected through, don't set a dump device to
a partition on that disk. The firmware upgrade will fail if you do. Answer the dump device
question with n in this case when it comes up, or use cleardump.
As with all the other boot questions, the display of the dump device question is contingent on
whether the 'install' boot argument was set. If it was set, then dump device question will not
be asked. To set the dump device in this case, use the main menu option.

5 ► Text menus
5.1 Main menu
After the system is done with the boot process, it will present a menu like this:
*******************************************************************************
Solaris Utility Environment version 3.32
SunOS sselab1 5.10 Generic_142909-17 sun4u sparc SUNW,Sun-Fire-880
Patched with EIS 28SEP10 System serial number: 0343AM02B8
********************************** Main Menu **********************************
1) Invoke /bin/sh 10) Stop Veritas Volume Manager

2) Invoke /bin/ksh 11) Start Solaris Volume Manager
3) Invoke /bin/csh 12) Stop Solaris Volume Manager
4) Invoke /bin/bash 13) Import ZFS pools
5) SunVTS 14) Run findaft on root disk
6) Firmware menu 15) Run findUE on root disk
7) Set dump device 16) Run findfma
8) Clear dump device 17) Start LDOMS
9) Start Veritas Volume Manager 18) Stop LDOMS
-------------------------------------------------------------------------------
h) Halt system r) Reboot system d) Disable menu s) Help on GNU screen
u) View SUE User's Guide
-------------------------------------------------------------------------------
Enter selection:
The top two lines of the menu show the SUE version, along with the output of uname -a. In
this case the host, sselab1, is a V880 booted with SUE version 3.32. The third line displays
what version of EIS was used to patch the OS on the image. On the right side of the third line,
the system serial number (as extracted via SNEEP) is displayed on SPARC systems. If no
serial number was entered, the serial number is displayed as 'unknown'. The fourth line
states that this is the main menu (as opposed to the firmware menu). The x86 version of this
menu may look slightly different.
The menu is executed through a program called screen. The screen program is part of the
GNU project and is open source. It allows the user to run multiple terminal sessions
concurrently on a single terminal. Full documentation on screen is available via the man
page. Typing 's' in the menu also provides the following instructions for commonly used
functionality:
This menu is being run inside a program called GNU screen. To paraphrase from
the man page:
Screen is a full-screen window manager that multiplexes a physical

terminal between several processes (typically interactive shells).
What this means is that you can run multiple terminal windows from this one
window. Screen uses a control character to access its command set. The
control character is currently set to the default, Control-a (Control key and
the 'a' key simultaneously. After hitting Control-a, you then type in a second
character (after releasing Control-a) which represents the command. Some
common commands are:
Control-a c - Create new screen

Control-a n - Go to the next screen

Control-a p - Go to the previous screen
Control-a w - List all screens
For a complete list of commands, type Control-a ?
Main menu items are described in the table below.
Menu item Function

1) Invoke /bin/sh Bourne shell run as a login shell
2) Invoke /bin/ksh Korn shell run as a login shell
3) Invoke /bin/csh C shell run as login a shell
4) Invoke /bin/bash Born Again shell run as a login shell
5) SunVTS Run sunvts -t in a separate screen
6) Firmware menu Display the firmware menu
7) Set dump device Set the dump device to the primary swap partition (if any) of the disk
defined in OBP as boot-device. This is prompted for at boot time, but if it
wasn't set then, it can be set here. If the dump device is already set, this
option will only display what it is set to.
8) Clear dump device Unsets the kernel dump device. Useful if a dump device was set at boot
time and a firmware upgrade on some hardware component of that
device needs to be performed. Won't work if a swap partition was
activated to add more virtual memory to a system with less than 512MB
of memory.
9 Start Veritas Volume Manager Runs vxvm start. Enables access to the Veritas Volume Manager
configuration on a system.
10) Stop Veritas Volume Manager Runs vxvm stop. Disables access to the Veritas Volume Manager
11) Start Solaris Volume Manager Runs svm start. Enables access to the Solaris Volume Manager
12) Stop Solaris Volume Manager Runs svm stop. Disables access to the Solaris Volume Manager
13) Import ZFS pools Imports all ZFS pools found on the system. The pools are imported read-
only as Alternate Root Pools. See the Solaris 10u4 or higher man page
on zpool(1m) for more information on Alternate Root Pools.
14) Run findaft on root disk Runs the findaft script described in InfoDoc 80270. It provides a summary
listing of AFT (Asynchronous Fault Trap), CPU, and PCI ECC errors.
15) Run findUE on root disk Runs the findUE script descibed in InfoDoc 85108. Narrows down the
search for a bad DIMM within a bank by examining the ECC syndrome or
bit distribution.
16) Run findfma Runs the findfma script documented in InfoDoc 83483
17) Start LDOMS Start an LDOMS configuration and become the control domain
18) Stop LDOMS Shut down the LDOMS configuration
h) Halt system Performs an init 0 to shut down the system.
r) Reboot system Performs an init 6 to reboot the system.
d) Disable menu For those who don't want the menu, this will disable it and just run a
single shell as with older versions of the SUE.
s) Help on GNU screen A mini tutorial on navigating through GNU screen. GNU screen is used as
the wrapper for the menu and allows multiple ttys to run concurrently on a
single terminal device.

Menu item Function
u) View SUE User's Guide View this documentation via the Lynx text-based web browser.
Main menu options
The menu program is run out of SMF and it will continue to respawn itself if exited unless
option 'd' is selected. Option 'd' creates a file, /tmp/.nomenu, that signals the parent script of
the SUE menu not to run the menu program. To re-enable the menu after option 'd' is
selected, type the following:
rm /tmp/.nomenu; exit
5.2 Firmware menu (SPARC)

From the main menu select option 6 to be taken to the firmware menu. The menu looks like
this for SPARC:
*******************************************************************************
SunOS sselab1 5.10 Generic_142909-17 sun4u sparc SUNW,Sun-Fire-880
Patched with EIS 28SEP10 System serial number: 0343AM02B8
******************************** Firmware Menu ********************************
1) Disk 8) LSI controllers

2) OBP/flash 9) Jasper 320 LVD SCSI controller
3) Fibre Channel HBA 10) sun4v system firmware
4) 880/890 disk backplane 11) Adaptec SAS controller
5) ALOM 12) Auto firmware check
6) RSC 13) Main menu
7) v1280/2900/Netra 1280
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Enter selection:
The firmware menu has utilities for upgrading firmware for various Sun hardware. The table
below describes these options. Currently, there are no firmware options for the x86 version of
SUE, so this menu applies to SPARC only.
Menu Item Function

1) Disk Run upgrade_dfw, a perl script that compares the
disk firmware on the system against a database
created by the SUE build process and prompts to
upgrade. This functionality is described more fully in
the Disk Firmware section.
2) OBP/flash Run upgrade_obp. A utility to perform an OBP/flash
upgrade
3) Fibre Channel HBA Run upgrade_hba, a utility that scans the system and
prompts to perform appropriate fibre channel HBA
firmware upgrades for the system
4) 880/890 disk backplane Run upgrade_dbp script. This script will run the
luxadm command to upgrade the disk backplane
firmware on a v880.

Menu Item Function
5) ALOM Run upgrade_alom script. This script will upgrade the
ALOM firmware on the system controller.
6) RSC Upgrade the firmware on the RSC card. This utility will
also check the version of RSC software on the root
disk of the host so that it can provide the appropriate
warnings if there's a mismatch between it and the
version on SUE.
7) LOM Upgrade the LOM firmware. This utility will not
upgrade LOM firmware on systems with first
generation LOM chips.
8) v1280/2900/Netra 1280 Firmware Upgrade the system controller firmware on lightweight
8 systems via the lom interface. This includes RTOS,
ScApp, CPU, and I/O board firmware.
9) LSI controllers Upgrade a system that has an onboard LSI controller.
10) Jasper 320 LVD SCSI controller Utility to upgrade the FCODE on the Jasper 320 LVD
SCSI controller card.
11) sun4v system firmware Utility to upgrade the system firmware on the T1000,
T2000, Netra T2000, Sun Blade 6300, T5120,
T5220,Netra T5220, T5140, and T5240
12) Adaptec SAS controller Utility to upgrade firmware on the Cougar and
Prometheus SAS RAID cards.
13) Auto firmware check Utility to scan for the applicability of all the above
firmware (except the 1280/2900 SC firmware).
14) Main menu Returns to the main menu
SPARC firmware menu options
In addition to these menu options, the h (halt), r (reboot), d (disable menu), and s (help on
GNU screen) are also available as they are in the main menu.

5.3 Firmware menu (x86)
The x86 version of SUE has the following firmware menu:

*******************************************************************************
SunOS sselab7 5.10 Generic_142910-17 i86pc i386 i86pc
Patched with EIS 28SEP10
******************************** Firmware Menu ********************************
1) Disk
2) Fibre Channel HBA
3) Adaptec SAS controller
4) Auto firmware check
5) Main menu
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Enter selection:
These options for x86 perform the same function as their SPARC counterparts.

6 ► SunVTS
Running SunVTS wihin SUE is no different than running it off the root disk of the host. The
logs and all other transient data are still in /var/opt/SUNWvts. These logs will be lost once the
system is halted or rebooted, so if it's desired to keep the logs, they must be transfered to
another machine in order to save them permanently.
When running verbose mode in SunVTS, keep in mind that a Sun serial port console normally
operates at 9600 bits per second. Verbose mode may be a little overwhelming for the console
device and can make it difficult to get a reasonably quick response out of the console if you
want to terminate it or switch to another screen. It might be a good idea to either not run
verbose mode or telnet into the SUE booted host from another system and run SunVTS in
verbose mode from the telnet session.
Occasionally, SunVTS will tickle a fault in a system that will cause it to panic. If you set the
dump device at boot time, then you should be able to reboot the SUE and retrieve the core
file via savecore. If you're so inclined, you can also analyze it with Solaris CAT, which is also
installed on SUE. A panic while booted from SUE will not reboot the system because of the
set halt_on_panic=1 setting in /etc/system. This way if the system panics while it's not being
monitored, it won't reboot into the customer's OS, and the results of the panic will be left on
the screen.
There are times when the terminal emulation software or terminal type being used to access
the console of a system doesn't interpret the arrow keys correctly in SunVTS. In this case, the
following alternate key sequences can be used:
Control-r moves the cursor to the right.

Control-p moves the cursor to the left.
Control-u moves the cursor up.
Control-n moves the cursor down.
Control-w replaces TAB function.
Control-l (ell) Redisplay the screen.

7 ► Firmware
The firmware utilities on SUE are capable of detecting firmware levels present on the booted
system and comparing them to the patch versions it contains. The process of keeping these
patches up to date is completely automated by the SUE build process. In addition,
Notifications are made to the SUE developers when any new patches are released.
7.1 Disk Firmware

SUE contains the latest disk firmware patches that are available at build time. The SUE build
process puts these patches in the directory /usr/sue/firmware/disk along with two other files,
patchinfo, and diskfwdb. The patchinfo file is a composite text file that contains the one line
synopsis for each patch in the directory. The diskfwdb (disk firmware database) file is a file
created out of the build process that contains the following information for every disk firmware
patch in the directory:
• Patch number + revision

• Vendor disk model
• Firmware version of patch
The latter two pieces of information are obtained from the filenames of the actual firmware
files contained in the patches.
The purpose for creating the diskfwdb is to provide an easy mechanism to upgrade disk
firmware on a system. A perl script, upgrade_dfw, will run the explorer diskinfo command to
extract the SCSI inquiry data of all the individual disks that can be seen from the host,
compare it to the information in this database, and if applicable, prompt to upgrade. The
upgrade_dfw program can also be run by choosing menu option 1 in the text console
firmware menu. Here's an example of running upgrade_dfw
Scanning disks. Please wait...done. 7 devices scanned.
Found the following relevant disk firmware patch(es) for this system:
Patch Vendor Disk model Patch FW Disk FW # of drives

---------- ---------- -------------- ------------ --------- -----------
116464-02 HITACHI DK32EJ72F 2Q0J 2Q0F 4
Would you like to perform firmware upgrades [y/[n]/(s)how detail] ?
On this system, there were four disks that had firmware patches available on SUE. Note that
upgrade_dfw will only list the different disk types, and not the disks themselves. To display
information on all the disks, answer the above question with s for show detail.
Device Patch Vendor Model Patch fw Disk fw Upgrade ?
--------------- --------- -------- --------- --------- --------- ---------
c1t0d0s2 116514-10 FUJITSU MAP3735F 1701 1701 No
c1t1d0s2 109962-14 SEAGATE ST373405F 0638 0638 No
c1t2d0s2 116464-02 HITACHI DK32EJ72F 2Q0J 2Q0F Yes
Would you like to perform firmware upgrades [y/[n]/(s)how detail] ?

This same listing can be achieved by running upgrade_dfw -l from a shell prompt.
Answer y to proceed with the upgrades or n to quit. For SAS drives, it will perform the
upgrade on each drive individually. For normal SCSI drives, it will upgrade all the drives of a
specific model number (and patch) simultaneously.
If upgrade_dfw determines that there are no upgrades available, the following message is
displayed:
All disk firmware is up to date per this SUE release.
7.1.1 SunAlert 103174
SunAlert 103174 affects systems that use Solaris Volume Manager and disks that contain
metadbs that have their firmware upgraded. The key here is something called VPD page
0x83 support. VPD page 0x83 is a newer way for disks to identify themselves. The previous
method, called VPD page 0x80, simply used the disk serial number. VPD page 0x83 is a
more comprehensive identification method. SVM will use VPD page 0x83 if it's present. If not,
it will use VPD page 0x80. The problem described in this SunAlert comes about when a disk
that didn't previously have VPD page 0x83 support has it's firmware upgraded and that
firmware upgrade adds this support. The effect in SVM is that now the ID has changed for
these disks, causing the system's /kernel/drv/md.conf file to be out of sync with the actual IDs
on the disks. This situation will cause metadevices in SVM to disappear.
The SunAlert references specific drive models and firmware versions. However, the
practicality of maintaining such a list is seems to be unrealistic. In addition, the procedure in
the SunAlert has the user downgrade the firmware first to resolve it. The means that the user
needs to go digging through SunSolve to locate an older version of the firmware patch that
they just used to upgrade the firmware.
The upgrade_dfw program has the ability to detect when VPD page 0x83 support has been
added for a disk containing metadbs and is capable of mitigating the problem on systems that
have Solaris 10 installed by automatically fixing the md.conf on the root disk after the
firmware has been upgraded. If the upgrade_dfw program detects this situation, the following
will be displayed after the firmware upgrade(s):
The following disks had VPD page 0x83 support added to them as a result of
the firmware upgrade:
<disks listed here>
Because there is a Solaris Volume Manager configuration on this system, it is

now affected by SunAlert 103174 and the md.conf needs to be repaired.
Because of the differences in the device tree structures between Solaris 10 and previous
versions of Solaris, SUE cannot repair the md.conf on systems running versions of Solaris
prior to Solaris 10. If this is the case, the following message will be displayed:
Please follow the procedures documented in SunAlert 103174 to recover.
It will be necessary to downgrade the firmware as part of the procedures in the SunAlert.

However, if the OS version installed is Solaris 10, then the following will be displayed:
SUE is capable of performing this repair operation on the root disk.
Would you like to fix the SVM configuration (y/n) ?
A y response will run fixsvm, which will rebuild the metadbs with the new disk ID's and update
the md.conf on the root disk.
If something other than y is given to the above prompt, the following will be displayed:
Ok. But if the system panics when it's booted off the root drive, or if any of
the Solaris Volume Manager configuration comes up missing, boot SUE back up
and run fixsvm from the command line. The alternative is to follow the
procedure described in the SunAlert, which will require you to first downgrade
the firmware.

7.2 Upgrading OBP/POST
The following platforms are supported for upgrading OBP with the Solaris Utility Environment.
With the exception of SUNW,Ultra-Enterprise, all these platforms can be upgraded from SUE
with the following command line:
boot <device> -F obp_archive -D /flash/<platform name>
where <device> is the boot device containing SUE (e.g. cdrom,net) and <platform name> is
one of the strings listed below. The platform name can be determined by running uname -i on
the host in Solaris.
Patch Platform(s) System(s)

103346 SUNW,Ultra-Enterprise E3000, E4000, E5000, E6000, E3500, E4500, E5500,
E6500
104169 SUNW,Ultra-2 Ultra 2
105930 SUNW,Ultra-30 Ultra 30
106121 SUNW,Ultra-5_10 Ultra 5, Ultra 10
106122 SUNW,Ultra-4 E450
106455 SUNW,Ultra-60 Ultra 60, E220R, Netra 1120/1125
106503 SUNW,Ultra-250 E250
109082 SUNW,Ultra-80 Ultra 80, E420R, Netra 1400/1405
118323 SUNW,Sun-Blade-1000, SUNW,Sun-Fire- Sun Blade 1000, Sun Fire 280R, Netra T4, Netra T20, Sun
280R, SUNW,Netra-T4 Blade 2000
119232 SUNW,Sun-Blade-2500, SUNW,Sun-Fire- Sun Blade 2500, Sun Fire v250
V250
119233 SUNW,Sun-Blade-2500-S Sun Blade 2500 (Silver)
119235 SUNW,Sun-Blade-100 Sun Blade 100, Sun Blade 150
119236 SUNW,Sun-Blade-1500 Sun Blade 1500
119237 SUNW,Sun-Blade-1500-S Sun Blade 1500 (Silver)
121683 SUNW,Sun-Fire-V210, SUNW,Sun-Fire- Sun Fire v210, Sun Fire v240, Netra 240
V240, SUNW,Netra-240
121685 SUNW,Sun-Fire-V440, SUNW,Netra-440 Sun Fire v440, Netra 440
121688 SUNW,Sun-Fire-880, SUNW,Sun-Fire- Sun Fire v880, Sun Fire 890
V890
121689 SUNW,Sun-Fire-480R, SUNW,Sun-Fire- Sun Fire v480, Sun Fire v490
V490
121690 SUNW,Sun-Fire-V445 Sun Fire v445
1
121691 SUNW,Sun-Fire-V125 Sun Fire v125
121692 SUNW,Sun-Fire-V215, SUNW, Sun-Fire- Sun Fire v215, Sun Fire V245
V245
124410 SUNW,A892 Ultra 25
124411 SUNW,A70 Ultra 45
1 As with the Ultra 25, this is not the actual uname -i value, but the namesake of it's uname -i value (SUNW,Sun-Fire-V210) uses a
different OBP patch. However, use this value when doing OBP upgrades for the v125 from SUE.
2 SUNW,A89 is actually not the uname -i value returned on an Ultra 25, SUNW,A70 is (the same as the Ultra 45). This is a bug (6462199),
but it's unclear whether it will ever be fixed. For the purposes of doing OBP upgrades on the Ultra 25 from SUE, use SUNW,A89.

Alternately, the flash upgrade can be performed by first booting the Solaris Utility
Environment, then selecting the OBP/flash option from the firmware menu or running
upgrade_obp from a shell. Using this method will automatically determine the platform and
boot the necessary file. In addition, this is the only method that OBP/POST can be upgraded
on the SUNW,Ultra-Enterprise platform3, since the patch for this platform is script-based and
has no flash image to boot. For all the other systems listed in the table, a dialog similar to the
following will be displayed:
Patch: 119244-02
Platform: SUNW,Sun-Fire-880
Patch version: 4.18.8
System version: 4.18.6
Upgrade available: yes
This update requires booting the flash image.

Please modify any necessary jumper/keyswitch settings before attempting this.
The boot command is now set to:
reboot -- "/pci@9,700000/network@1,1 -F obp_archive -D /flash/SUNW,Sun-Fire-880"
Would you like to reboot with this image [y/n] ?
In this case, there is an available upgrade to OBP. Answering with a y will cause the script to
do a check on the NVRAM setting of auto-boot?. If the auto-boot? setting in NVRAM is set to
true, then the following message will be displayed at this point:
The flash update program does a reset in OBP when it's done. The auto-boot?
setting in NVRAM is currently set to true. This means that this system will
end up booting off the device defined as boot-device (most likely the boot
disk) when it's done updating OBP.
Would you like to set auto-boot? to false to prevent this from happening
and have the system drop to the OK prompt when it's done instead (y/n) ?
If you don't want the system to reboot to the device specified by boot-device when the flash
update is complete, answer with a y response. The system will reboot off the boot media (CD,
DVD, or network) and load the appropriate flash update program.
3 E3x00,E4x00,E5x00, and E6x00 systems.

7.3 Fibre Channel HBA firmware
The Solaris Utility Environment is capable of automatically detecting and upgrading the
firmware on all Sun-supported fibre channel host bus adapters that have FCODE patches via
the perl script upgrade_hba. This script is available as a menu option in the firmware menu
after the SUE boots. This script does the following:
• Reads a config file and a firmware version database file (created at build time). These files
contain information about patches, HBA types, patch HBA firmware revisions, and patch
dependencies
• Gathers information about the HBAs currently installed on the system using various
utilities.
• Compares this information to determine what HBAs are running what versions of firmware
on the system, and whether they need to be upgraded. It then presents this list of HBAs
and their firmware status.
• If there are JNI cards, it checks to see if SEEPROM patch 116424 needs to be applied as
per FIN I1081. If so, it will prompt to install the new SEEPROM code.
• Check the dependencies (on the real disk of course) of the installable firmware patches. If
there are any unsatisfied dependencies, it will list them,
• Prompt to run the firmware upgrade program from each patch that has associated
hardware on the system.
Here's an example of running upgrade_hba:
Found the following fibre channel HBAs
Patch HBA Patch FW HBA FW Upgrade

Device Path Available
---------- --------------------------------- ---------- --------- ------------
111853-03 ISP2200 (Amber/Crystal+/Diamond) 1.14.09 1.13 yes
/devices/pci@8,700000/pci@2/SUNW,qlc@4:devctl
111853-03 ISP2200 (Amber/Crystal+/Diamond) 1.14.09 1.13 yes

/devices/pci@8,700000/pci@2/SUNW,qlc@5:devctl
Checking dependencies: OS version on root disk is 5.9

Dependencies satisfied.
Proceed with upgrade (y/n) ?
If you answer with a 'y', the program will proceed to run the firmware installation program from
patch 111853. If there are multiple patches listed, the firmware installation for those patches
will be run once for each of them.
If you run upgrade_hba on a system with an onboard FC controller, the program will skip over
it and the following message will be displayed before the list of HBAs:
Skipping onboard controller (use OBP patch to upgrade):
/devices/pci@8,600000/SUNW,qlc@2/fp@0,0:devctl
The example above is from a v880. The other platforms that have onboard FC controllers are
the Netra T4, Sun Blade 1000, 280R, 480R, v490, and the v890.

7.3.1 Dependencies
The version of firmware loaded on a FC HBA corresponds to a particular driver version for
that HBA. It's important that the two match up in order to ensure correct functioning. The
driver and firmware versions are usually released as part of a larger package from Sun called
SAN 4.x. The upgrade_hba script will attempt to determine if the correct driver patch is
loaded on the root disk for each HBA that has been identified as being downrev from the
available firmware patch. It does this by mounting (read-only) the root filesystem from the
host4 and running a showrev -p against it. It then matches up the patch dependencies found
in the patchinfo files of the firmware patches against the output of showrev. If there are
dependencies that are not met, the following dialog will be displayed:
Checking dependencies: OS version on root disk is 5.9
The following patch dependencies have not been satisfied:
Firmware patch Failed Dependencies

114874-02 113043-06
The dependencies listed are patches that contain drivers and software that
correspond to the listed firmware patch(es). It is recommended to install
these patches on the root disk before upgrading the firmware.
Would you like to upgrade anyway (y/n) ?
This is saying that firmware patch 114874-02 has a dependency on patch 113043-06 being
installed on the root disk. You can proceed to upgrade the firmware anyway at this point, but
you'll need to install patch 113043-06 (and any dependencies that 113043-06 might have)
when you boot the system back up on it's normal root disk.
If upgrade_hba is unable to mount the root disk so that it can run showrev -p against it, the
following warning message will be displayed:
Checking dependencies: failed.
Warning: Root filesystem could not be mounted from boot disk.
No dependency checking done.
7.3.2 Fin 1081 and the JNI SEEPROM
The upgrade_hba script will detect the presence of JNI cards that are affected by FIN 1081. If
it finds any JNI cards with the generic subsystem-id set, it will prompt to install the SEEPROM
update on patch 116424 with the following dialog:
The SEEPROM values on at least one JNI card is incorrect as per FCO I1081.
This needs to be be corrected by applying patch 116424. Upgrading the
fcode on the affected JNI card(s) won't be possible until this is done.
Would you like to install the new SEEPROM now (y/n) ?
A 'y' response will cause the program to install the new SEEPROM on all affected JNI cards.
It is not possible to upgrade the JNI firmware on affected cards until the new SEEPROM is
written and the system has been reset. After the SEEPROM is updated on the cards, the
following dialog will be displayed:
The system needs to be reset to make the changes take effect
Would you like to reboot the SUE now ?
4 See Finishing up the boot in the Boot Process chapter for how it determines what the root filesystem is.

A 'y' response will cause upgrade_hba to reboot using the same boot path that was originally
used to boot the Solaris Utility Environment (rather than the root disk).
If an 'n' response is given to the SEEPROM question above, the program will continue
normally. However, any affected JNI cards will be flagged as 'not upgradable' as illustrated
below:
Found the following fibre channel HBAs
Patch HBA Patch FW HBA FW Upgrade

Device Path Available
---------- --------------------------------- ---------- --------- ------------
114873-02 ISP2300 (Amber2) 1.14.09 1.13.08 yes
/devices/pci@1f,4000/SUNW,qlc@2/fp@0,0:devctl
114873-02 ISP2300 (Amber2) 1.14.09 1.13.08 yes

/devices/pci@1f,2000/SUNW,qlc@1/fp@0,0:devctl
116423-03 JNIC1560 (Amber2J/Crystal2J) 1.5.1 1.0 no (SEEPROM)

/devices/pci@1f,4000/SUNW,jfca@4/fp@0,0:devctl
116423-03 JNIC1560 (Amber2J/Crystal2J) 1.5.1 1.0 no (SEEPROM)

/devices/pci@1f,4000/SUNW,jfca@5/fp@0,0:devctl
This status will also be displayed if the SEEPROM upgrade has been done, but the system
has not yet been reset.
7.4 V880/890 disk backplane

The upgrade_dbp utility will upgrade the fibre channel disk backplane firmware on the
v880/890. It will display the following prompt if an upgrade is warranted:
Current firmware = 9229
Patch firmware version = 922A
About to perform v880/890 disk backplane firmware upgrade. Please

note that the firmware upgrade may not actually take effect until
up to 15 minutes after this procedure is complete. Please monitor
the change in firmware version via the command
luxadm display FCloop
Alternately, you can monitor /var/adm/messages for the OFFLINE/

ONLINE messages that will occur when the disk backplane is done
resetting itself.
Do NOT reboot or reset this system until the firmware version has
changed to the desired version. If you do, the upgrade will not
complete.
Please make sure keyswitch is not in the locked position.

Upgrade [y/(n)] ?

7.5 ALOM Firmware
The Solaris Utility Environment contains the firmware and a script called upgrade_alom to
perform an upgrade of ALOM firmware on the systems listed in the table below. The script
can be run from firmware menu or from the command line.
System Platform
v125 SUNW,Sun-Fire-V210
Netra 210 SUNW,Netra-210
Systems with ALOM ports
Running this script on one of the above-mentioned systems will cause the following to be
displayed if the system is downrevved in it's ALOM firmware:
This will upgrade the ALOM/sc firmware to x.y.z
Type c to continue or a to abort:
One of the issues in upgrading the ALOM firmware is running the upgrade from the ALOM
controlled console. Since the SC will need to reboot a couple of times, it's possible that the
upgrade can get killed in the middle if run from the console device. This could possibly render
the SC unusable. Because of this, the ALOM upgrade utility on the SUE will generate the
following when it's run from the console:
You are attempting to run this upgrade from the console.The assumption here
is that your console device is on the ALOM port. You have two options:
- Continue and run the upgrade from the console. If you choose this
option, this script will execute the upgrade nohup in background.
The results of the upgrade will be logged to /tmp/upgrade_alom.log
- Abort and rerun this script from a telnet session. If you have
networking configured, open a telnet session into this host and run
upgrade_alom
Continue or abort [c/a] ?

Using this utility, you can safely continue the upgrade from the console because the upgrade
process gets detached from the console device and run in background, To monitor the
progress of the upgrade, run
tail -f /tmp/upgrade_alom.log
from a tty other than the console. Alternatively, just run upgrade_alom from a non-console tty.

7.6 RSC firmware
Select the RSC option from the firmware to run the upgrade_rsc script. This utility can be
used to upgrade the RSC firmware on the any of the systems listed in the table below.
System Platform
E250 SUNW,Ultra-250
280R SUNW,Sun-Fire-280R
480R SUNW,Sun-Fire-480R
V490 SUNW,Sun-Fire-V490
V880 SUNW,Sun-Fire-880
V890 SUNW,Sun-Fire-V890
Systems with RSC cards
The procedure is similar to the ALOM upgrade procedure. However, since there is OS-based
software included with the RSC software packages, the upgrade script checks the version of
the RSC software installed on the host. If the RSC software is present on the host, and it is a
different revision than the version on SUE, it will notify the user. In this case, the firmware can
still be loaded, but the RSC software on the host should be upgraded before using any of the
host RSC functionality.
For systems that have downrev firmware from that available on SUE, the following message
will be displayed:
This will upgrade the RSC firmware to x.y.z
Type c to continue or a to abort:
If you continue and attempt to perform the upgrade from the console, you will be presented
with the following:
You are attempting to run this upgrade from the console. The assumption here
is that your console device is on the RSC card. You have two options:
- Continue and run the upgrade from the console. If you choose this
option, this script will execute the upgrade nohup in background.
The results of the upgrade will be logged to /tmp/upgrade_rsc.log
- Abort and rerun this script from a telnet session. If you have
networking configured, open a telnet session into this host and run
upgrade_rsc
Continue or abort [c/a] ?
This is the same as running the ALOM upgrade from the console. The software will detach
itself from the controlling terminal (the console in this case) and send it's output to a log file.
7.7 v1280/2900/Netra 1280

The upgrade_lw8 script can be used to perform an upgrade using the LOM interface. If an
upgrade is needed, the following will be displayed:
This script will upgrade RTOS, ScApp, CPU board, and I/O board firmware on the
1280, 2900, or Netra 1280.

The process of upgrading the firmware will generate a number of messages
relating to the need to reset various components of this system. Please do
not reset anything until this script is finished. This will be evident from
the message "upgrade_lw8 script complete". At that point, only a reset in
OBP is required. A reboot will accomplish this.
Proceed (y/n) ?
A y response will upgrade RTOS, ScApp, and all CPU and I/O boards. If any part of the
upgrade fails, it will be necessary to manually complete the process for the components that
failed to upgrade.
This firmware can also be upgraded using the procedure described in section 7.12.
7.8 LSI controller firmware

Since most onboard LSI controllers use essentially the same procedure for performing
firmware updates, a generic utility has been created for all of them. The upgrade_lsi program
is capable up upgrading the following controllers:
System LSI Controller type

T1000 1064
T2000 1064e SAS
v245 1064
v445 1068x
Sun Blade T6300 1068e
Sun Blade T6320 1068e-b2 and 1068e-b3
Sun Blade T6340 1068e-b3
7.9 Jasper 320 LVD SCSI controller

The upgrade_jasper script will upgrade the FCODE on an LSI 1030 Jasper controller card. It
will not upgrade the onboard LSI 1030 controller on the v440, Netra 440, v1280, or 2900.
7.10 sun4v system firmware

The upgrade_sun4v utility can be used to perform a system firmware upgrade for the
following systems:
● Sun Fire/SPARC Enterprise T1000

● Sun Fire/SPARC Enterprise/Netra T2000

● SunBlade T63x0 blades
● SPARC Enterprise T5120
● SPARC Enterprise/Netra T5220
● T5140
● T5240
● T5440
● Netra T5440
Because part of the upgrade procedure requires the host to be powered off, the process isn't
entirely automated on SUE. However, the upgrade_sun4v utility will provide the correct ALOM
commands to complete the upgrade after it's done downloading the firmware. The
upgrade_sun4v program can be run from the command line of from the firmware menu.
There are two prerequisites for using this utility. First, there must be network connectivity
between the SUE booted host and the ALOM interface. Second, there must be an account
set up on the service processor that has it's cli_mode set to ALOM and role set to
Administrator. If there is no account set up for ALOM on the SP, one can be set up from ILOM
as follows:
-> create /SP/users/admin role=Administrator cli_mode=alom
Creating user...
Enter new password: *********
Enter new password again: *********
Created /SP/users/admin
The program will first check to see if an upgrade is warranted. If not, it will display the
following:
*****************************************
System firmware upgrade for sun4v systems
System type: SUNW,T5240
Patch: 136936-06
System version: 7.1.3.e
Patch version: 7.1.3.e
No upgrade available
On T1000 and T2000 systems, the login/password dialog below will be displayed first. This is
because the sysfwdownload binary is incapable of retrieving the firmware versions on these
systems, so the version need to first be retrieved from ALOM.
If there is an upgrade available, the following message will be displayed:

**************** PLEASE READ!!!! ****************
This firmware upgrade procedure has two parts to it. The first part is the
execution of this program. It will download the firmware to the system
controller. The second part of the upgrade requires that the host be powered
off and the 'flashupdate' command be issued from the sc> prompt. Please make
sure you follow the second part of the procedure after this program is done.
You will be prompted to power off and issue the flashupdate command.

Hit enter to continue:
After hitting the enter key, it will display some information on the upgrade to be performed.
*****************************************
System firmware upgrade for sun4v systems
System type: SUNW,T5240
Patch: 136936-06
System version: 7.1.3.d
Patch version: 7.1.3.e
The first time the upgrade_sun4v utility is run, it will prompt for the access information to the
ALOM port. Once this information is entered the first time from either program, it won't be
necessary to enter it again.
In order for this procedure to work, there must be network connectivity to the
system controller. In addition, an account must be set up in ILOM with it's
cli_mode set to alom and role set to Administrator. This can be accomplished
with the following command in ILOM:
create /SP/users/admin role=Administrator cli_mode=alom
Please provide the IP address, login, and password to access this ALOM account.
Enter sc IP address <IP address | (q)uit> : 10.2.20.144

Enter login: admin
Enter password:
Using ssh for ALOM communication
Once the program is able to talk to the ALOM, the following will be displayed
To ensure that the correct system controller is being accessed,
please confirm that the locator LED is currently lit on this system
Is the correct locator LED lit (y/[n]) ?
At this point, the locator LED should be lit on the system that you're expecting to upgrade.
This is just a safeguard to verify that the system controller that you intend to upgrade is really
the same system controller that you gave the IP address for previously. This is done because
there's no way to tell what the real IP address of the system controller is from the host. If it
turns out not to be the correct system, you'll need to clear out the ALOM access information
and rerun with the correct ip, login, and password. To clear out the ALOM information, open a
shell and type
rm /tmp/.alom
After answering y to the above response, the following will be displayed:
Download the system firmware to the system controller (y/[n]) ?
A y response to the download question will start the download process. Before the actual
download is performed, the program will check the status of the keyswitch on the ALOM. The
keyswitch setting needs to be set to normal for the upgrade procedure. If the keyswitch
setting is set to something other than normal, a message similar to this will be displayed:

Setting keyswitch from locked to normal for upgrade.
In this example, the keyswitch setting was originally set to locked and the program set it to
normal.
The download will now begin:

.......... (10%).......... (20%).......... (30%).......... (40%).......... (51%)..........
(61%).......... (71%).......... (81%).......... (91%)........ (100%)
Download completed successfully.
After the download is complete, the procedure for completing the firmware upgrade will be
displayed:
You must now log into the service processor from elsewhere to complete
the upgrade process. Once you are logged in, perform the following
procedure:
Power off the host:

sc> poweroff
Wait for the host to power down. The following message should be displayed
when this happens: SC Alert: Host system has shut down.
Load the firmware just downloaded:

sc> flashupdate -s 127.0.0.1
The following two lines will only be displayed if the program had previously changed the
keyswitch setting:
Set the keyswitch position back to it's previous state:
sc> setkeyswitch locked
After flashupdate is complete, reset the sc:

sc> resetsc
After the sc is done booting, log back in and power the system back on:
sc> poweron
The system will shut down now. Type a to abort or return to continue:
Hit return to shut the host down and then #. to go to the ALOM prompt. Once at the ALOM
prompt, perform the procedure given by the utility to complete the upgrade. If the given
procedure is not followed, then the firmware will not get upgraded. The upgrade_sun4v utility
on SUE only downloads the firmware to the system controller. The flashupdate command on
the ALOM needs to be executed (after the host is powered off) in order to actually load and
run the new firmware.
If you didn't perform this procedure from the serial port of ILOM/ALOM (i.e., you performed it
from a telnet or ssh connection into the ILOM/ALOM), then it will be necessary to log back in
to the system controller after executing resetsc.

7.11 Adaptec SAS RAID controller (Cougar/Prometheus)
SUE can be used to upgrade the firmware on the Cougar and Prometheus cards on both
SPARC and x86. Select the Adaptec SAS controller option from the firmware menu or type
upgrade_adptsas from a shell prompt. Dialog similar to the following will be displayed for
any controllers found that have downrev firmware:
Found 2 controllers
Controller # 1
---------------------------
Controller type: cougar
Controller fw version: 15825
Available fw version : 15872
Upgrade controller 1 (y/n) ? y
Answer 'y' for every controller that needs to be upgraded. The new firmware version will not
be reflected on the controller until a system reset is done.
7.12 Serengeti firmware

The latest firmware patch for the SF3800, 4800, 4810, 4900, 6800, 6900, 1280, 2900, and
Netra 1280 systems is included on SUE. Because of the nature of this firmware upgrade,
there is no automated procedure to perform it. However, there is a script to set SUE up as an
anonymous ftp server to make the patch directory available to the system controllers for
download. Network connectivity between the SUE booted host and the system controller(s) is
necessary for this to work.
To set up the SUE booted host as an anonymous ftp server, open a shell and type
setup_sgftp.
The first thing the script will do is check to see that you have networking configured. If not, it
will exit with the following message:
Error: There is no network setup on this system.
If networking is set up, the following will be displayed:

Setting up anonymous ftp server for upgrading the system controller firmware
on the following systems:
3800, 4800, 4810, 4900, 6800, 6900, 1280, 2900, and Netra 1280
Setting up anonymous ftp...done.

Please take note of the following:
- For flashupdate to work, there needs to be network connectivity from this

host (booted off of SUE) to the system controller that you plan to upgrade.
- It is recommended that upgrades be performed from the serial port of the

system controller so that the upgrade of RTOS and ScApp can be monitored.
- To upgrade the firmware, use the following commands from the platform shell
of the system controllers:
Main - flashupdate -y -f ftp://<IP ADDRESS>/pub/flash all

Spare - flashupdate -y -f ftp://<IP ADDRESS>/pub/flash rtos scapp
The system's primary IP address should be displayed in place of <IP ADDRESS>. Part of the
process of setting up the anonymous ftp server is to extract the latest Serengeti firmware
patch (located in /usr/sue/firmware/misc) into the anonymous ftp space so that the system
controller can access it.
The setup_sgftp script is not in the SUE firmware menu, essentially because it doesn't
perform the actual upgrade or any part of it. It must be run from the command line. Also,
setup_sgftp is available on both the SPARC and x86 versions of SUE, since the function of
an anonymous ftp server is platform independent.
7.13 Auto Firmware Check

The Auto firmware check option of the firmware menu will scan the booted host for applicable
firmware upgrades that SUE is capable of performing. If it determines that a particular
firmware upgrade is needed, it will run the appropriate firmware upgrade program.
There are two things to be aware of with auto firmware check. First, it will not scan for the
applicability of system controller firmware for the 1280/2900. This is because there is no
coherent way to tell what the current version of system controller firmware is from the host.
Second, for the older Niagara systems (T1000/T2000 and derivatives), it's not possible to
determine the system firmware version from the host without looking on the ALOM. While the
upgrade_sun4v program is capable of talking to ALOM after the correct IP address, login and
password are entered, it didn't seem appropriate to prompt for this information just to do a
scan. Because of this, the T1000/T2000 (and derivatives) will always come up positive in the
auto firmware check. Even if there is no firmware to upgrade, all that will happen is that auto
firmware check will run the firmware upgrade program, and the firmware upgrade program
will say that there's no upgrade to perform (after prompting for login, etc.). The newer Niagara
systems (e.g. T5120) don't have this issue as the sysfwdownload program is capable of
accurately reporting the system firmware version from the host on these systems.

8 ► Veritas Volume Manager
Veritas Volume Manager is a somewhat complex bundle of software, and this document
makes no attempt at any form of tutorial on it. It merely explains how to gain access to VxVM
configurations on a host while booted from the CD. The value of doing this is entirely up to
the user.
There are several ways to bring up Veritas Volume Manager while booted off the SUE. From
the command line, type vxvm start to gain access to the system's Veritas Volume Manager
configuration. The Main Menu option to Start Veritas Volume Manager can also be used.
The vxvm start command attempts to run the following in this order:
1. vxconfigd -m disable
2. vxdctl init
3. vxdctl initdmp
4. vxdctl enable
See the man pages for these commands to find out more about what the individual
commands do. If successful, running this sequence of commands will allow access to the
Veritas Volume Manager configuration installed on the host.
Most of the Volume Manager issues that SUE is useful in resolving are centered around
access to an encapsulated root disk. In the past, if a user couldn't boot a Volume Manager
encapsulated root disk, the user would have to boot the Solaris CD, mount the root filesystem
from a partition (if possible), modify etc/system, etc/vfstab, and touch
etc/vx/reconfig.d/state.d/install-db as part of the process of fixing it. This would have the effect
of manually unencapsulating the root disk. Once the problem was fixed from booting off of
CD, the user would then have to boot the root disk and re-encapsulate and remirror the drive.
This is a lot of work and has a high margin for error. This process is no longer necessary with
the SUE. It is now possible to work on the entire volume rather than just one of the slices.
As an example, say the /etc/vfstab file on a host with a VxVM encapsulated root disk was
damaged or deleted, but nobody found out until an attempt was made to reboot the system.
At this point, the machine won't boot.
Executing last command: boot
Boot device: disk1:a File and args:
SunOS Release 5.9 Version Generic_112233-10 64-bit
Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
configuring IPv4 interfaces: hme0.
Hostname: thehelm
/sbin/rcS: /etc/vfstab: cannot open
INIT: Cannot create /var/adm/utmpx
INIT: failed write of utmpx entry:" "
INIT: failed write of utmpx entry:" "
INIT: SINGLE USER MODE
Type control-d to proceed with normal startup,
(or give root password for system maintenance):

Even though you can log in at this point, you can't make any changes to the root filesystem
since it really isn't mounted (in this case because there's no vfstab entry). The normal course
of action would be to boot CD, manually unencapsulate the root disk, fix vfstab, boot, and re-
encapsulate. With SUE, you can boot the CD and run vxvm start or select the Start Veritas
Volume Manager option from the Main menu.
Normally, there will be a valid license present on the root disk of the host that has VxVM
installed on it (if there isn't, you have bigger issues). The vxvm script will attempt to extract
this license key and use it to license VxVM on SUE. In the event that there is no license on
the host or the vxvm script is unable to extract it, the following message will be displayed:
Importing license from host...failed.
************************************************************************
* No valid license was found for Volume Manager version 5.0.
* Run 'vxlicinst', enter a valid license key, and rerun this program.
* A demo license will be sufficient.
************************************************************************
In this case, it will be necessary to obtain a demo license to get access to VxVM functionality
while running SUE.
If all goes well with licensing, the following will be displayed:

Importing license from host...ok.
Apr 18 15:05:17 seagirt fbt: WARNING: couldn't allocate FBT table for module vxio
Apr 18 15:05:17 seagirt vxdmp: NOTICE: VxVM vxdmp V-5-0-34 added disk array DISKS, datype =
Disk
Started vxconfigd in disable mode...ok.
Running vxdctl init...ok.
Running vxdctl initdmp...ok.
Running vxdctl enable...ok.
* Volume manager is enabled.To access the volumes, use either *

* vxvol -g <dgname> start <volumename> *
* vxvol -g <dgname> startall *
* Be aware that starting a volume may cause a sync operation *
* to start, depending on the state of it's plexes. *
It is safe to ignore the fbt driver warning. See CR 6411105 for details.
It is now possible to start volumes. Once the volumes are started, any number of things may
be done including mounting filesystems that exist on volumes, running vxdiskadm, etc. At this
point, the issue of the trashed /etc/vfstab in the above example can be repaired by performing
the following:
• vxvol startall
• mount /dev/vx/dsk/rootdg/rootvol /mnt
• cd /mnt/etc
• Fix whatever's wrong with vfstab
• cd /; umount /mnt
• reboot
Resolving the problem in this manner required no changes to the VxVM configuration and
can be accomplished in a much shorter period of time, especially on large servers that take
longer to boot.

It's not necessary, but it's usually a good idea to stop Volume Manager before bringing down
the machine. This can be accomplished via vxvm stop or the Stop Veritas Volume Manager
menu item. This dialog displays the normal shutdown of Volume Manager using the vxvm
stop command:
Killing vxconfigd...done.
Unloading vxspec module...done.
Unloading vxio module...done.
Unloading vxdmp module...done.
Volume manager stopped.
If vxvm stop is attempted while there are still Volume Manager devices mounted, the following
dialog will be displayed:
Killing vxconfigd...done.
Unloading vxspec module...done.
Unloading vxio module...failed.
Are all vxvm filesystems unmounted ?
Veritas Volume Manager is available on both the SPARC and x86 versions of SUE.

9 ► Solaris Volume Manager
Solaris Volume Manager configurations on a host can be accessed from SUE through the
svm script. It works similarly to the vxvm script. To allow access to the SVM configuration,
type svm start or select the Start Solaris Volume Manager option from the main menu. This
will use the /tmp/.rootdev file to determine the root device (see Boot Process), and attempt
to find the location of the metadbs by reading the kernel/drv/md.conf file off it. It will also
import the nmd and md_nsets parameters from it as well. Once access to the metadbs is
accomplished, the script creates the md.conf locally (in /tmp), reloads the md driver, and runs
devfsadm5. At this point, the metadevices will be accessible as such. If svm start is
successful in bringing up the SVM configuration, it displays the following dialog:
Retrieving md.conf...done
SVM successfully started
The Solaris Volume Manager configuration has been

started. If you need to effect any changes on existing
metadevices, you may need to execute 'metasync -r' before
doing so to set the state of these devices to 'Ok'. Be
aware that executing metasync -r will cause any unsynched
mirrors or RAID 5 devices to start synchronizing.
Devices viewed via the metastat command may display a status of Needs Maintenance until
metasync -r is run.
If there is a problem importing the kernel/drv/md.conf file from the root device, then the
following dialog is displayed:
Retrieving md.conf...failed.
Unable to import md.conf - File is empty.
To bring down the SVM configuration, run svm stop:

Unloading SVM modules...done.
Restored /kernel/drv/md.conf
SVM successfully stopped.
5 In case the imported nmd and md_nsets parameters from md.conf are set higher than the defaults. This way
all the necessary /dev and /devices links will get created.

10 ► ZFS
The ZFS configuration on a host can be accessed with the Import ZFS pools menu item or
the zfsimport script. When ZFS pools are imported with this utility, they are imported read-
only. In addition, they are imported as Alternate Root Pools. The zpool(1m) man page in
Solaris 10u4 and higher has this to say about alternate root pools:
By default, whenever a pool is created or imported on a system, it is permanently added so that it is available
whenever the system boots. For removable media, or when in recovery situations, this may not always be
desirable. An alternate root pool does not persist on the system. Instead, it exists only until exported or the
system is rebooted, at which point it will have to be imported again.
This means that it is safe to import the ZFS pools on SUE as alternate root pools. Please be
aware that if the ZFS pools are imported as normal pools (via command line), then the
configuration will be altered. In addition, importing a pool means mounting all the
filesystems in that pool. Because of the read-only nature of the SUE root filesystem, these
mount operations will most likely fail. When using the zfsimport script, all mounts are done
under /tmp/zfs.
Since the pool is imported read-only, all the filesystems will be mounted read-only as well. If
read-write access is needed to a filesystem, it can be mounted as such after running
zfsimport with the following command line:
zfs mount -o remount,rw <filesystem name>
Where <filesystem name> is the identifier that appears in the NAME column of zfs list, not
the mountpoint.
Below is an example of running Import ZFS pools from the menu or zfsimport from the
command line:
This utility will search for any existing ZFS pools on this system
and attempt to import them as read-only Alternate Root Pools. As
such, the ZFS configuration will not be altered in any way. All
filesystems mounted as a result of the import will be mounted under
/tmp/zfs. See the SUE documentation for more information.
Searching for pools. This may take a minute...done.
Pool Status
-------------------- --------------------------
pool1 ONLINE
pool2 ONLINE
Import these pools (y/n) ?
An answer of y will cause the zpool import command to be run on each pool identified:
Importing pool pool1 ...done.

Importing pool pool2 ...done.

There is no menu item or utility to export the pools. This is because there is no option to
zpool export that will not modify the configuration. If the pools are exported while booted
from SUE, the pools will remain exported after booting the normal OS disk. This can cause all
kinds of problems with the operation of the system as it will be missing filesystems when it
boots up. Do not export any pools when booted off of SUE. Leave them imported in SUE
when you reboot. This will leave the configuration untouched. If, for some reason, the pools
are exported when booted off of SUE, recovery can be performed by doing the following:
● Boot the OS off the root disk in single user mode (boot -s)
● zpool import any pools that were exported from SUE
● reboot the OS normally off the root disk.

11 ► Creating a Network Boot Image
11.1 Setting up a boot server
As of SUE 3.23, the CD/DVD images have become fairly endian-neutral and occupy only one
slice. This means that the endian conversion programs that existed on previous versions of
SUE are no longer needed and have been removed. The advantage here is that a SPARC
boot server can be set up on an x86 system simply by running setup_install_server from the
SPARC CD/DVD mounted on the x86 system. The same is true in setting up an x86 boot
server on a SPARC system.
In most cases, setting up the Solaris Utility Environment for use as a network boot image is
no different than setting up a normal Solaris network boot server. The setup_install_server,
add_install_client, and rm_install_client scripts are all in the Solaris_10/Tools directory of
the CD/DVD and can be used to create a network boot image of the CD/DVD and configure
clients for the image6.
If setting up the SUE net image on a SF12K/15K/20K/25K system controller, it is

recommended to inspect /etc/bootparams and /tftpboot before running add_install_client out
of the SUE image directory. Most likely, the domains are already set up to boot off the net via
the system controller. In this case, it's probably easier to manually change /etc/bootparams to
point the domain to the SUE image.
It's not necessary to have a physical CD to set up a network boot server from SUE. The ISO
image itself can be used utilizing the setup_from_iso script contained in the Solaris_10/Tools
directory. Below is an example of how this works. It assumes that the ISO image is in the
current directory and that we're extracting the image to /var/tmp/sue.
# lofiadm -a `pwd`/sue-3.32-sparc.iso
/dev/lofi/1
# mount -F hsfs -o ro /dev/lofi/1 /mnt
# cd /mnt/Solaris_10/Tools
You can now run setup_install_server to copy the boot image.
Whether using a lofi mounted image or a physical CD/DVD, it's also possible to set up a boot
server without using setup_install_server. The image itself can be shared on the network for
clients to boot from. To use this configuration, simply run add_install_client directly from the
CD/DVD/lofi device without running setup_install_server. This is the quickest way to set up a
boot server, but requires that the CD/DVD remain in the drive or the lofi image remain
mounted while any boot clients are booted off the image.
6 Even though scripts have the word install in them, no installation can occur using the SUE net image as the
installation scripts and packages are missing from it.

11.2 Dual boot DVD
The dual boot DVD adds a little complexity to setting up a boot server. To start with, the
specific platform image that gets mounted depends what type of medium is being used to
mount it and the type of platform it's being mounted on. The table below shows the various
iterations of when the x86 image will be mounted versus when the SPARC image will be
mounted.
Media type DVD lofi mounted ISO image

System type
SPARC slice 0 - SPARC x86
slice 1 - x86
x86 x86 x86
As is evident from the table, the only time the SPARC image will get mounted from the dual
boot DVD is when a physical DVD is mounted on a SPARC system.
In addition, both the SPARC and x86 sections of the DVD can be mounted by using the slice
listed above. Unfortuntely, it's currently not possible to mount the SPARC section on an x86
system. However, it's still possible to extract the SPARC section of the DVD from x86 for the
purpose of setting up a SPARC boot server on an x86 system.
To avoid confusion with setting up a boot server from the dual boot DVD, the
setup_boot_server script can be used. The setup_boot_server script is essentially a
wrapper for setup_install_server, except that it's capable of extracting either the SPARC or
x86 image from the dual boot DVD regardless of what platform it's run on. In addition, it will
be obvious which platform image is being set up. The usage for setup_boot_server is:
./setup_boot_server [ -t tmpdir ] [ -p platform ] <directory>
-t tmpdir Allows you to specify an alternate temporary directory that the script uses to
save temporary image files. The default is /var/tmp. If there's not enough
room in /var/tmp to hold an ISO image of the SUE CD (up to 660MB), set
this to a directory that has enough space.
-p platform Only valid on the dual boot DVD. Allows you to specify which platform image
to use - sparc or i386. If this option is not specified for the dual boot DVD,
then setup_boot_server will prompt for the platform type.
directory The directory to dump the image in. This argument is passed on to
setup_install_server and is required.
The setup_boot_server script resides in the same directory as setup_install_server,

add_install_client, and rm_install_client, i.e., Solaris_10/Tools. Also, since setup_boot_server
is really a wrapper script for setup_install_server, it can be used in its place, even when not
working with the dual boot DVD.

11.3 Hands-off booting
It's possible to set up a SUE network boot to be completely hands-off, much the same way
that a hands-off jumpstart installation is performed. There are a few things that need to be set
up beforehand to do this.
The first thing that needs to be done is to set up a sysidcfg file to pre-answer all the system
identification questions. This is done exactly the same way as for a jumpstart installation.
Here's an example of a sysidcfg file:

root_password=4jnQ29DK0cAtQ
system_locale=C
timeserver=localhost
timezone=US/Eastern
terminal=vt100
security_policy=NONE
nfs4_domain=dynamic
network_interface=PRIMARY {hostname=sselab7 ip_address=129.154.57.219 netmask=255.255.255.0
protocol_ipv6=no default_route=129.154.57.228}
Since 'C' is the only locale installed on SUE, it must be specified for system_locale. If any
other locale is specified, the boot will issue a warning about locale not found and ask for both
the terminal type and locale.
Use the -p option to add_install_client to specify the location of your sysidcfg file. Doing so
will put the correct entry into bootparams (SPARC) or menu.lst (x86). For example:
add_install_client -p freehold:/export/home/config sselab7 sun4u
will set up client sselab7 in /etc/bootparams to use a sysidcfg file located in the directory
/export/home/config on freehold. Make sure that the directory you specify is shared
appropriately and that the configuration file is called sysidcfg. It may also be necessary to
specify the IP address of the NFS server rather than the host name.
Once add_install_client is run for SPARC, boot the image via

boot net - install
(boot space net space dash space install)
For x86, you'll need to modify the menu.lst that add_install_client created to add the '- install'
(dash space install) option. To do this, open /tftpboot/boot/grub/menu.lst with your favorite text
editor and add ' - install' (space dash space install) directly after kernel/unix on the kernel line.
Leave a space between 'install' and anything that comes after it. At this time, you can also
change this line to boot the 64-bit kernel instead. Change kernel/unix to kernel/amd64/unix to
accomplish this.
The 'install' option won't really do an install. This keyword was kept to insure compatibility with
the normal Jumpstart mechanisms. When using the 'install' boot option, the behavior of the
SUE-specific boot questions will be answered as follows:

● On SPARC systems with less that 512MB of memory, no prompts will be made unless
SUE can't determine what to do about the shortfall of memory. If it's able to find a valid
swap device on the boot drive, then it will automatically use it to increase the amount
of virtual memory on the system.
● SNEEP prompt will be bypassed
● No prompt will be made to set the dump device, and the dump device will not be set
(unless a swap device was added due to lack of virtual memory, in which case it will
already be set as the dump device). The dump device can be set from the main menu.

11.4 WAN booting (SPARC only)
As of release 3.31, a script has been added to the Solaris_10/Tools directory called
setup_sue_wanboot to simplify setting up SUE for WAN booting. Simply run the script from its
directory to set up a system as a WAN boot server for SUE.
# ./setup_sue_wanboot
Using server IP address of 10.143.2.81
Starting Apache web server
Apache web server started successfully
Creating wanboot directory structure in /var/apache2/htdocs/suewbd
Running setup_install_server
Verifying target directory...
Calculating the required disk space for the Solaris_10 product
Calculating space required for the installation boot image
Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Copying /boot netboot hierarchy...
Installing /mnt/boot/sparc.miniroot as /var/apache2/htdocs/suewbd/wanboot/wpath/miniroot
WAN boot Image creation complete
The WAN boot Image file has been placed in
/var/apache2/htdocs/suewbd/wanboot/wpath/miniroot
Ensure that you move this file to a location
accessible to the web server, and that the
WAN boot configuration file wanboot.conf(4)
for each WAN boot client contains the entries:
root_server=<URL>
where <URL> is an HTTP or HTTPS URL
scheme pointing to the location of the
WAN boot CGI program
root_file=<miniroot>
where <miniroot> is the path and file
name, relative to the web server
document directory, of 'miniroot'
You should also make sure you have initialized
the key generation process by issuing (once):
# /usr/sbin/wanbootutil keygen -m
Install Server setup complete
Copying wanboot binaries
Wanboot server is set up for SUE. The default platform configured is sun4u. If
you need to set up for a different platform (i.e. sun4v or sun4us), modify the
file /etc/netboot/wanboot.conf and point boot_file to the correct image. The
add_install_client script must be run for each system that will be booted with
SUE.
On the client, perform the following from OBP (assumes OBP > 4.13):
setenv network-boot-arguments host-ip=<client IP>,router-ip=<client def route>,subnet-mask=<client
subnet mask>,hostname=<client hostname>,file=http://10.143.2.81/cgi-bin/wanboot-cgi
Then type:
boot net - <SUE boot option>
where <SUE boot option> = autocfg, mancfg, nocfg, or install. See the SUE
documentation for more information.
The script simply sets up the directory structure under /var/apache2/htdocs and creates
/etc/netboot/wanboot.conf. Any customizations (e.g. setting up keys, separate networks,
clients) to this configuration will need to be done manually, but it provides a starting point that
will function.

At this point, add_install_client may be run for the clients that are to be booted with SUE.
Each client will also need network-boot-arguments set in OBP. If an automated boot
(jumpstart) is desired, place the sysidcfg, profile, and rules file in the
/var/apache2/htdocs/suewbd/config directory and use the -c and -p options of
add_install_client to point to this directory. It may be necessary to adjust the NFS share that
add_install_client sets up to include the entire suewbd directory.
Thanks to Dan Transue for coming up with the procedure used in this script.

12 ► USB Flash Drive booting (x86 only)
As of SUE version 3.14, it is possible to set up the x86 version of SUE on a USB flash drive
for those systems that are capable of booting from one. To accomplish this, run the script
setup_flash_drive in the Solaris_10/Tools directory of the SUE image. This script will not
only create a bootable SUE image on the flash drive, it will also create a scratch area as a
pcfs with whatever space is left over on the drive to provide a non-volatile area to write to
while SUE is booted.
12.1 Creating a bootable SUE flash drive

Before we go through the procedure to install the SUE image on a USB flash drive, it is
important to understand that this procedure will completely wipe out anything that is on
the flash drive. In addition, it is assumed that this procedure is being performed on a system
running Solaris 10.
To install SUE on a flash drive, vold must first be disabled (at least for the flash drive itself).
The reason for this is that when a flash drive is under vold control, there is no way to access
the p0 (whole drive) device for installing the fdisk partition table. In addition, vold provides no
way to completely remove a device from it's control once it has assumed control of it. To
disable volume management:
svcadm disable volfs
Once vold has been disabled, manually mount your CD, DVD, or ISO image:
For CD or DVD:
mount -F hsfs -o ro /dev/dsk/<device> /mnt
For ISO images:

lofiadm -a <full path to ISO> (returns the device to use in the next step)
mount -F hsfs -o ro <lofi device> /mnt
Once your SUE image is mounted:

cd /mnt/Solaris_10/Tools
./setup_flash_drive
Running this will display the following:

Warning! This operation will destroy the contents of your flash drive.
Continue (y/n) ? y
Select a device to use:
1. /dev/rdsk/c4t0d0p0 (SanDisk U3 Contour 4.04)

2. /dev/rdsk/c4t0d1p0 (SanDisk U3 Contour 4.04)
Select the flash device to use.

Enter number: 1
At this point, the creation of the SUE flash drive image will begin.
Creating flash drive fdisk partitions...done.
Scratch area size = 3316MB
Creating Solaris VTOC...done.
Creating root filesystem on flash drive...done.
Copying image...done. 1187248 blocks copied.
Installing GRUB on flash drive.
stage1 written to partition 1 sector 0 (abs 6795264)
stage2 written to partition 1, 265 sectors starting at 50 (abs 6795314)
Unmounting flash drive...done.
Operation complete. SUE image transfered to flash drive.
If there are no errors, then the flash drive can now be removed and used for booting on a
system that supports it. If you disabled vold, you can re-enable it now by typing:
svcadm enable volfs
By default, the setup_flash_drive script will use /var/tmp as a scratch area for creating
filesystems, miniroots, etc. If there's not enough space in /var/tmp for this, an alternate
directory may be specified with the -t option:
./setup_flash_drive -t /reallybigtmp
12.2 Booting the flash drive

To boot the flash drive, you'll most likely need to go into the BIOS settings and set the boot
device first. Other than this, the boot process is pretty much the same as for other types of
media. The scratch area created by setup_flash_drive will get mounted under /save when
SUE is booted. The exception to this is that if an in memory boot is performed from the flash
drive, the scratch area won't get mounted as the assumption is that the user wants to remove
the drive after booting and use it elsewhere. In this case, having the scratch area mounted
becomes problematic.
A feature of having this scratch area is the ability to automatically run your own customized
program after SUE is done booting. The SUE boot process will look for the existence of a file
named /save/autorun and execute it instead of the SUE menu if it finds it. It will only execute
this program once. Once it is done, a shell prompt will be given. If it is desired to bring up the
SUE menu at this point, type in:
rm /tmp/.nomenu; exit
The standard SUE menu should appear.

13 ► ECC Utilities for SPARC (cediag, findaft, fin954)
Three utilities for examining and diagnosing ECC errors on UltraSPARC systems are
available in SUE. The use of these utilities and the thought behind them is documented in
various FINs and InfoDocs in Sunsolve. They are all available in the main menu which runs
them via wrapper scripts. The wrapper scripts provide a simple mechanism to run the utilities
against the log files on the root disk of the host, rather than against the log files of the booted
image. Selecting a utility from the main menu will run it against all the messages files found
in /var/adm on the OS disk (i.e. /var/adm/messages*).
13.1 findaft
findaft provides a summary of AFT (Asynchronous Fault Trap), CPU, and PCI ECC errors
found in the system log files. It provides no diagnosis, but provides a good reference for
examining these types of errors. It's use is documented on Sunsolve in InfoDoc 80270.
13.2 findUE
The findUE script helps narrow down the analysis of a UE and reduce the number of DIMMs
that need to be replaced. It does this by examining the ECC syndrome or the bit distribution
from the AFAR to identify a specific DIMM rather than just the bank. Please refer to InfoDoc
85108 for more details.
13.3 findfma
The findfma script is a command line summary script for fmdump -eV outputs. This output is
useful where multiple DIMMs are reporting CEs. It is not meant for general diagnosis of faults.
FMA automates this already. It is meant for further analysis and improvement of the FMA
diagnosis algorithms. See InfoDoc 83483 for more information.
The wrapper script for findfma processes the in-memory FMA errors by default. It can also be
used to process the FMA error log on the root disk of the system by answering the following
prompt with an n:
Run against in-memory log ([y]/n) ?
However, using the data obtained from the on-disk error log as the basis for part
replacement should only be done at the direction of PTS or backline support. This
should be evident from the following warning message and prompt, which are displayed when
the on-disk log is selected:
------------------------------------------------------------------------
WARNING!
You have chosen to run findfma against the system root disk error log.
The faults listed are historical and may have already been resolved. Do
NOT replace any parts based on this information without confirmation from
backline support or PTS that parts actually need to be replaced.
Type 'ack' to acknowledge that you have read this and understand it.
-------------------------------------------------------------------------

Enter 'ack':
Enter ack to continue processing.
13.4 ECC errors and /etc/system

SUE has the following settings pertaining to ECC errors in /etc/system:
set aft_verbose=1
set ce_verbose_memory=2
set ce_verbose_other=2
However, this will only affect the reporting of ECC errors that occur while SUE is booted.
Since the wrapper scripts process the log files from the OS disk, the relevance here is to
have these settings set in /etc/system on the OS disk. Refer to InfoDoc 70702 for more
information on these settings.

14 ► Device path decoder
The Solaris Device Path Decoder is an attempt to remove the guesswork from identifying
devices from Solaris device paths across the range of Sun hardware. It can provide the
location, type and various pieces of information on most Sun platforms and Sun devices.
The difficulty with a number of Solaris platforms is that in order to correctly read a device path
you must know either a set of rules or have a table to look up. Once you have done that you
still may not know what the end device is. What the decoder aims to do is to take any path
and provide consistant and human readable output to aid in diagnostics, documentation and
system planning.
The device path decoder is an independent project from SUE and is not developed by the
developers of SUE. Nonetheless, if you have any questions about it, please send them along
to the appropriate SUE support alias and we will forward to the developers of the device path
decoder.
Output from the decoder will look something like this:

Enter path? /devices/pci@8,600000/SUNW,qlc@2/fp@0,0:fc
Possible machines:
0. Sun Fire V880
1. Sun Fire V880z
2. Sun Fire V890
3. Sun Fire V480
4. Sun Fire V490
Selection [default: V880]: 0
Sun Fire V880
System Board
Mainboard device
Node: SUNW,qlc@2
Desc: Onboard FC Network Adaptor
Node: fp@0,0:fc
Desc: Fibre Channel port

15 ► devfsadm
There are a number of programs on the Solaris Utility Environment that require running
devfsadm to create new device paths. When booted off a standard boot disk, this isn't a
problem since the /etc/path_to_inst file and the /dev and /devices directories are all writable.
However, when booted off a CD or the network, anything outside of /tmp is not writable.
Because of this, devfsadm will normally generate the following errors when it's run on a
CD/DVD or net booted system:
devfsadm: mkdir failed for /dev 0x1ed: Read-only file system
devfsadm: inst_sync failed for /etc/path_to_inst.392: Read-only file system
This means that devfsadm was unable to update the system. There are two options that can
be provided to devfsadm to get around this. The first is -r which is used to specify an alternate
root directory of where the /dev and /devices directories live. The second (undocumented)
option is -p. This option is used to specify the location of the path_to_inst file.
Because of all this, in SUE, the devfsadm command has been moved out of /sbin and
replaced with a wrapper script that forces calling the devfsadm binaries with the correct -r and
-p options. This ensures that the path_to_inst file and /dev and /devices directories will
always get updated correctly when a program or person runs devfsadm. This means that
devfsadm can be run on SUE without specifying these options.

16 ► DtraceToolkit
SUE includes a copy of the DTrace Toolkit. The toolkit is available in /opt/DTraceToolkit and
may assist in debugging some issues. The following is an excerpt from the README file that
is supplied with the toolkit. We provide it here so that one can find the scripts they need
easily.
The DtraceToolkit file hierarchy is as follows:
/opt/DTraceToolkit
Bin/ Symlinks to the scripts
App/ Application specific scripts
Cpu/ Scripts for CPU analysis
Disk/ Scripts for disk I/O analysis
Docs/ Documentation
Contents Command list for the Toolkit
Examples/ Examples of command usage
Faq Frequently asked questions
Links Further DTrace links
Notes/ Notes on Toolkit commands
Readme Readme for using the docs
Extra/ Misc scripts
Guide The README file (actually the README is a link to Guide.)
Kernel/ Scripts for kernel analysis
License The CDDL license
Locks/ Scripts for lock analysis
Man/ Man pages
man1m Man pages for the Toolkit commands
Mem/ Scripts for memory analysis
Net/ Scripts for network analysis
Proc/ Scripts for process analysis
System/ Scripts for system analysis
User/ Scripts for user based activity analysis
Zones/ Scripts for analysis by zone
Version DTraceToolkit version
install Install script, use for installs only
When you type ls in the DtraceToolkit directory, you will be looking at the top ten or so most
useful scripts. Other scripts have been placed in meaningful subdirectories, such as Disk,
Kernel, Proc, etc. An optional Bin directory has been provided that links to all the scripts.

The DTraceToolkit is released under the CDDL license. It's the same freeware license that
OpenSolaris has been released under.

17 ► scrubber
Included on SUE and SUE++ is a disk scrubber program that can perform automated read
tests or destructive data wipe operations on disks. No claims are made on how effective this
scrub operation is or whether it's sufficient for your customer. The implications on it's
effectiveness can be derived from how it works. The scrubber uses the Solaris format
command to perform an analyze->purge on each selected disk twice, once with the original
manufacturer's defect list and once with a merge of the manufacturer's defect list and the
grown defect list.
Because the scrubber can be so destructive to a system, it is not in the SUE menu nor in the
SUE++ GUI. It must be run from the command line. The command line synopsis is:
scrubber [ -x [ -b ]] [ -d disk1,disk2,... ]
Where the following options are supported:
-x
Tells scrubber to run in destructive mode. This causes scrubber to use the analyze-
>purge command in format on the selected disks. Without the -x option, scrubber
will run the analyze->read command in format.
-b
Force the scrubber to operate on the boot device. This option is primarily for running
the scrubber while booted off the Solaris Utility Environment (SUE). It disables the
safety check that precludes the boot device from being selected in destructive
mode. If booted off the boot device, the boot device will be excluded by the fact that
it's part of a mounted filesystem. In that case, the -b option won't have any effect.
-d
Provide a comma separated list of disks to perform the scrub operation on. If no -d
option is given, scrubber will obtain its list of disks from the contents of /dev/rdsk as
format does.
For more detailed information on using the scrubber, see the man page on SUE by typing:
man scrubber
while booted off of SUE.

18 ► Online documentation
A copy of this document has been placed on the SUE image and can be viewed by typing u
from any menu. This will invoke the text-based Lynx web browser and display an html version
of this document. The browser itself is fairly intuitive and has a search capability. Information
on it's use can be found by typing h after bringing it up.
Online documentation is also available on SUE++ through the context-sensitive help.

19 ► LDOMS (SPARC only)
As of SUE 3.29, support for accessing LDOMS configurations on sun4v systems has been
added. The SUNWldm package has been added and a utility script called ldomctl has been
written to facilitate activating and deactivating the LDOMS configuration and having the SUE
booted host act as a control domain. The ldomctl script can be run from the command line or
from the main menu.
The ldomctl script takes two arguments: start and stop. The start option will:
• Attempt to retrieve the LDOMS configuration from the boot disk

• Start ldmd
• Start the virtual network terminal server daemon (vntsd)
All three of these steps must succeed to be able to access LDOMS on the host.
The stop argument simply kills vntsd and ldmd.

20 ► SUE++ Interface
SUE++ is a release type of SUE that contains all the functionality of the standard SUE image,
plus a graphical user interface. The GUI uses the following components.
● X Windows
● fvwm window manager
● Opera web browser
● Java
● PHP
SUE++ has both a SPARC and an x86 version. Each one is over 2.5GB in size.
20.1 X configuration
As with standard SUE, SUE++ will also boot to the text menu described in section 5.1.
However, there will be an extra option listed towards the bottom of the menu entitled Start X
windows. If the system has a graphical head (i.e.video card/framebuffer, keyboard, mouse),
selecting the x option from the menu will cause the GUI to be started on the console. On
SPARC systems, the GUI should automatically come up. On x86 system, kdmconfig will be
run to configure the keyboard, display, and mouse and will display something similar to the
following:
Proposed Window System Configuration For Installation:
Video Device: NVidia Corporation GeForce FX Go5200 32M/64M

Video Driver: XF86-NV
Resolution/Colors: 1024x768 - 256 colors @ 70Hz
Screen Size: 17-inch (43cm)
Monitor Type: MultiFrequency 56kHz (up to 1280x1024 interlaced)
Keyboard Type: Generic US-English
Pointing Device: Generic Mouse (3 Button)
Press <ENTER> to accept proposed configuration

or <ESC> to change proposed configuration
or <SPACE> to pause
<<< timeout in 30 seconds >>>
It's fairly safe to just use the defaults that kdmconfig comes up with. However, you may want
to select a higher resolution or color depth. To change the default configuration, hit ESC, then
use the menus to configure the display. If the default is acceptable, just hit ENTER or wait 30
seconds.

20.2 Remote access
It's also possible to bring the GUI up remotely over the network without having to configure
the console device. This is useful if the system booted on SUE++ does not have a graphical
head (like most systems that exist in datacenters). To do this, first networking must be
configured on the SUE++ booted host. Then point a web browser running on another
machine on the network to the IP address of the SUE++ booted host. You can also use the
host name if the appropriate name services are configured on the network to handle resolving
the name to an IP address.
When you point your web browser to the SUE++ booted host, the following screen should be
displayed:
Clicking on any of the Run buttons will start a Java VNC client using the specified resolution.
You can also download the binary for you operating system by clicking the here link. The
page attempts to automatically detect the OS that the browser is running and offer the
appropriate binary. Use the value in the VNC server option column to connect with the
binary vncviewer.
20.3 Logging in
Regardless of whether running from the console or remotely, a login screen will be displayed.
Log in to the SUE++ booted host using root as the login and the password given during the
boot process.

20.4 Main tab
Once logged in, the Main tab will be displayed:
The menu items are described in the following table:
Menu item Function

Invoke <shell> Starts the selected shell in an xterm window
SunVTS Starts all the components necessary to run SunVTS 7 in the Java
Webconsole, then opens a browser screen.
Sun System Handbook Opens the browser up to the resident copy of the Sun System
Handbook
Shared Shell Opens a browser window to the shared shell web site. This is
contingent on networking being configured and having the ability to
actually talk to the shared shell web site.
Run SUE text menu Brings up the conventional SUE text menu in an xterm window.
20.4.1 Sun System Handbook
As mentioned above, there is a copy of the Sun System Handbook resident on SUE++. It will
be necessary to click through the license agreement to access it. This copy of the SSH is the
CD/DVD image that can be downloaded from the SSH web site. It does not contain all the
documentation that the web site does.

20.4.2 Shared Shell
This is not really anything resident on SUE++ other than a link that points to the shared shell
web site. If networking was configured, then a shared shell session can be opened on the
SUE++ booted host.
20.5 Firmware tab

The firmware tab lists the possible firmware upgrades that can be performed on the system.
The initial appearance of this tab for SPARC is:
The x86 version of this screen only contains firmware upgrades for disks and fibre channel
host bus adapters.
To perform a firmware upgrade, click the Check for upgrades button. This will run the
equivalent of the Auto firmware check from the text firmware menu. Once it's done, the
Upgrade available ? column will signify whether there's a firmware upgrade available on
SUE for that particular piece of hardware. If so, then a link will be presented in the Hardware
column. Clicking on the link will perform the firmware upgrade. Documentation on the various
firmware upgrades listed here can be found throughout this manual or by clicking on the Help
button next to the firmware type.

20.6 Start/Stop tab
The Start/Stop tab is for activating or deactivating configurations of software. The list of
software is displayed on the screen:
For Veritas VM and Solaris VM, the Storage Manager tab provides a toggle for turning on and
off support for the given volume manager. For ZFS, it will import everything it finds as
alternate root pools. For LDOMS, the control domain functionality can be turned on and off on
a sun4v system.
See section 8 for more information on VxVM, section 9 for Solaris Volume Manager, section
10 for ZFS, and section 19 for LDOMS.
20.7 ECC Utilities tab (SPARC only)
This tab contains all the utilities in section 13. It is absent from the x86 version.

20.8 System Control tab
The System Control tab has options for shutting down and rebooting the system. It also has a
toggle button for setting and clearing the dump device.
20.9 System info tab

This tab contains some basic information about the booted system. The information
contained here is still a work in progress and may change in the future.

Appendix A - Troubleshooting
Message Context Meaning
*** WARNING: This system is affected by startsue One of the DVD-ROM drives on the system
SunAlert 102139 booting SUE is affected by this SunAlert and
should have it's firmware upgraded ASAP. The
the SunAlert 102139 section under Boot
Process
Applying mdb patch to fix memory vts-hack The vts-hack script, which runs at boot time, has
alignment for VTS pmemtest. See bug determined that the kernel memory list is not
6333683 for details. aligned on a page boundary and has corrected it.
Can't open firmware database upgrade_dfw /usr/sue/firmware/disk/diskfwdb is missing or can
not be accessed for reading.
Cannot unload module: zfs zfsctl Most likely, an attempt was made to deactivate
Will be unloaded upon reboot. ZFS while there were still ZFS volumes mounted.
Forcing update of zfs.conf. Run zfsctl start, unmount the ZFS filesystems
using zfs unmount -a, then run zfsctl stop
Dump device cleared successfully cleardump Dump device was cleared successfully from
being set via setdump
Error accessing /dev/rdsk upgrade_dfw In working around bug 5064915, the script was
unable to scan the contents of the
/dev/rdsk directory.
Error: Could not find CDROM device to sue-init Something went wrong with the CD/DVD
mount /usr from. detection process at boot time. SUE will be
unable to mount the /usr filesystem.
Error: Default route is not local to any mancfg The given address for a default router isn't valid
interface because it is not on a local network with any of
the configured interfaces on the system.
Error: DHCP failed on interface X sue-init SUE failed to up the primary interface via DHCP.
This really shouldn't happen as the miniroot was
already loaded via DHCP.
Error: dump device not cleared cleardump There was a problem clearing the dump device.
Since clearing the dump device involves deleting
the swap partition, it's possible that there is not
enough physical memory on the system to
remove the swap partition.
Error: install_media not defined in GRUB sue-init There is no -B install_media=<NFS mount> in
configuration. menu.lst
Error: Mount of /media failed. sue-init The SUE boot process was unable to mount
/media from either NFS or the CD/DVD. This in
turn means that it is unable to mount the
/usr filesystem contained within /media. This
really should never happen for a CD/DVD. If it
happens with net booting, check the -B
install_media parameter in the menu.lst file
(usually in /tftpboot/boot/grub on the server). The
directory listed should be shared as ro,anon=0
Importing license from host...failed. vxvm The vxvm script attempted to import the Veritas
Volume Manager license from the host, but was
unsuccessful. A license key will have to be
entered manually.

Invalid address for DNS server xxxx mancfg The address given for a default route isn't a valid
IPv4 address (x.x.x.x)
Invalid default route mancfg The given default route is invalid either because
the address itself is invalid, or the address given
isn't on a local network.
Invalid hostname. mancfg The program was unable to set the hostname to
the given string
Invalid IP address mancfg The IP address given is not a valid IPv4 address
(x.x.x.x)
Invalid platform <platform> upgrade_dbp Attempt was made to upgrade the disk backplane
Program terminated. firmware on a system other than an 880 or 890
Invalid platform for LOM upgrade. upgrade_lom The system booted with SUE either has no LOM
or it has a 1st generation LOM. Either way,
upgrade_lom can't perform an upgrade.
Invalid subnet mask mancfg The given subnet mask is not a valid IPv4 mask
(x.x.x.x)
Killing vxconfigd...failed. vxvm vxvstop failed to kill vxconfigd
No installable firmware patches found. upgrade_dfw No disk firmware patches were found for any
disks on the current system.
No relevant HBA firmware patches found upgrade_hba Either there are no fibre channel HBAs on the
for this system system, or there were no firmware patches found
pertaining to the installed FC-HBA cards.
No root device was found at boot time. upgrade_rsc The file /tmp/.rootdev never got created by
Unable to check version of RSC software getroot at boot time. Therefore the upgrade_rsc
on host. script is unable to check the root filesystem on
the host to find out what version of RSC software
is installed on it.
No upgrades available. upgrade_dbp Patch version of the 880/890 disk backplane
firmware is the same as the version loaded.
No upgrades available. upgrade_dfw Disk firmware patches were found for the disks
on the current system, but according to the disk
firmware database (diskfwdb), they are all up
date.
Notice: Default route of x.x.x.x already mancfg A default route was given, but there is already a
present in routing table default route defined. This is valid, but it may not
be desired.
Notice: The RSC software is not installed upgrade_rsc RSC software was never installed on the root disk
on this host. of the host. This essentially tells upgrade_rsc that
it can install any version of firmware on the RSC
card.
Password not valid passwd An attempt was made to set the password to
nothing.
Passwords don't match. try again. passwd In trying to set the root password, the first and
second entries typed in as the password don't
match.
RARP/bootparams not supported on x86 sue-init An attempt was made to boot x86 SUE via
SUE. Please use DHCP. RARP/bootparams. This is unsupported. Use
DHCP instead.

Retrieving metadb info...failed. svm The svm script was unsuccessful in importing the
Unable to import metadb configuration. File mddb.cf file from the real root filesystem on the
is empty. host because the file was either invalid or had no
configuration data in it.
Retrieving metadb info...failed. svm The svm script was unable to retrieve the mddb.cf
Unable to parse mddb.cf from root file from the real root filesystem because it was
filesystem unable to mount the real root filesystem.
Running vxdctl enable...failed. vxvm Veritas Volume Manager failed to read the
system's disk configuration. This may be due to
an invalid license or that Volume Manager isn't
installed on the host.
Running vxdctl enable...ok. (Read-only vxvm No valid license key was entered, therefore the
mode) Veritas Volume Manager configuration can only
be viewed.
Running vxdctl init...failed. vxvm vxdctl init was run as a result of running vxvm
start, and it failed at creating the volboot file.
Running vxdctl initdmp...failed. vxvm vxdctl initdmp was unable to initialize Veritas
Volume Manager Dynamic MultiPathing
Started vxconfigd in disable mode...failed. vxvm vxconfigd -m disable failed to come up. It's
possible that it's already running.
StorEdge 3310 found. Configuring extra startsue A StorEdge 3310 (SCSI Minnow) was found.
luns in sd driver... Extra luns will be generated in the sd driver via
update_drv -f
SVM already started. svm An attempt was made to bring up the Solaris
Volume Manager configuration via svm start
when the configuration was already active.
SVM not running. svm An attempt was made to stop the SVM
configuration when it wasn't active.
There are no updates for platform upgrade_obp An OBP/flash firmware patch for this system does
<platform> on this CD. not exist on the SUE.
Unable to import metadb configuration. File svm /etc/lvm/mddb.cf on the system root disk didn't
is empty. contain any information. Since this file contains
the location(s) of the metadb, Solaris Volume
Manager can't be started.
Unable to mount /var from host to check upgrade_rsc upgrade_rsc found a /tmp/.vardev, which
RSC software version. indicates that the normal root device of the SUE
booted host has /var as a separate filesystem.
However, it was unable to mount it. /var is needed
because upgrade_rsc needs to run pkginfo to
check the RSC software version, and /var/sadm
is where all the package information is.
Unable to mount root device to check RSC upgrade_rsc upgrade_rsc was able to find a
software version on host. /tmp/.rootdev file, but was unable to mount the
device as a UFS. It's possible that it's already
mounted somewhere.
Unable to parse mddb.cf from root svm The mddb.cf file from the root filesystem could
filesystem not be located.
Unable to run find upgrade_dfw The script was unable to run the find command to
locate data within a disk firmware patch.
Unknown processor type <proc type> getroot The results of uname -p came up with something
other than sparc or i386

Unloading SVM modules...failed svm An svm stop failed to shut down the md
Failed ioctl: Device busy configuration while a metadevice was busy. Most
likely, a metadevice is still mounted.
Unloading vxX module...failed. vxvm The Veritas Volume Manager modules failed to
Are all vxvm filesystems unmounted ? unload because something is still using them,
such as a mounted filesystem.
VxVM already started. vxvm An attempt was made to bring up the Veritas
Volume Manager configuration via vxvm start
when the configuration was already active.
VxVM not running. vxvm An attempt was made to stop the Veritas Volume
Manager configuration when it wasn't active.
Warning: bogus devalias <devalias> in getroot A device alias was found in boot-device in OBP
boot-device that doesn't map to a real device path
Warning: Changing the IP address of an mancfg The IP address of an interface that is already up
active interface is being changed
Warning: Insufficient memory to start startsue The system booting the SUE has a graphical
window system. head, but not enough memory to run X windows.
Warning: No valid root disk found getroot A valid root disk was not found in the OBP boot-
device list
Warning: Root filesystem could not be upgrade_hba In an attempt to run showrev -p against the root
mounted from boot disk. No dependency filesystem on the system's root disk, it was unable
checking done. to mount (read-only) the root filesystem.
Warning: Root filesystem from device getroot The getroot determines if /var is a separate
pointed to by OBP boot-device is filesystem on the boot disk by mounted the root
unmountable. Unable to determine if /var is filesystem read only and looking at vfstab. In this
a separate filesystem. process it had identified what the root filesystem
was, but it was unable to mount it.
Warning! there's a filesystem on the getroot After checking the disk label and finding a
partition listed below even though is has a partition that has a tag of swap and flags of wu,
swap partition tag. Cowardly refusing to use fstyp reports that there is a filesystem on this
it as a dump device. partition. This may happen on a newly installed
root disk with a webstart installation where the
initial miniroot is installed on (what will be) the
swap partition. This check is the last check
performed to see if a partition can be used as a
dump device.
Warning! This system is not listed as a type checkvts As of SunVTS 6.2 on x86, SunVTS uses the
that is supported in SunVTS. smbios command to check the type of system it's
Use at your own risk. running on and will refuse to run unless an entry
is made for that system in
/opt/SUNWvts/lib/conf/platform.conf. The
checkvts wrapper script will put and entry in
platform.conf if necessary to allow sunvts to run.
However, when it does this, this warning
message will print out.
You don't have enough memory on this startsue The system doesn't have enough memory to
machine to load the /opt directory. destage /opt. Refer to Destaging /opt in the
Boot Process section.

Appendix B – Image contents
Tables 3 and 4 show the software added to the standard Solaris net root filesystem to make
the Solaris Utility Environment
Table 3 – Add-on packages installed on the SUE
Software Package name(s) Architecture
ALOM 1.6.10 firmware N/A SPARC
bash – born again shell SUNWbash SPARC/x86
Fault Management daemon SUNWfmd SPARC/x86
FRUID SUNWfruid, SUNWfruip, SUNWfruix SPARC
ftpd SUNWftpr, SUNWftpu SPARC/x86
gzip SUNWgzip SPARC/x86
Patches from EIS 28SEP10 N/A SPARC/x86
picld SUNWpiclr, SUNWpiclu SPARC
RSC 2.2.3 (1.14 for E250) SUNWrsc SPARC
sccli (Minnow) 2.5.1 N/A - sccli binary only from SUNWsccs SPARC/x86
Solaris 10U8 - KUP 142909-17 N/A SPARC
Solaris 10U8 - KUP 142910-17 N/A x86
SNEEP 2.9 SUNWsneep SPARC
Sun VTS 7.0ps9 SUNWvts, SUNWvtsr, SUNWvtstr SPARC/x86
Solaris CAT 5.3Beta SUNWscat SPARC*/x86
Veritas Volume Manager 5.1 RP2 VRTSvlic, VRTSvmman, VRTSvxvm SPARC/x86
* Solaris CAT for SPARC is on SUE++ only

Table 4 – Homegrown programs on the Solaris Utility Environment (most reside
in /usr/sue/bin)
Program Function Architecture
cleardump Clears the system dump device SPARC/x86
diskinfo Binary taken from explorer to display SCSI inquiry data SPARC/x86
execsh Shell script to execute a shell as a login shell SPARC/x86
firmware_check Runs all the upgrade_* scripts with the -n option. The -n option tells SPARC
the upgrade scripts to just report on the upgradeability of that
component and not perform the actual upgrade.
getroot Perl script to derive the Solaris device path from the value(s) of SPARC/x86
boot-device in OBP
mancfg Perl script to perform manual network configuration SPARC/x86
md5sum GNU program for generating MD5 checksums on files SPARC/x86
mdstop C program to perform the correct ioctl to shut down Solaris Volume SPARC/x86
Manager so that it's possible to uload the SVM drivers.
passwd Perl script replacement for the Solaris passwd binary. A necessary SPARC/x86
replacement because the Solaris passwd command needs to create
temporary files in /etc, which is read-only when SUE is booted.
run_findaft Runs findaft against the log files on the OS disk of the host SPARC
run_findfma Runs findfma against the log files on the OS disk of the host SPARC
run_findUE Runs findUE against the log files on the OS disk of the host SPARC
runpause Wrapper script that runs a program then waits for a response. SPARC
screen Open source C program to multiplex a single terminal window SPARC/x86
setdump Shell script to parse for setting the system dump device. SPARC/x86
setup_boot_server Similar to setup_install_server and can be run in it's place as it's SPARC/x86
essentially a wrapper for it. However, setup_boot_server can be
used to extract either the SPARC or x86 boot image from the dual
boot DVD regardless of what platform it's being run on.
setup_flash_drive Install the SUE image on a USB flash drive so that the flash drive x86
can be booted.
startsue Startup script for the SUE. Replaces SPARC/x86
/sbin/startup from the standard Solaris net root filesystem.
sue-init For x86, sue-init finds and mounts the /usr filesystem and displays SPARC/x86
the banner. For SPARC, it just displays the banner.
sue-menu Menu program for text console SPARC/x86
svm Shell script to activate/deactivate a Solaris Volume Manager SPARC/x86
configuration.
syscfg-sue System configuration startup script for SUE. Replaces SPARC/x86
/sbin/sysconfig
upgrade_alom Shell script to upgrade the ALOM firmware on the system controller SPARC
of a v210, v240, v250, v440, Netra 240, or Netra 440
upgrade_dbp Shell script to upgrade the disk backplane firmware on a v880/890 SPARC
upgrade_dfw Perl script that compares a disk firmware database created at build SPARC
time to the current disks on a host and upgrade (if desired).

Program Function Architecture
upgrade_hba Perl script that compares an HBA firmware database created at build SPARC
time with the current FC HBAs found on the system, and prompts to
upgrade
upgrade_jasper Perl script to upgrade the FCODE on the Jasper 320 card SPARC
upgrade_lom Shell script to upgrade the LOM firmware and update the LOM SPARC
EEPROM configurations for systems with second generation LOM
chips.
upgrade_lw8 Shell script to upgrade the system controller firmware on a SPARC
Lightweight 8 system via the lom interface
upgrade_lsi Script to upgrade firmware and FCODE on various systems with SPARC
onboard LSI controllers.
upgrade_obp Shell script to perform OBP/POST firmware upgrades SPARC
upgrade_rsc Shell script to upgrade RSC firmware. SPARC
upgrade_sun4v Upgrade the system firmware on a T1000, T2000, Netra T2000, SPARC
SunBlade T6300, T5120, or T5220, and other sun4v systems
vxvm Shell script to activate/deactivate a Veritas Volume Manager SPARC
configuration.
zfsimport Activates a ZFS configuration from a system. Imports the pools as SPARC/x86
alternate root pools. See zpool(1m). Pools imported with this
command should not be exported as this will change the state of the
pools. See section 10.

Sue Userguide 3.32

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Sue Userguide 3.32

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sue Userguide 3.32

Uploaded by

Copyright:

Available Formats

Solaris Utility Environment (SUE)

Version 3.32 User's Guide

Oracle Proprietary – Internal and Authorized Partner use only

Oracle Proprietary – Internal and Authorized Partner use only 2

Oracle Proprietary – Internal and Authorized Partner use only 3

Oracle Proprietary – Internal and Authorized Partner use only 4

• Allows diagnosis and troubleshooting to be performed without the variable of the

Oracle Proprietary – Internal and Authorized Partner use only 5

Oracle Proprietary – Internal and Authorized Partner use only 6

Name Media type GUI interface ? Platform(s)

3.2 SUE dual boot DVD

See section 20 for more information on the GUI interface.

Oracle Proprietary – Internal and Authorized Partner use only 7

Table 1- boot options

boot <device> - <boot option>

Oracle Proprietary – Internal and Authorized Partner use only 8

4.4 Booting SUE entirely in memory

Oracle Proprietary – Internal and Authorized Partner use only 9

4.5 System Configuration

1 Auto system configuration

Oracle Proprietary – Internal and Authorized Partner use only 10

** Manual network configuration starting **

RARP boot interface is eri0

Searching for network interfaces: [eri0] [ge0] done

Process interface eri0 ([y]/n/q) ? y

Is this correct ([y]/n/q) ?

Oracle Proprietary – Internal and Authorized Partner use only 11

Information entered for eri0:

Is this correct ([y]/n/q) ?

Oracle Proprietary – Internal and Authorized Partner use only 12

4.8 SunAlert 102139

4.9 Setting the dump device

Oracle Proprietary – Internal and Authorized Partner use only 13

Oracle Proprietary – Internal and Authorized Partner use only 14

1) Invoke /bin/sh 10) Stop Veritas Volume Manager

Screen is a full-screen window manager that multiplexes a physical

Control-a c - Create new screen

Oracle Proprietary – Internal and Authorized Partner use only 15

For a complete list of commands, type Control-a ?

Main menu items are described in the table below.

Menu item Function

Oracle Proprietary – Internal and Authorized Partner use only 16

5.2 Firmware menu (SPARC)

1) Disk 8) LSI controllers

Menu Item Function

Oracle Proprietary – Internal and Authorized Partner use only 17

Oracle Proprietary – Internal and Authorized Partner use only 18

The x86 version of SUE has the following firmware menu:

Oracle Proprietary – Internal and Authorized Partner use only 19

Control-r moves the cursor to the right.

Oracle Proprietary – Internal and Authorized Partner use only 20

7.1 Disk Firmware

• Patch number + revision

Patch Vendor Disk model Patch FW Disk FW # of drives

Would you like to perform firmware upgrades [y/[n]/(s)how detail] ?

Would you like to perform firmware upgrades [y/[n]/(s)how detail] ?

Oracle Proprietary – Internal and Authorized Partner use only 21

Manual network configuration starting