Sun Java Enterprise System 5 Installation Guide for UNIX

Resolving Installation Problems

This section addresses the following problems you might encounter during installation.

Installation Fails Due to Files Left Behind During an Uninstallation

Uninstallation can leave behind product component files or packages. In such a case, you might need to manually remove the files or packages before you can reinstall Java ES. The installer reports that the product component is on the host, even though you thought you removed it.

The following might have occurred:

The uninstallation failed and an error message provided the name of the package that was not uninstalled, but no one resolved the problem.
The uninstallation failed but the error was not detected, so you believe packages were uninstalled when they were not.

To Clean Up a Partial Installation

Use the following command to determine whether any packages were partially installed.

Solaris OS: pkginfo -p

Linux: rpm -qa |grep —I ^sun | xargs rpm -V

HP-UX: swlist -l product sun-*

The command output lists any partially installed packages. Using the package names returned, refer to Chapter 5, List of Installable Packages, in Sun Java Enterprise System 5 Installation Reference for UNIX to discover what product component the packages belong to.

Remove components or packages.
- On Solaris 9 or 10, use the prodreg tool.
  
  The prodreg tool manages the package-based components on your host. You can view product components and their packages, with full information, including interdependencies. You can use the prodreg tool to safely uninstall product components and remove packages. Once you have removed a product component with the prodreg tool, you can reinstall.
- On Linux, use the rpm -e command.
  
  To edit the product registry file, open the file /var/opt/sun/install/productregistry. This XML file describes each product component. Each product component description starts with a <compid\> tag and ends with a </compid\> tag. Delete the entire entry for the product component.
- On HP-UX, use the swremove command.
  
  To edit the product registry file, open the file /var/adm/swproductregistry. This XML file describes each product component. Each product component description starts with a <compid\> tag and ends with a </compid\> tag. Delete the entire entry for the product component.

Verify that the following directories do not contain Java ES product components or packages:

/opt

/etc/opt

/var/opt

Run the installer again.

Installation Fails Due to Removed Shared Components in Product Registry After Uninstallation

As of the Java ES 5 release, shared components are listed in the product registry file after installation.

The Java ES uninstaller removes product components from the system but does not remove shared components. After an uninstallation, the product registry still contains entries for the shared components. If you manually remove any Java ES shared components after an uninstallation, these components are not removed from the product registry. Thus, the next Java ES 5 installation fails because the installer assumes that the manually deleted shared components are present (because they still have entries in the product registry file).

Tip –

Avoid manually removing Java ES shared components from your system.

Suggested Fix. Either remove the corresponding entries from the product registry file or remove the product registry file itself. Removing entries from the product registry file can cause the file to become corrupted, so you might prefer to remove the whole product registry. Before doing this, verify that products other than Java ES components are not using the product registry file.

On Linux and HP-UX there is no equivalent of the graphical product registry that exists on Solaris OS. If you manually removed files on Linux or HP-UX, you must manually edit the product registry file to remove those entries.

Cannot Configure IBM WebSphere as the Portal Server Web Container

WebSphere might not be running, or you might have specified a WebSphere value that does not match the WebSphere native configuration. There are two approaches to troubleshooting this issue. IBM WebSphere is only supported as a web container on Solaris OS.

Check the Configuration

One approach is to check the configuration of your WebSphere instance.

To Check the WebSphere Configuration

Ensure that WebSphere is running.

Examine the values for the following installer fields:
- WebSphere Virtual Host (PS_IBM_VIRTUAL_HOST in the state file)
- Application Server Name (PS_IBM_APPSERV_NAME in the state file)

Use the WebSphere tools to check the configuration to make sure it matches the values you are entering.

Try again.

Create New Instances

Another approach is to create new instances of the WebSphere entities.

To Create New Instances of WebSphere Entities

Use the adminclient.sh to start the WebSphere console.

Create a new virtual host instance and a new Application Server instance name.

Click the entry under Nodes (typically the host name), and select Regen WebServer Plugin.

This process saves the new entries into the plugin configuration file, which the installer checks for the legal names.

Return to the installer and enter the values you just created.

Unexpected External Error Occurs

A power failure or system failure might have occurred, or you might have entered CTRL/C to stop the installer process.

Suggested Fix. If the failure occurred during the installation or configuration process, you are probably left with a partial installation. Run the uninstaller. If the uninstaller fails, follow the instructions under Uninstallation Fails, Leaving Behind Files

Graphical Installer Seems Unresponsive

The installer sometimes creates an image on the screen before the image is ready for input. You cannot repeatedly click Next in the installation wizard without waiting.

Suggested Fix. The button that represents the default choice includes a blue rectangle. This rectangle sometimes appears after the button itself appears. Wait until you see the blue rectangle before clicking a button.

Silent Installation Fails: “State File is Incompatible or Corrupted”

If you are using a state file that was created on the same platform on which you are using it, the problem might be due to an unknown file corruption error. There are two approaches to troubleshooting this issue.

Generate a New State File

If you created the state file on the same platform on which you are running the silent installation, generate a new state file and reinstall.
If you are using a state file that was created on a different platform or version, the problem is that state files must be run on the same type of platform on which they are created. For example, if you created the state file on Solaris 9, you cannot use it on Solaris 10, or, if you created the state file on the x86 platform, you cannot use it on the SPARC platform.

Create a New Platform-Appropriate ID

If the platform on which you created the state file is not the same as the platform on which you are running the silent installation, create a new, platform-appropriate ID for the file. For instructions on how to do this, refer to Creating a Platform-Appropriate State File ID.

Silent Installation Fails After Editing the State File

If you edited the state file, you might have introduced errors. Check the following and regenerate the state file as described in Creating a State File.

Are all local host parameters set, and are they set to consistent values?
Are parameter values in the correct case?
Did you delete a required parameter without entering a replacement?
Are all port numbers valid and unassigned?

Suggested Fix. Resolve the problem and regenerate the state file.

Man Pages Do Not Display

The most likely reason for this is that your MANPATH environment variable is not set correctly for the components you installed.

Suggested Fix. Update /etc/MANPATH to point to the new man page directory. Refer to Verifying Man Pages .