This section addresses the following problems you might encounter during installation.
Installation Fails Due to Leftover Files During Uninstallation
Installation Fails Due to Removed Shared Components in Product Registry After Uninstallation
Cannot Configure IBM WebSphere as the Portal Server Web Container
Silent Installation Fails: “State File is Incompatible or Corrupted”
Uninstallation can leave behind components or packages. In such a case, you must manually remove the components or packages before you reinstall Java ES. You might discover this problem in the following ways:
The uninstaller fails, providing the name of the package it failed to uninstall.
You want to install a component but the installer reports that the component is already installed, even though you removed it.
Use the following command to determine whether any packages were partially installed.
For Solaris OS:
pkginfo -p |
For Linux:
rpm -qa |grep sun | xargs rpm -V |
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 2005Q4 Installation Reference to discover what 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 components and their packages, with full information, including interdependencies. You can use the prodreg tool to safely uninstall components and remove packages. Once you have removed a component with the prodreg tool, you can reinstall.
On Solaris 8, use the pkgrm command.
The pkgrm command requires that you remove components one package at a time. This command does not update the product registry. Depending on what has happened, you can restore the archived product registry file or manually edit the product registry file so that it no longer refers to the removed components.
To edit the product registry file, open the file /var/sadm/install/productregistry . This XML file describes each component. Each component description opens with a <compid\> tag and closes with a </compid\> tag. Delete the entire entry for the component.
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 component. Each component description starts with a <compid\> tag and ends with a </compid\> tag. Delete the entire entry for the component.
Clean the /opt, /etc/opt and /var/opt directories.
Run the installer again.
As of the Java ES 2005Q4 release, shared components are listed in the product registry file after installation.
The Java ES uninstaller removes selectable 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 2005Q4 installation fails because the installer assumes that the manually deleted shared components are present (because they still have entries in the product registry file).
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: There is no equivalent of the graphical product registry file on Linux, so if you removed such rpm files by mistake, you must manually edit the product registry file.
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.
One approach is to check the configuration of your WebSphere instance.
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.
Another approach is to create new instances of the 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.
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
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.
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.
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 8, or, if you created the state file on the x86 platform, you cannot use it on the SPARC platform.
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.
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?
The most likely reason for this is that your MANPATH environment variable is not set correctly for the components you installed. Refer to MANPATH Setup.