Solaris 7 OnLine Release Notes (SUNWrdm)

Installation Bugs

JumpStart is Unable to Read DiskSuite^TM and Veritas Partitions (4109714)

If part of the Solaris operating environment has been installed on a DiskSuite or Veritas partition, JumpStart^TM cannot mount these partitions. As a result various tests in the rules file fail, including the one listed below:

installed any Solaris_2.6 begin profile finish

Specifically, this line in the rules file fails because JumpStart is unable to mount the partition containing the Solaris operating environment. Therefore, JumpStart does not recognize that the Solaris operating environment has been installed.

Workaround: Do not use JumpStart rules that depend on the installed keyword (or its negative) on systems that store part of the Solaris operating environment on DiskSuite or Veritas partitions.

Before Installation

Caution -

Be sure to read bug description ID 4121281 before you start upgrading your x86 system to the Solaris 7 operating environment.

x86 only: DiskSuite^TM May Cause Data Loss (4121281)

The DiskSuite metadb replicas contain driver names as part of the DiskSuite configuration data. In x86-based systems that run versions 2.4, 2.5, 2.5.1, and 2.6 of the Solaris operating environment, the SCSI driver name is called cmdk. The cmdk driver has been replaced by the sd driver in the Solaris 7 operating environment for x86 systems.

Workaround: To avoid potential data loss during upgrades to the Solaris 7 operating environment, you must save the system's metadevice configurations in text files and remove their metadb replicas before upgrading any x86 system that is running DiskSuite. After you finish upgrading your x86 system, you must restore the metadevice configurations by using the DiskSuite command line interface.

The DiskSuite Version 4.2 Release Notes contain a procedure for saving metadb configurations, removing metadb replicas, upgrading x86 systems to the Solaris 7 operating environment, upgrading DiskSuite to version 4.2, and restoring metadevice configurations. Bourne shell scripts that automate the procedure will be available for the FCS version of the Solaris 7 operating environment.

During Installation

The following bugs only occur during an installation.

Erroneous Messages Indicating Packages Added A Second Time (1235464)

This appears as an attempt to install the same architecture and version of a package that is already installed. This installation overwrites this package.

When upgrading a system with the "Entire Distribution plus OEM Cluster," the following packages seem to be added twice:

SUNWolinc
SUNWxwdim
SUNWxwinc
SUNWxwman
SUNWxwpmn
SUNWxwsrc
SUNWolbk
SUNWoldim
SUNWolman
SUNWolsrc

Workaround: If you try to add a package that has already been installed on a system, the installed package is overwritten.

Installation Progress Bar May be Inaacurate (1266156)

The "Installing Solaris Software - Progress" bar sometimes indicates that an installation is complete when it is still in progress. The install program may add packages for several minutes after the progress bar has indicated that the installation is complete.

Do not rely on the progress bar to indicate that the installation is complete. The installation displays the following message when the program has completed all installation operations:

Installation complete

JumpStart Installs on Wrong Default Boot Disk (4027156)

JumpStart does not install the default boot on the current default boot disk under some conditions. A condition under which the problem has been observed involves using a fully automated install on a SPARCstation 5 with two hard disk drives. Therefore, the previous version of the Solaris operating environment is booted instead of the current one when you reboot.

Workaround: Install the Solaris operating environment without JumpStart.

Installation of Diskless Client Does Not Preserve Changes in dfstab File on Server (4045544)

When you upgrade the Solaris operating environment on a server with diskless clients, the options on the dfstab line are not preserved for /usr. For example, if you entered the following in the dfstab file,

share -F nfs -o rw /export/exec/Solaris_2.7_sparc.all/usr

then this entry is automatically replaced with the following entry during the upgrade:

share -F nfs -o ro /export/exec/Solaris_2.7_sparc.all/usr

Workaround: Before you attempt to upgrade the Solaris operating environment on an OS server that has a diskless client or AutoClient, back up the /etc/dfs/dfstab file for the clients.

Installation Bugs Before the Start of an Upgrade

Caution -

Be sure to read bug description ID 4121281 before you start upgrading your x86 system to the Solaris 7 operating environment. This bug is described in the section called "Before Installation" earlier in this file. This problem may cause data loss.

Installation Bugs That May Occur During an Upgrade

All bugs described in this section only occur if you perform an upgrade.

Multiple Architecture Server Cannot Be Patched (1249343)

After upgrading a server with diskless clients of more than one SPARC kernel architecture, such as a sun4u server with diskless sun4c, sun4d, and sun4m clients, the SUNWkvm packages for clients whose kernel architectures differ from that of the server cannot be patched.

Workaround: Manually add all of the SUNWkvm packages before applying any patches that affect them.

# pkgadd -d  SUNWkvm.*

Disk Space Requirements can be Exaggerated by the Upgrade Process (4041733)

The upgrade program can exaggerate by as much as 30 percent the amount of space required for upgrades to systems with the Solaris software. Therefore, it prevents many systems from being upgraded without deselecting packages or finding more space.

Workaround: You can manually reallocate disk space among file systems or use the Software Customization menu to remove software packages that are not needed.

Upgrade exits with : Error: `upgrade_script` terminated abnormally.

This problem occurs when you have to reallocate disk space. The upgrade_log displays a syntax error in upgrade_script.

Workaround: Perform the following steps:

Find the line that contains "syntax error" in the upgrade script:

/tmp/root/var/sadm/system/logs/upgrade_log

For example:

syntax error is located at line 3519: `fi' unexpected

Edit the following file by using vi(1). (Using the vi text editor is recommended because of the size of the file).
/a/var/sadm/system/admin/upgrade_script
Go to the line containing the syntax error by using the vi(1) command 3519 G.

Look above this line for a fi that is on a line by itself above the line that has the syntax error. This should be located below a log progress statement. For example:

if [ $? = 0 ] ; then chgrp 1 
$base/export/root/petrel/etc/rmmount.conf; fi
logprogress 4073 none
fi   <------ This is the extra fi in upgrade_script
if [ 4074 -gt $resumecnt ] ; then
rm -f ${base}///var/sadm/install_data/CLUSTER
rm -f ${base}///var/sadm/system/admin/CLUSTER
echo CLUSTER=SUNWCall > ${base}///var/sadm/system/admin/CLUSTER
logprogress 4074 none
fi

Remove fi by typing x twice in the vi editor.

Save the following script:

/tmp/root/var/sadm/system/logs/upgrade_log upgrade

Halt the system by typing:
# halt 0
Restart the installation by typing one of the following commands:
OK> boot net
or
OK> boot cdrom
Select Upgrade again.

The installation should now complete.