sue-userguide-3.32

Solaris Utility Environment (SUE) Version 3.32 User's Guide

John CecereDana FagerstromSun ServicesNovember 12, 2010

Oracle Proprietary – Internal and Authorized Partner use only

Table of Contents

1 � Solaris Utility Environment vs. Diagnostic Boot CD............................................................42 � Overview............................................................................................................................. 53 � SUE release types.............................................................................................................. 7

3.1 SUE CD.......................................................................................................................... 73.2 SUE dual boot DVD........................................................................................................73.3 SUE++............................................................................................................................ 7

4 � Boot process....................................................................................................................... 84.1 Boot options....................................................................................................................84.2 SPARC............................................................................................................................84.3 x86/x64........................................................................................................................... 84.4 Booting SUE entirely in memory.................................................................................... 94.5 System Configuration................................................................................................... 104.6 getroot.......................................................................................................................... 124.7 SNEEP (SPARC only).................................................................................................. 134.8 SunAlert 102139...........................................................................................................134.9 Setting the dump device...............................................................................................13

5 � Text menus........................................................................................................................ 155.1 Main menu....................................................................................................................155.2 Firmware menu (SPARC).............................................................................................175.3 Firmware menu (x86)................................................................................................... 19

6 � SunVTS............................................................................................................................. 207 � Firmware........................................................................................................................... 21

7.1 Disk Firmware...............................................................................................................217.1.1SunAlert 103174...................................................................................................... 22

7.2 Upgrading OBP/POST................................................................................................. 247.3 Fibre Channel HBA firmware........................................................................................26

7.3.1Dependencies.......................................................................................................... 277.3.2Fin 1081 and the JNI SEEPROM.............................................................................27

7.4 V880/890 disk backplane............................................................................................. 287.5 ALOM Firmware............................................................................................................297.6 RSC firmware............................................................................................................... 317.7 v1280/2900/Netra 1280................................................................................................317.8 LSI controller firmware................................................................................................. 327.9 Jasper 320 LVD SCSI controller...................................................................................327.10 sun4v system firmware...............................................................................................327.11 Adaptec SAS RAID controller (Cougar/Prometheus)................................................. 367.12 Serengeti firmware..................................................................................................... 367.13 Auto Firmware Check................................................................................................. 37

8 � Veritas Volume Manager...................................................................................................389 � Solaris Volume Manager...................................................................................................4110 � ZFS..................................................................................................................................4211 � Creating a Network Boot Image...................................................................................... 44

11.1 Setting up a boot server............................................................................................. 4411.2 Dual boot DVD............................................................................................................4511.3 Hands-off booting....................................................................................................... 4611.4 WAN booting (SPARC only)....................................................................................... 48

12 � USB Flash Drive booting (x86 only)................................................................................5012.1 Creating a bootable SUE flash drive.......................................................................... 5012.2 Booting the flash drive................................................................................................51

Oracle Proprietary – Internal and Authorized Partner use only 2

13 � ECC Utilities for SPARC (cediag, findaft, fin954)............................................................5213.1 findaft..........................................................................................................................5213.2 findUE.........................................................................................................................5213.3 findfma........................................................................................................................5213.4 ECC errors and /etc/system....................................................................................... 53

14 � Device path decoder....................................................................................................... 5415 � devfsadm.........................................................................................................................5516 � DtraceToolkit................................................................................................................... 5617 � scrubber.......................................................................................................................... 5818 � Online documentation..................................................................................................... 5919 � LDOMS (SPARC only).................................................................................................... 6020 � SUE++ Interface..............................................................................................................61

20.1 X configuration............................................................................................................6120.2 Remote access...........................................................................................................6220.3 Logging in................................................................................................................... 6220.4 Main tab......................................................................................................................63

20.4.1 Sun System Handbook......................................................................................... 6320.4.2 Shared Shell..........................................................................................................64

20.5 Firmware tab...............................................................................................................6420.6 Start/Stop tab..............................................................................................................6520.7 ECC Utilities tab (SPARC only)..................................................................................6520.8 System Control tab.....................................................................................................6620.9 System info tab...........................................................................................................66

Appendix A - Troubleshooting...................................................................................................67Appendix 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 optionsOption Platform Description

autocfg All

Causes SUE to perform an auto configuration during the boot process. This auto configuration is the same one performed when booting the 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.

mancfg All

Causes SUE to run the manual system configuration program during the boot process. This is a perl script that prompts for name, IP address, and subnet mask for each interface, as well as default route and DNS information.

nocfg AllCauses SUE to boot without performing a system and network configuration. This boot option will still prompt for a terminal type and hostname.

install All

Synonym for autocfg with the addition of attempting to take default answers for any of the SUE specific boot questions. This is here to allow for a hands off SUE boot using the traditional jumpstart methods. See section 11.3 for details.

-F obp_archive -D /flash/<platform name> SPARC

Boot the OBP/flash image for <platform name>. This is for performing OBP/flash upgrades. The platform name must be the same name returned via uname -i on the host being booted. See the section on Upgrading OBP/POST for supported platforms for this function.

fsinmem x86 Tell SUE to attempt booting the entire image in memory. If this isn't 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 configuration2 Manual system configuration3 No system configurationh 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) ? yName: sselab1IP address: 129.154.57.125Subnet 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: sselab1IP address: 129.154.57.125Subnet 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 AppendixB). 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 whilebooted 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 offthis 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 thecomponents of the device listed (hba, disk, fc backplane, etc.), answer this question 'no' to avoid 'must be sole user' or 'busy' errors duringthe firmware upgrade process. If you set the dump device and then decidelater 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 menuAfter the system is done with the boot process, it will present a menu like this:

*******************************************************************************Solaris Utility Environment version 3.32SunOS sselab1 5.10 Generic_142909-17 sun4u sparc SUNW,Sun-Fire-880Patched with EIS 28SEP10 System serial number: 0343AM02B8********************************** Main Menu **********************************

1) Invoke /bin/sh 10) Stop Veritas Volume Manager2) Invoke /bin/ksh 11) Start Solaris Volume Manager3) Invoke /bin/csh 12) Stop Solaris Volume Manager4) Invoke /bin/bash 13) Import ZFS pools5) SunVTS 14) Run findaft on root disk6) Firmware menu 15) Run findUE on root disk7) Set dump device 16) Run findfma8) Clear dump device 17) Start LDOMS9) Start Veritas Volume Manager 18) Stop LDOMS

-------------------------------------------------------------------------------h) Halt system r) Reboot system d) Disable menu s) Help on GNU screenu) 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 fromthe 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 onewindow. Screen uses a control character to access its command set. Thecontrol character is currently set to the default, Control-a (Control key andthe 'a' key simultaneously. After hitting Control-a, you then type in a secondcharacter (after releasing Control-a) which represents the command. Somecommon 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 Function1) 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 configuration on a system.

11) Start Solaris Volume Manager Runs svm start. Enables access to the Solaris Volume Manager configuration on a system.

12) Stop Solaris Volume Manager Runs svm stop. Disables access to the Solaris Volume Manager configuration on a system.

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:

*******************************************************************************Solaris Utility Environment version 3.32SunOS sselab1 5.10 Generic_142909-17 sun4u sparc SUNW,Sun-Fire-880Patched with EIS 28SEP10 System serial number: 0343AM02B8******************************** Firmware Menu ********************************

1) Disk 8) LSI controllers2) OBP/flash 9) Jasper 320 LVD SCSI controller3) Fibre Channel HBA 10) sun4v system firmware4) 880/890 disk backplane 11) Adaptec SAS controller5) ALOM 12) Auto firmware check6) RSC 13) Main menu7) 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 Function1) 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 Function5) 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:

*******************************************************************************Solaris Utility Environment version 3.32SunOS sselab7 5.10 Generic_142910-17 i86pc i386 i86pcPatched with EIS 28SEP10 ******************************** Firmware Menu ********************************

1) Disk2) Fibre Channel HBA3) Adaptec SAS controller4) Auto firmware check5) 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 Noc1t1d0s2 109962-14 SEAGATE ST373405F 0638 0638 Noc1t2d0s2 116464-02 HITACHI DK32EJ72F 2Q0J 2Q0F Yesc1t3d0s2 116464-02 HITACHI DK32EJ72F 2Q0J 2Q0F Yesc1t4d0s2 116464-02 HITACHI DK32EJ72F 2Q0J 2Q0F Yesc1t5d0s2 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 ofthe firmware upgrade:

<disks listed here>

Because there is a Solaris Volume Manager configuration on this system, it isnow 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 ofthe Solaris Volume Manager configuration comes up missing, boot SUE back upand run fixsvm from the command line. The alternative is to follow theprocedure described in the SunAlert, which will require you to first downgradethe 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-280R, SUNW,Netra-T4

Sun Blade 1000, Sun Fire 280R, Netra T4, Netra T20, Sun Blade 2000

119232 SUNW,Sun-Blade-2500, SUNW,Sun-Fire-V250

Sun Blade 2500, Sun Fire 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-V240, SUNW,Netra-240

Sun Fire v210, Sun Fire v240, Netra 240

121685 SUNW,Sun-Fire-V440, SUNW,Netra-440 Sun Fire v440, Netra 440

121688 SUNW,Sun-Fire-880, SUNW,Sun-Fire-V890

Sun Fire v880, Sun Fire 890

121689 SUNW,Sun-Fire-480R, SUNW,Sun-Fire-V490

Sun Fire v480, Sun Fire v490

121690 SUNW,Sun-Fire-V445 Sun Fire v445

121691 SUNW,Sun-Fire-V1251 Sun Fire v125

121692 SUNW,Sun-Fire-V215, SUNW, Sun-Fire-V245

Sun Fire v215, Sun Fire 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-02Platform: SUNW,Sun-Fire-880Patch version: 4.18.8System version: 4.18.6Upgrade 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 willend up booting off the device defined as boot-device (most likely the bootdisk) when it's done updating OBP.

Would you like to set auto-boot? to false to prevent this from happeningand 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.9Dependencies 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 Dependencies114874-02 113043-06

The dependencies listed are patches that contain drivers and software thatcorrespond to the listed firmware patch(es). It is recommended to installthese 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 thefcode 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 effectWould 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 = 9229Patch firmware version = 922A

About to perform v880/890 disk backplane firmware upgrade. Pleasenote that the firmware upgrade may not actually take effect untilup to 15 minutes after this procedure is complete. Please monitorthe 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 doneresetting itself.

Do NOT reboot or reset this system until the firmware version haschanged to the desired version. If you do, the upgrade will notcomplete.

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 Platformv125 SUNW,Sun-Fire-V210

v210 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.zType 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 hereis 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 PlatformE250 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.zType 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 hereis 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 the1280, 2900, or Netra 1280.


The process of upgrading the firmware will generate a number of messagesrelating to the need to reset various components of this system. Please donot reset anything until this script is finished. This will be evident fromthe message "upgrade_lw8 script complete". At that point, only a reset inOBP 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 typeT1000 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=alomCreating 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-06System 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 theexecution of this program. It will download the firmware to the systemcontroller. The second part of the upgrade requires that the host be poweredoff and the 'flashupdate' command be issued from the sc> prompt. Please makesure 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-06System 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 thesystem controller. In addition, an account must be set up in ILOM with it'scli_mode set to alom and role set to Administrator. This can be accomplishedwith 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.144Enter login: adminEnter 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 completethe upgrade process. Once you are logged in, perform the followingprocedure:

Power off the host:sc> poweroffWait for the host to power down. The following message should be displayedwhen 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: cougarController fw version: 15825Available 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 firmwareon 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 disable2. vxdctl init3. vxdctl initdmp4. 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-bitCopyright 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 openINIT: Cannot create /var/adm/utmpxINIT: failed write of utmpx entry:" "INIT: failed write of utmpx entry:" "INIT: SINGLE USER MODEType 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 vxioApr 18 15:05:17 seagirt vxdmp: NOTICE: VxVM vxdmp V-5-0-34 added disk array DISKS, datype = DiskStarted 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• rebootResolving 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...doneSVM successfully started

The Solaris Volume Manager configuration has beenstarted. If you need to effect any changes on existingmetadevices, you may need to execute 'metasync -r' beforedoing so to set the state of these devices to 'Ok'. Beaware that executing metasync -r will cause any unsynchedmirrors 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.confSVM 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 systemand attempt to import them as read-only Alternate Root Pools. Assuch, the ZFS configuration will not be altered in any way. Allfilesystems 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 ONLINEpool2 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 typeSystem type

DVD lofi mounted ISO image

SPARC slice 0 - SPARCslice 1 - x86

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=4jnQ29DK0cAtQsystem_locale=Ctimeserver=localhosttimezone=US/Easternterminal=vt100security_policy=NONEnfs4_domain=dynamicnetwork_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_wanbootUsing server IP address of 10.143.2.81Starting Apache web serverApache web server started successfullyCreating wanboot directory structure in /var/apache2/htdocs/suewbdRunning setup_install_serverVerifying target directory...Calculating the required disk space for the Solaris_10 productCalculating space required for the installation boot imageCopying 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/minirootWAN 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 completeCopying wanboot binaries

Wanboot server is set up for SUE. The default platform configured is sun4u. Ifyou need to set up for a different platform (i.e. sun4v or sun4us), modify thefile /etc/netboot/wanboot.conf and point boot_file to the correct image. Theadd_install_client script must be run for each system that will be booted withSUE.

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 SUEdocumentation 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 = 3316MBCreating 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=1set ce_verbose_memory=2set 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:fcPossible machines:0. Sun Fire V8801. Sun Fire V880z2. Sun Fire V8903. Sun Fire V4804. Sun Fire V490Selection [default: V880]: 0Sun Fire V880System 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 systemdevfsadm: 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/DTraceToolkitBin/ 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:

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

-dProvide 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 configurationor <ESC> to change proposed configurationor <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 FunctionInvoke <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 SunAlert 102139

startsue One of the DVD-ROM drives on the system 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 alignment for VTS pmemtest. See bug 6333683 for details.

vts-hack The vts-hack script, which runs at boot time, has determined that the kernel memory list is not 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: zfsWill be unloaded upon reboot.Forcing update of zfs.conf.

zfsctl Most likely, an attempt was made to deactivate ZFS while there were still ZFS volumes mounted. 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 mount /usr from.

sue-init Something went wrong with the CD/DVD detection process at boot time. SUE will be unable to mount the /usr filesystem.

Error: Default route is not local to any interface

mancfg The given address for a default router isn't valid 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 configuration.

sue-init There is no -B install_media=<NFS mount> in 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.


Message Context MeaningInvalid 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>Program terminated.

upgrade_dbp Attempt was made to upgrade the disk backplane 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 for this system

upgrade_hba Either there are no fibre channel HBAs on the system, or there were no firmware patches found pertaining to the installed FC-HBA cards.

No root device was found at boot time. Unable to check version of RSC software on host.

upgrade_rsc The file /tmp/.rootdev never got created by getroot at boot time. Therefore the upgrade_rsc 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 present in routing table

mancfg A default route was given, but there is already a default route defined. This is valid, but it may not be desired.

Notice: The RSC software is not installed on this host.

upgrade_rsc RSC software was never installed on the root disk 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. Please use DHCP.

sue-init An attempt was made to boot x86 SUE via RARP/bootparams. This is unsupported. Use DHCP instead.


Message Context MeaningRetrieving metadb info...failed.Unable to import metadb configuration. File is empty.

svm The svm script was unsuccessful in importing the mddb.cf file from the real root filesystem on the host because the file was either invalid or had no configuration data in it.

Retrieving metadb info...failed.Unable to parse mddb.cf from root filesystem

svm The svm script was unable to retrieve the mddb.cf file from the real root filesystem because it was 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 mode)

vxvm No valid license key was entered, therefore the 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 luns in sd driver...

startsue A StorEdge 3310 (SCSI Minnow) was found. 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 <platform> on this CD.

upgrade_obp An OBP/flash firmware patch for this system does not exist on the SUE.

Unable to import metadb configuration. File is empty.

svm /etc/lvm/mddb.cf on the system root disk didn't 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 RSC software version.

upgrade_rsc upgrade_rsc found a /tmp/.vardev, which 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 software version on host.

upgrade_rsc upgrade_rsc was able to find a /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 filesystem

svm The mddb.cf file from the root filesystem could 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


Message Context MeaningUnloading SVM modules...failedFailed ioctl: Device busy

svm An svm stop failed to shut down the md configuration while a metadevice was busy. Most likely, a metadevice is still mounted.

Unloading vxX module...failed.Are all vxvm filesystems unmounted ?

vxvm The Veritas Volume Manager modules failed to 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 boot-device

getroot A device alias was found in boot-device in OBP that doesn't map to a real device path

Warning: Changing the IP address of an active interface

mancfg The IP address of an interface that is already up is being changed

Warning: Insufficient memory to start window system.

startsue The system booting the SUE has a graphical 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 mounted from boot disk. No dependency checking done.

upgrade_hba In an attempt to run showrev -p against the root filesystem on the system's root disk, it was unable to mount (read-only) the root filesystem.

Warning: Root filesystem from device pointed to by OBP boot-device is unmountable. Unable to determine if /var is a separate filesystem.

getroot The getroot determines if /var is a separate filesystem on the boot disk by mounted the root filesystem read only and looking at vfstab. In this process it had identified what the root filesystem was, but it was unable to mount it.

Warning! there's a filesystem on the partition listed below even though is has a swap partition tag. Cowardly refusing to use it as a dump device.

getroot After checking the disk label and finding a partition that has a tag of swap and flags of wu, fstyp reports that there is a filesystem on this 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 that is supported in SunVTS.Use at your own risk.

checkvts As of SunVTS 6.2 on x86, SunVTS uses the smbios command to check the type of system it's 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 machine to load the /opt directory.

startsue The system doesn't have enough memory to 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 EnvironmentTable 3 – Add-on packages installed on the SUE

Software Package name(s) ArchitectureALOM 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 Architecturecleardump 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 the upgrade scripts to just report on the upgradeability of that component and not perform the actual upgrade.

SPARC

getroot Perl script to derive the Solaris device path from the value(s) of boot-device in OBP

SPARC/x86

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 Manager so that it's possible to uload the SVM drivers.

SPARC/x86

passwd Perl script replacement for the Solaris passwd binary. A necessary replacement because the Solaris passwd command needs to create temporary files in /etc, which is read-only when SUE is booted.

SPARC/x86

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

SPARC/x86

setup_flash_drive Install the SUE image on a USB flash drive so that the flash drive can be booted.

x86

startsue Startup script for the SUE. Replaces /sbin/startup from the standard Solaris net root filesystem.

SPARC/x86

sue-init For x86, sue-init finds and mounts the /usr filesystem and displays the banner. For SPARC, it just displays the banner.

SPARC/x86

sue-menu Menu program for text console SPARC/x86

svm Shell script to activate/deactivate a Solaris Volume Manager configuration.

SPARC/x86

syscfg-sue System configuration startup script for SUE. Replaces /sbin/sysconfig

SPARC/x86

upgrade_alom Shell script to upgrade the ALOM firmware on the system controller of a v210, v240, v250, v440, Netra 240, or Netra 440

SPARC

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 time to the current disks on a host and upgrade (if desired).

SPARC


Program Function Architectureupgrade_hba Perl script that compares an HBA firmware database created at build

time with the current FC HBAs found on the system, and prompts to upgrade

SPARC

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 EEPROM configurations for systems with second generation LOM chips.

SPARC

upgrade_lw8 Shell script to upgrade the system controller firmware on a Lightweight 8 system via the lom interface

SPARC

upgrade_lsi Script to upgrade firmware and FCODE on various systems with onboard LSI controllers.

SPARC

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, SunBlade T6300, T5120, or T5220, and other sun4v systems

SPARC

vxvm Shell script to activate/deactivate a Veritas Volume Manager configuration.

SPARC

zfsimport Activates a ZFS configuration from a system. Imports the pools as 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.

SPARC/x86


sue-userguide-3.32

Documents