Part II Appendixes

This part contains troubleshooting and reference information.

Appendix A Troubleshooting
(Tasks)

This chapter contains a list of specific error messages and general
problems you might encounter when installing Solaris 10 8/07 software.
The chapter also explains how to fix the problems. Start by using this list
of sections to determine where in the installation process the problem occurred.

When Solaris 10 8/07 software was installed
(either through the Solaris installation program or custom JumpStart), no
boot disk was selected. You now must edit the BIOS to boot the system.

Solution:

Select the BIOS to boot. See your BIOS documentation
for instructions.

Booting From Media, General Problems

The system does not boot.

Description:

When initially setting up a custom JumpStart
server, you might encounter boot problems that do not return an error message.
To verify information about the system and how the system is booting, run
the boot command with the -v option. When you use the -v option,
the boot command displays verbose debugging information about the screen.

Note –

If this flag is not given, the messages are still printed, but
the output is directed to the system log file. For more information, see syslogd(1M).

Solution:

For SPARC based systems, at the ok prompt,
type the following command.

ok boot net -v - install

Boot from DVD media fails on systems
with Toshiba SD-M 1401 DVD-ROM

Description:

If your system has a Toshiba SD-M1401
DVD-ROM with firmware revision 1007, the system cannot boot from the Solaris Operating System DVD.

Solution:

Apply patch 111649–03, or later version,
to update the Toshiba SD-M1401 DVD-ROM drive's firmware. The patch 111649–03
is available at sunsolve.sun.com.

The system hangs or panics when nonmemory
PC cards are inserted. (x86 based systems only)

Cause:

Nonmemory PC cards cannot use the same memory
resources that are used by other devices.

Solution:

To correct this problem, see the instructions
for your PC card and check for the address range.

The system hangs before displaying
the system prompt. (x86 based systems only)

Solution:

You have hardware that is not supported.
Check your hardware manufacturer's documentation.

Booting From the Network, Error Messages

WARNING: getfile: RPC failed: error
5 (RPC Timed out).

Description:

This error occurs when you have two or
more servers on a network responding to an install client's boot request.
The install client connects to the wrong boot server, and the installation
hangs. The following specific reasons might cause this error to occur:

Cause:

Reason 1:/etc/bootparams files might exist on different servers with an entry for this
install client.

Solution:

Reason 1: Ensure that
servers on the network do not have multiple /etc/bootparams entries
for the install client. If they do have multiple entries, remove duplicate
client entries in the /etc/bootparams file on all install
servers and boot servers except the one you want the install client to use.

Reason 2: Ensure that
servers on the network do not have multiple /tftpboot or /rplboot directory entries for the install client. If they do have
multiple entries, remove duplicate client entries from the /tftpboot or /rplboot directories on all install servers and boot servers except
the one you want the install client to use.

Cause:

Reason 3: An install client
entry might exist in the /etc/bootparams file on a server
and an entry in another /etc/bootparams file that enables
all systems to access the profile server. Such an entry resembles the following:

* install_config=profile_server:path

A line that resembles the previous entry in the NIS or NIS+ bootparams table can also cause this error.

Solution:

Reason 3: If a wildcard
entry is in the naming service bootparams map or table
(for example, * install_config=), delete it and add it
to the /etc/bootparams file on the boot server.

No network boot server. Unable to install
the system. See installation instructions. (SPARC based systems
only)

Cause:

This error occurs on a system that you are attempting
to install from the network. The system is not set up correctly.

This error occurs when you are installing Solaris
from a network, but the boot software cannot locate the following:

Solaris Operating System DVD, either the DVD or a copy of the DVD image on
the install server

Solaris Software - 1 CD image, either the Solaris Software - 1 CD
or a copy of the CD image on the install server

Solution:

Ensure that the installation software is
mounted and shared.

If you are installing Solaris from the install server's DVD-ROM
or CD-ROM drive, ensure that the Solaris Operating System DVD or Solaris Software - 1 CD is
inserted in the CD-ROM drive, is mounted, and is shared in the /etc/dfs/dfstab file.

If installing from a copy of the Solaris Operating System DVD image or Solaris Software - 1 CD
image on the install server's disk, ensure that the directory path to the
copy is shared in the /etc/dfs/dfstab file.

Timeout waiting for ARP/RARP packet...(SPARC based systems only)

Cause:

Reason 1: The client is
trying to boot from the network, but it cannot find a system that knows about
the client.

Solution:

Reason 1: Verify the
system's host name is in the NIS or NIS+ naming service. Also, verify the bootparams search order in the boot server's /etc/nsswitch.conf file.

For example, the following line in the /etc/nsswitch.conf file indicates that JumpStart or the Solaris installation program
first looks in the NIS maps for bootparams information.
If the program does not find any information, the installer looks in the boot
server's /etc/bootparams file.

bootparams: nis files

Cause:

Reason 2: The client's
Ethernet address is not correct.

Solution:

Reason 2: Verify that
the client's Ethernet address in the install server's /etc/ethers file
is correct.

Cause:

Reason 3: In a custom JumpStart
installation, the add_install_client command specifies
the platform group that uses a specified server as an install server. If the
wrong architecture value is used when using the add_install_client,
this problem occurs. For example, the machine you want to install is a sun4u,
but you used i86pc instead.

This error message is displayed
when you boot a system with a token ring card. Ethernet multicast and token
ring multicast do not work the same way. The driver returns this error message
because an invalid multicast address was provided to it.

Solution:

Ignore this error message. If multicast does
not work, IP uses layer broadcasts instead and does not cause the installation
to fail.

The client is trying to boot from the network,
but it cannot find a system that knows about the client.

Solution:

Verify the system's host name is listed in
the naming service. If the system's host name is listed in the NIS or NIS+
naming service, and the system continues to print this error message, try
rebooting.

The DHCP server is not configured correctly.
This error might occur if the options or macros are not correctly defined
in the DHCP Manager software.

Solution:

In the DHCP Manager software, verify that
the options and macros are correctly defined. Confirm that the Router option
is defined, and that the value of the Router option is correct for the subnet
you are using for the network installation.

Booting From the Network, General Problems

The system boots from the network, but from a
system other than the specified install server.

Cause:

An /etc/bootparams and
perhaps an /etc/ethers entry exist on another system
for the client.

Solution:

On the
name server, update the /etc/bootparams entry for the system
that is being installed. The entry should conform to the following syntax:

install_system root=boot_server:path install=install_server:path

Also, ensure that only one bootparams entry is on
the subnet for the install client.

The system does not boot from the network
(network installations with DHCP only).

Cause:

The DHCP server is not configured correctly.
This error might occur if the system is not configured as an installation
client on the DHCP server.

Initial Installation of the Solaris
OS

Initial installation fails

Solution:

If the Solaris installation fails, you must
restart the installation. To restart the installation, boot the system from
the Solaris Operating System DVD, the Solaris Software - 1 CD, or from the network.

You cannot uninstall the Solaris software after the software has been
partially installed. You must restore your system from a backup or begin the
Solaris installation process again.

/cdrom/cdrom0/SUNWxxxx/reloc.cpio: Broken pipe

Description:

This error message is informational and
does not affect the installation. The condition occurs when a write on a pipe
does not have a reading process.

Solution:

Ignore the message and continue with the
installation.

WARNING: CHANGE DEFAULT BOOT DEVICE (x86 based systems only)

Cause:

This is an informational message. The default
boot device set in the system's BIOS might be set to a device that requires
you to use the Solaris Device Configuration Assistant to boot the system.

Solution:

Continue with the installation and, if necessary,
change the system's default boot device specified in the BIOS after you install
the Solaris software to a device that does not require the Solaris Device Configuration Assistant.

x86 only –

If you are using the locale keyword
to test a custom JumpStart profile for an initial installation, the pfinstall-D command fails to test the profile. For a workaround,
see the error message “could not select locale,” in the section, Upgrading the Solaris OS.

x86: To Check IDE Disk for Bad Blocks

IDE disk drives do not automatically map out bad blocks like other drives
supported by Solaris software. Before installing Solaris on an IDE disk, you
might want to perform a surface analysis on the disk. To perform surface analysis
on an IDE disk, follow this procedure.

A patch is needed to install Solaris Live
Upgrade. Ensure that you have the most recently updated patch list by consulting http://sunsolve.sun.com.
Search for the info doc 72099 on the SunSolve web site.

Upgradeable Solaris root devices were
found, however, no suitable partitions to hold the Solaris install software
were found. Upgrading using the Solaris Installer is not possible. It might
be possible to upgrade using the Solaris Software 1 CDROM. (x86 based systems
only)

Cause:

You cannot upgrade with the Solaris Software - 1 CD
because you do not have enough space.

Solution:

To upgrade, you can either create a swap
slice that is larger than or equal to 512 Mbytes or use another method of
upgrading such as the Solaris installation program from Solaris Operating System DVD, a net installation image,
or JumpStart.

ERROR: Could not select locale (x86 based systems only)

Cause:

When you test your JumpStart profile by using
the pfinstall-D command, the dry run test
fails under the following conditions:

The profile contains the locale keyword.

You're testing a release that contains GRUB software. Starting with the Solaris 10 1/06 release, the GRUB
boot loader facilitates booting different operating systems installed on your
system with the GRUB menu.

With the introduction of GRUB software, the miniroot is compressed.
The software can no longer find the list of locales from the compressed miniroot.
The miniroot is the smallest possible Solaris root (/)
file system and is found on the Solaris installation media.

The upgrade fails because the Solaris
installation program cannot mount a file system.

Cause:

During an upgrade, the script attempts to mount all the file systems
that are listed in the system's /etc/vfstab file on the
root (/) file system that is being upgraded. If the installation
script cannot mount a file system, it fails and exits.

Solution:

Ensure that all file systems in the system's /etc/vfstab file can be mounted. Comment out any file systems in
the /etc/vfstab file that cannot be mounted or that might
cause the problem so that the Solaris installation program does not try to
mount them during the upgrade. Any system-based file systems that contain
software to be upgraded (for example, /usr) cannot be
commented out.

ERROR: The media dirctory does not contain
an operating system upgrade image.

Description:

The error messages are seen
when using the luupgrade command to upgrade a new boot
environment.

Cause:

An older version of Solaris Live Upgrade is
being used. The Solaris Live Upgrade packages you have installed on your system
are incompatible with the media and the release on that media.

Solution:

Always use the Solaris Live Upgrade packages
from the release you are upgrading to.

Example:

In the following example, the error message
indicates that the Solaris Live Upgrade packages on the system are not the
same version as on the media.

# luupgrade -u -n s10u1 -s /mnt
Validating the contents of the media </mnt>.
The media is a standard Solaris media.
ERROR: The media product tools installation directory
</mnt/Solaris_10/Tools/Boot/usr/sbin/install.d/install_config> does
not exist.
ERROR: The media </mnt> does not contain an operating system upgrade
image.

ERROR: Cannot find or is not executable:
</sbin/biosdev>.

ERROR: One or more patches required by Solaris Live Upgrade has not
been installed.

Cause:

One or more patches required by Solaris Live
Upgrade are not installed on your system. Beware that this error message
does not catch all missing patches.

Solution:

Before using Solaris Live Upgrade, always
install all the required patches. Ensure that you have the most recently updated
patch list by consulting http://sunsolve.sun.com. Search for the info doc 72099 on the SunSolve web site.

The file system containing the GRUB
menu was accidentally remade. However, the disk has the same slices as before.
For example, the disk was not re-sliced.

Cause:

The file system that contains the GRUB menu
is critical to keeping the system bootable. Solaris Live Upgrade commands
do not destroy the GRUB menu. But, if you accidentally remake or otherwise
destroy the file system containing the GRUB menu with a command other than
a Solaris Live Upgrade command, the recovery software attempts to reinstall
the GRUB menu. The recovery software puts the GRUB menu back in the same file
system at the next reboot. For example, you might have used the newfs or mkfs commands on the file system and accidentally destroyed the
GRUB menu. To restore the GRUB menu correctly, the slice must adhere to the
following conditions:

Contain a mountable file system

Remain a part of the same Solaris Live Upgrade boot environment
where the slice resided previously

Before rebooting the system, make any necessary corrective actions on
the slice.

Solution:

Reboot the system. A backup copy of the GRUB
menu is automatically installed.

The GRUB menu's menu.lst file
was accidentally deleted.

Solution:

Reboot the system. A backup copy of the GRUB
menu is automatically installed.

System Panics When Upgrading With Solaris
Live Upgrade Running Veritas VxVm

When you use Solaris Live Upgrade while upgrading and running Veritas
VxVM, the system panics on reboot unless you upgrade by using the following
procedure. The problem occurs if packages do not conform to Solaris advanced
packaging guidelines.

x86: Service Partition Not Created by Default
on Systems With No Existing Service Partition

If you install the Solaris 10 8/07 OS on a system that does
not currently include a service or diagnostic partition, the installation
program might not create a service partition by default. If you want to include
a service partition on the same disk as the Solaris partition, you must
re-create the service partition before you install the Solaris 10 8/07 OS.

If you installed the Solaris 8 2/02 OS on a system with a service partition,
the installation program might not have preserved the service partition.
If you did not manually edit the fdisk boot partition
layout to preserve the service partition, the installation program deleted
the service partition during the installation.

Note –

If you did not specifically preserve the service partition when
you installed the Solaris 8 2/02 OS, you might not be able to re-create the
service partition and upgrade to the Solaris 10 8/07 OS.

If you want to include a service partition on the disk that contains
the Solaris partition, choose one of the following workarounds.

To Install Software From a Network Installation Image or From
the Solaris Operating System DVD

To install the software from a net installation image or from the Solaris Operating System DVD over
the network, follow these steps.

Delete the contents of the disk.

Before you install, create the service partition by using the
diagnostics CD for your system.

For information about how to create
the service partition, see your hardware documentation.

Boot the system from the network.

The Customize fdisk Partitions screen is displayed.

To load the default boot disk partition layout, click Default.

The installation program preserves the service partition and creates
the Solaris partition.

To Install From the Solaris Software - 1 CD or From a Network
Installation Image

To use the Solaris installation program to install from the Solaris Software - 1 CD
or from a network installation image on a boot server, follow these steps.

Delete the contents of the disk.

Before you install, create the service partition by using the
diagnostics CD for your system.

For information about how to create
the service partition, see your hardware documentation.

The installation program prompts you to choose a method for creating
the Solaris partition.

Boot the system.

Select the Use rest of disk for Solaris partition option.

The installation program preserves the service partition and
creates the Solaris partition.

Complete the installation.

Appendix B Additional
SVR4 Packaging Requirements (Reference)

This appendix is for system administrators who install or remove
packages, especially third-party packages. Following these packaging requirements
enables the following:

Avoids modifying the currently running system so you can upgrade
with Solaris Live Upgrade and create and maintain non-global zones and diskless
clients

Prevents a package from being interactive to automate installations
when using installation programs such as custom JumpStart

Preventing Modification of the Current OS

Following the requirements in this section keeps the currently running
OS unaltered.

Using Absolute Paths

For an installation of an operating system to be successful, packages
must recognize and correctly respect alternate root (/) file systems, such
as a Solaris Live Upgrade inactive boot environment.

Packages can include absolute paths in their pkgmap file
(package map). If these files exist, they are written relative to the -R option
of the pkgadd command. Packages that contain both absolute
and relative (relocatable) paths can be installed to an alternative root (/) file system as well. $PKG_INSTALL_ROOT is prepended
to both absolute and relocatable files so all paths are resolved properly
when being installed by pkgadd.

Using the pkgadd-R Command

Packages being installed by using the pkgadd-R option
or being removed using the pkgrm-R option
must not alter the currently running system. This feature is used by custom
JumpStart, Solaris Live Upgrade, non-global zones and diskless client.

Any procedure scripts that are included in the packages being installed
with the pkgadd command -R option or being
removed by using the pkgrm command -R option
must not alter the currently running system. Any installation scripts that
you provide must reference any directory or file that is prefixed with the $PKG_INSTALL_ROOT variable. The package must write all directories
and files with the $PKG_INSTALL_ROOT prefix. The package must
not remove directories without a $PKG_INSTALL_ROOT prefix.

Differences Between $PKG_INSTALL_ROOT and $BASEDIR Overview

$PKG_INSTALL_ROOT is the location of the root (/)
file system of the machine to which you are adding the package. The location
is set to the -R argument of the pkgadd command.
For example, if the following command is invoked, then $PKG_INSTALL_ROOT becomes /a during the installation of the package.

# pkgadd -R /a SUNWvxvm

$BASEDIR points to the relocatable base
directory into which relocatable package objects are installed. Only relocatable
objects are installed here. Nonrelocatable objects (those that have absolute paths in the pkgmap file) are always installed
relative to the inactive boot environment, but not relative to the $BASEDIR in effect. If a package has no relocatable objects, then the package
is said to be an absolute package (or nonrelocatable), and $BASEDIR is
undefined and not available to package procedure scripts.

If this package is installed with the following command, then ls is
installed in /a/opt/sbin/ls, but ls2 is
installed as /a/sbin/ls2.

# pkgadd -R /a SUNWtest

Guidelines for Writing Scripts

Your package procedure scripts must be independent of the currently
running OS to prevent modifying the OS. Procedure scripts define actions that
occur at particular points during package installation and removal. Four procedure
scripts can be created with these predefined names: preinstall, postinstall, preremove, and postremove.

Table B–2 Guidelines For Creating
Scripts

Guidelines

Affects Solaris Live Upgrade

Affects non-global zones

Scripts must be written in Bourne shell (/bin/sh).
Bourne shell is the interpreter that is used by the pkgadd command
to execute the procedure scripts.

X

X

Scripts must not start or stop any processes or depend on the output
of commands such as ps or truss, which
are operating system dependent and report information about the currently
running system.

X

X

Scripts are free to use other standard UNIX commands such as expr, cp, and ls and other commands that facilitate
shell scripting.

X

X

Any commands that a script invokes must be available in all supported
releases, since a package must run on all of those releases. Therefore, you
cannot use commands that were added or removed after the Solaris 8 release.

To verify that a specific command or option is supported in a Solaris
8, 9, or 10 release, see the specific version of Solaris Reference
Manual AnswerBook on http://docs.sun.com.

X

Maintaining Diskless Client Compatibility

Packages must not execute commands delivered by the package itself.
This is to maintain diskless client compatibility and avoids running commands
that might require shared libraries that are not installed yet.

Verifying Packages

All packages must pass pkgchk validation. After a
package is created and before it is installed, it must be checked with the
following command.

# pkgchk -ddir_namepkg_name

dir_name

Specifies the name of the directory where the package resides

pkg_name

Specifies the name of the package

Example B–1 Testing a Package

After a package is created, it must be tested by installing it in an
alternate root (/) file system location by using the -Rdir_name option to pkgadd.
After the package is installed, it must be checked for correctness by using pkgchk, as in this example.

# pkgadd -d . -R /a SUNWvxvm
# pkgchk -R /a SUNWvxvm

No errors should be displayed.

Example B–2 Testing a Package on /export/SUNWvxvm

If a package exists at /export/SUNWvxvm, then you
would issue the following command.

# pkgchk -d /export SUNWvxvm

No errors should be displayed.

Other commands can check the package when you are creating, modifying,
and deleting files. The following commands are some examples.

For example, the dircmp or fssnap commands
can be used to verify that packages behave properly.

Also, the ps command can be used for testing
daemon compliance by making sure daemons are not stopped or started by the
package.

The truss, pkgadd -v,
and pkgrm commands can test runtime package installation
compliance, but might not work in all situations. In the following example,
the truss command strips out all read-only, non-$TEMPDIR access and shows only non-read-only access to paths that do not lie
within the specified inactive boot environment.

Preventing User Interaction When Installing
or Upgrading

Packages must be added or removed without the user being prompted for
information when using the following standard Solaris utilities.

The custom JumpStart program

Solaris Live Upgrade

Solaris installation program program

Solaris Zones

To test a package to ensure that it will install with no user interaction,
a new administration file can be set up with the pkgadd command -a option. The -a option defines an installation administration
file to be used in place of the default administration file. Using the default
file might result in the user being prompted for more information. You can
create an administration file that indicates to pkgadd that
it should bypass these checks and install the package without user confirmation.
For details, see the man page admin(4) or pkgadd(1M).

The following examples show how the pkgadd command
uses the administration file.

If no administration file is provided, pkgadd uses /var/sadm/install/admin/default. Using this file might result in
user interaction.

# pkgadd

If a relative administration file is provided on the command
line, pkgadd looks in /var/sadm/install/admin for
the file name and uses it. In this example, the relative administration file
is named nocheck and pkgadd looks
for /var/sadm/install/admin/nocheck.

# pkgadd -a nocheck

If an absolute file is provided pkgadd uses
it. In this example, pkgadd looks in /tmp for
the nocheck administration file.

# pkgadd -a /tmp/nocheck

Example B–3 Installation Administration File

The following is an example of an installation administration file that
requires very little user interaction with the pkgadd utility.
Unless the package requires more space than is available on the system, the pkgadd utility uses this file and installs the package without prompting
the user for more information.

Setting Package Parameters For Zones

Packages have parameters that control how their content is distributed
and made visible on a system with non-global zones installed. The SUNW_PKG_ALLZONES, SUNW_PKG_HOLLOW, and SUNW_PKG_THISZONE package
parameters define the characteristics of packages on a system with zones installed.
These parameters must be set so that packages can be administered in a system
with non-global zones.

The following table lists the four valid combinations for setting package
parameters. If you choose setting combinations that are not listed in the
following table, those settings are invalid and result in the package failing
to install.

Note –

Ensure that you have set all three package parameters. You can
leave all three package parameters blank. The package tools interpret a missing
zone package parameter as if the setting were “false,” but not
setting the parameters is strongly discouraged. By setting all three package
parameters, you specify the exact behavior the package tools should exhibit
when installing or removing the package.

Table B–3 Valid Package Parameter
Settings For Zones

SUNW_PKG_ALLZONES Setting

SUNW_PKG_HOLLOW Setting

SUNW_PKG_THISZONE Setting

Package Description

false

false

false

This is the default setting for packages that do not specify values
for all the zone package parameters.

A package with these settings can be installed in either the global
zone or a non-global zone.

If the pkgadd command is run in the global
zone, the package is installed in the global zone and in all non-global zones.

If the pkgadd command is run in a non-global
zone, the package is installed in the non-global zone only.

In both cases, the entire contents of the package is visible in all
zones where the package is installed.

false

false

true

A package with these settings can be installed in either the global
zone or a non-global zone. If new non-global zones are created after the installation,
the package is not propagated to these new non-global zones.

If the pkgadd command is run in the global
zone, the package is installed in the global zone only.

If the pkgadd command is run in a non-global
zone, the package is installed in the non-global zone only.

In both cases, the entire contents of the package is visible in the
zone where the package is installed.

true

false

false

A package with these settings can be installed in the global zone only.
When the pkgadd command is run, the package is installed
in the global zone and in all non-global zones. The entire contents of the
package is visible in all zones.

For package dependency checking purposes, the package appears to be
installed in all zones.

In the global zone, the entire contents of the package is
visible.

In whole root non-global zones, the entire contents of the
package is not visible.

When a non-global zone inherits a file system from the global
zone, a package installed in this file system is visible in a non-global zone.
All other files delivered by the package are not visible within the non-global
zone.

For example, a sparse root non-global zone shares certain
directories with the global zone. These directories are read-only. Sparse
root non-global zones share the /platform file system
among others. Another example is packages that deliver files relevant only
to booting hardware.