This topic describes known problems and issues associated with the Update Installer for WebSphere Software program.
The update installer program displays its version information in the title bar of the graphical interface. Version information is stored in the version.txt file in the updateinstaller directory.
A new version might ship to correspond to any new fix. Information in the version.txt file is displayed prominently in the title bar of the wizard and is also recorded in the updatelog.txt file.
Always download and use the latest version of the Update installer wizard when installing an interim fix.
The Update Installer can not automatically detect locks on files by remote processes. So you must ensure that all AppServers processes have been stopped for all your profiles, including any remote profiles.
The following table describes known problems and when the problems were resolved. See the Workarounds section that follows the table for more information.
Description of problem | Workaround | Version with resolution |
---|---|---|
Product uninstall does not remove the updated product correctly. | Product uninstall | Current problem |
Relaunch action for SDK updates does not relaunch the
update installer.
|
Relaunch fails | Current problem |
Always use the most current version of the Update Installer for WebSphere Software to install maintenance packages | Use the most current version | Current problem |
Control returns prematurely to the command line when the Update Installer rolls back an updated IBM Software Development Kit (SDK). | Control returns prematurely | Limitation |
The Update Installer fails to relaunch after copying the IBM Software Development Kit (SDK) if not enough disk space is available for installation | Relaunch failure due to insufficient disk space | Limitation |
Non-root profiles start with error after installing Refresh Pack 2 | Service for profiles can change file owner | Limitation |
Problem in cloning the SDK for updates to the product SDK | SDK does not copy correctly | V6.0.2 |
Profile update and undo scripts are limited to SBCS and to characters without pronunciation keys due to operating system limitations | Accented characters in profile file path cause problems | Limitation |
Profiles can exist at the Version 6.0.2 level after rolling back Refresh Pack 2. | Profiles remain at the Version 6.0.2 level after roll back | Limitation |
InstallShield for Multiplatforms (ISMP) detects Windows 2003 64-bit AMD platform as Windows XP 64-bit AMD platform | ISMP incorrectly detects Windows 2003 64-bit AMD | V6.0.2 |
A previous version of the Update Installer can prevent the Version 6.0.2.x version of the Update Installer from working properly. | Delete previous Update Installer | Current problem |
The following section describes workarounds for current problems.
Problem: The product uninstaller for Version 6.0.x.x cannot delete all files and directories that exist after installing a refresh pack or a fix pack.
Description: If you apply a refresh pack or a fix pack using the update installer program and then uninstall the whole product using the Version 6.0.0.0 product uninstaller program, many files are left on the system.
Cause: The product uninstaller program will be fixed in a later release.
Problem: The update installer program cannot launch a second ISMP process that uses the cloned copy of the SDK in the app_server_root/updateinstaller/java/jre directory.
app_server_root /updateinstaller /java /jre
After copying the SDK, the update installer program stops the first ISMP process and launches a second process that uses the SDK in the app_server_root/updateinstaller/java/jre directory.
Cause: The update installer program will be fixed in a later release.
Customer action: If this problem occurs, launch the update installer program again. The update installer program uses the cloned copy of the SDK in the app_server_root/updateinstaller/java/jre directory if the copy is present.
./update -is:javahome app_server_root/updateinstaller/java
Problem: Older versions of the update installer program can fail to install newer maintenance packages properly.
"Prerequisite checking has failed. Failure messages follow:"
Contrary to the message, no additional messages display.
Cause: New maintenance packages often require a newer version of the update installer program.
Customer action: If the installation fails with the preceding error message, download the latest update installer program and reinstall the maintenance package. See the download page for the Update Installer to download the latest version.
Problem: Control returns prematurely to the command line when the Update Installer rolls back an updated IBM Software Development Kit (SDK).
Some maintenance packages, such as Refresh Pack 2 for WebSphere Application Server Version 6.0.0, include service for the IBM Software Development Kit, Java Technology Edition (SDK). When installing maintenance packages that include service to the SDK, the Update Installer for WebSphere Software copies or clones the SDK of the existing product. When you relaunch the Update Installer using the copied SDK, the product SDK is updated.
If you delete the copied SDK to free disk space after the maintenance package is installed, the Update Installer copies the SDK again if you uninstall or roll back the maintenance package.
./update -options responsefiles/uninstall.txt -silentIf you roll back a maintenance package that includes service to the SDK, the Update Installer copies the SDK and then automatically relaunches to roll back the maintenance package.
As the Update Installer relaunches, control returns to the command line even though the Update Installer is still running in the background.
./update -options responsefiles/uninstall.txt \ -silent \ -is:javahome app_server_root/updateinstaller/java
Or, you can let the Update Installer automatically clone the SDK and ignore the implication that the command line is ready to issue another command when control returns at the relaunch. The Update Installer is still running until it completes the roll back of the maintenance package.
See the app_server_root/logs/update/maintenance_package_name/updatelog.txt log file to determine when the operation is complete.
Problem: Relaunch failure for insufficient disk space after copying the IBM Software Development Kit (SDK) if not enough disk space is available for installation
Some maintenance packages, such as Refresh Pack 2 for WebSphere Application Server Version 6.0.0, include service for the IBM Software Development Kit, Java Technology Edition (SDK). When installing maintenance packages that include service for the SDK, the Update Installer for WebSphere Software copies the SDK of the existing product. Relaunching the Update Installer using the copied SDK allows the product SDK to be updated.
A possibility exists that the Update Installer can perform the first part of the update that copies the SDK, but that copying the SDK reduces the amount of available space to the point that the Update Installer cannot relaunch to continue the update.
Initializing InstallShield Wizard... Searching for Java(tm) Virtual Machine... A suitable JVM could not be found. Please run the program again using the option -is:javahome JAVA_HOME_DIR Error writing file = There may not be enough temporary disk space. Try using -is:tempdir to use a temporary directory on a partition with more disk space.
Description: A design limitation prevents the Update Installer from checking for available disk space before copying the SDK. During relaunch, the Java Virtual Machine (JVM) attempts to start but must stop because of the lack of disk space. Without the JVM, the Update Installer cannot start.
Customer action: Each maintenance package includes space requirements for the file system that contains the installation root directory of the WebSphere Application Server product, and for the system temporary directory.
If an interim fix does not state a disk requirement, verify that 100 MB of space is available in the file system and another 100 MB of space is available in the system temporary directory.
For example, the readme file for Refresh Pack 2 for Version 6.0.0 includes service for the SDK states that the amount of free temp space required is 250 MB and that the free space required on the file system is 600 MB.
Problem:
Maintenance packages with required service for existing profiles can change file ownership.
The root user runs the Update Installer wizard to install maintenance packages for WebSphere Application Server Version 6.x products. Some maintenance packages include required service for existing profiles.
Non-root users can own profiles on Linux and UNIX systems. If the root user updates an existing non-root profile, any new files that the maintenance package creates are owned by the root user instead of the non-root user.
When an application server in a non-root profile starts, it attempts to load the new files. Because the new files belong to the root user, the application server encounters an error and issues a message that is similar to the following example:
ADMR0104E: The system is unable to read document cells/MyCell/nodes/mynode/ node-metadata.properties: java.io.IOException: No such file or directory
Description:
Installing a maintenance package that contains service for a non-root profile changes the ownership of any new files that the maintenance package creates. The user who installs the maintenance becomes the owner of the new files. The root user is required to install maintenance for Version 6.x. Therefore, after installing the maintenance, root owns any new files in the profile.
Customer action:
To fix the problem, reassign ownership of the entire profile directory to the non-root user (wsdemo in the following example). The profile_root variable in the following example is the profile directory that the non-root user owns.
The root user can make the wsdemo user the owner of the profile directory with the following command:
chown -R wsdemo profile_root
For more information about the JDBC resource provider templates that are updated in Refresh Pack 2 for WebSphere Application Server, see the UPDI: Refresh Pack 2 for WebSphere Application Server includes required service for the JDBC resource provider templates in existing profiles technote.
The description of the wasprofile command includes a scenario for creating non-root profiles. See wasprofile command for more information.
Problem:
A defect in previous versions of the Update Installer wizard is now fixed in Version 6.0.2. The error prevents the SDK from being cloned when there is service to the product SDK.
"Failure: The JDK copy has failed"
The error causes the following entries in the log file and the trace file entries.
Entries in the updatelog.txt file
/usr/IBM/WebSphere/AppServer/updateinstaller/././java/jre Target: /usr/IBM/WebSphere/AppServer/updateinstaller/java:, percent complete: 0% (Jun 7, 2005 1:17:31 PM), Install, com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction, err, null (Jun 7, 2005 1:17:31 PM), Install, com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction, err, null (Jun 7, 2005 1:17:31 PM), Install, com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction, err, java.io.IOException
Entries in the upatetrace.txt file
<message>java.io.IOException at com.ibm.ws.install.ni.framework.io.DiskFileSystem.setPermissions(DiskFil eSystem.java:188) at com.ibm.ws.install.ni.framework.io.FileSystemEntry.setPermissions(FileSy stemEntry.java:167) at com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction.copySourceToT arget(ISMPCopyDirectoryAction.java:143) at com.ibm.ws.install.ni.ismp.actions.ISMPCopyDirectoryAction.execute(ISMPC opyDirectoryAction.java:66) at com.installshield.wizard.RunnableWizardBeanContext.run(RunnableWizardBea nContext.java:21) </message>
Customer action:
Manually copy the SDK before starting the Update Installer when the maintenance package contains service for the product SDK. Or, use the Version 6.0.2 level of the Update Installer to install the maintenance package.
Copy the product SDK to the app_server_root/updateinstaller/java/jre directory.
./update -is:javahome app_server_root/updateinstaller/java
Problem:
Shell scripts that perform service updates to existing profiles can fail if the profile path or the profile name contains accented characters.
Failure symptoms include a partial success message in the updatelog.txt file.
For example, the updateProfileJdbcTemplates.ant script runs during the installation of Refresh Pack 2 on WebSphere Application Server products.
In general, if the following message is present in the updateconfig.log file, run the JACL script using the wsadmin command to perform a manual update of all potentially affected profiles.
<message> Result of executing C:\WAS60GM\properties\version\update\config\install\ updateProfileJdbcTemplates.ant was: false </message>
Running the script does not harm profiles that are already updated.
Description:
Shell scripts on some operating systems cannot contain single-byte characters with pronunciation keys.
If the file path to the profile or the profile name includes single-byte characters with pronunciation keys, such as o-umlaut (a diacritic mark over the o), c-cedilla (a mark is under the c), or characters with other keys, the script might not run correctly.
Customer action:
Run a failing ANT script by copying the content to the command line and running the wsadmin command directly.
See the documentation for each failing ANT script to determine how to run its underlying JACL script using the wsadmin command. For example, see the UPDI: Refresh Pack 2 for WebSphere Application Server includes required service for the JDBC resource provider templates in existing profiles technote for more information about running the updateProfileJdbcTemplates.jacl script.
Problem:
Profiles can exist at the Version 6.0.2 level after rolling back Refresh Pack 2.
If you install Refresh Pack 2 for a WebSphere Application Server product and create a new profile, the resulting profile is at the Version 6.0.2 level. If you roll back Refresh Pack 2 with the update -W update.type="uninstall" command, the fix level of the product is either Version 6.0.0 or Version 6.0.1, but any Version 6.0.2 profiles still exist at the Version 6.0.2 level.
A Version 6.0.2 profile might not start or might run with errors if the fix level of the product is at a lesser level.
The problem can also occur within a cell, when the deployment manager, the node agent, or a federated application server is at the Version 6.0.2 level, but the product level is either Version 6.0.0 or Version 6.0.1.
Description:
V6.0.2 uses multihome support for profiles, which results in an * (asterisk) as the value of the host name field in the DCS_UNICAST_ADDRESS endpoint. Version 6.0.0 and Version 6.0.1 use a string value for the host name field.
V6.0.2 profiles have a value for host name that the Version 6.0.0 or Version 6.0.1 product cannot interpret. The result is an error when the Version 6.0.2 profile starts. Therefore, a new Version 6.0.2 profile is not supported in a Version 6.0.0-level or Version 6.0.1-level product.
Customer action:
Delete the Version 6.0.2-level profiles and recreate them at the current product level.
Problem:
The InstallShield for Multiplatforms (ISMP) Update Installer wizard detects the Windows 2003 64-bit AMD platform as a Windows XP 64-bit AMD platform when installing Refresh Pack 2 for a WebSphere Application Server product.
The Installation wizard that installs WebSphere Application Server Version 6.0.1.1 on Windows 2003 64-bit AMD platforms, logs the results of the installation in the log.txt file.
When installing Refresh Pack 2 (Version 6.0.2) on 64-bit AMD Windows 2003 platforms, the Update Installer logs the results of the installation of the maintenance package in the updatelog.txt file.
Both log files have entries that incorrectly identify the Windows 2003 system as a Windows XP system.
(date) UpdateInstaller, com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction, msg1, Java Install Path: C:\ND\IBM\WebSphere\AppServer\updateinstaller\java (date) UpdateInstaller, com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction, msg1, OS Name: Windows XP (date) UpdateInstaller, com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction, msg1, OS Architecture: amd64 (date) UpdateInstaller, com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction, msg1, OS Version: 5.2 build 3790 Service Pack 1 (date) UpdateInstaller, com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction, msg1, Current User ID: amd41 (date) UpdateInstaller, com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction, msg1, Current User Home: C:\Documents and Settings\Administrator (date) UpdateInstaller, com.ibm.ws.install.ni.ismp.actions.ISMPLogFileAction, msg1, Current Working Directory: C:\ND\IBM\WebSphere\AppServer
Description:
The Update Installer for WebSphere Software is using the IBM Software Development Kit (SDK), Java Technology Edition, that is included with the Version 6.0.1.1 product. The SDK causes the erroneous platform identification.
Customer action:
While installing Refresh Pack 2 (Version 6.0.2), the Update Installer updates the SDK. The updated SDK can correctly identify the Windows 2003 operating system platform. Further use of the Update Installer program, such as to install an interim fix or a fix pack for Version 6.0.2, creates entries in the updatelog.txt file that correctly identify the Windows 2003 system.
Ignore the incorrect platform specification in the log files for the Version 6.0.1.1 installation and the installation of Refresh Pack 2. WebSphere Application Server Version 6.0.2 does support the Windows 2003 64-bit AMD platform in spite of the messages in the log files.
Problem:
(Jul 8, 2005 4:06:23 PM), UpdateInstaller, com.installshield.wizard.RunnableWizardBeanContext, err, java.lang.NoSuchMethodError: com.ibm.ws.install.ni.framework. fileactions.FileActionPlugin: method getInverseFileActionID(Ljava/util/Hashtable; Lcom/ibm/ws/install/ni/framework/ installtoolkitbridge/InstallToolkitBridge;) Ljava/lang/String; not found STACK_TRACE: 14 java.lang.NoSuchMethodError: com.ibm.ws.install.ni.framework.fileactions. FileActionPlugin: method getInverseFileActionID(Ljava/util/Hashtable; Lcom/ibm/ws/install/ni/framework/ installtoolkitbridge/InstallToolkitBridge;) Ljava/lang/String; not found at com.ibm.ws.install.ni.updi.component.was. FilesListParser.getInverseFileActionDetails (FilesListParser.java:412) at com.ibm.ws.install.ni.updi.component.was. FilesListParser.getInverseFilesListForThisComponent (FilesListParser.java:144) at com.ibm.ws.install.ni.updi.component.was. ComponentDeployAction. createInverseFilesListFileInTheComponentBackupRepository (ComponentDeployAction.java:87) at com.ibm.ws.install.ni.updi.component.was. ComponentDeployAction.execute(ComponentDeployAction.java:52) at com.ibm.ws.install.ni.updi.component.was. UpdateComponent.execute(UpdateComponent.java:62) at com.ibm.ws.install.ni.framework.component. ComponentAction.executeComponentActions (ComponentAction.java:158) at com.ibm.ws.install.ni.framework.component. ComponentAction.executeBackupComponentActions (ComponentAction.java:52) at com.ibm.ws.install.ni.framework.maintenanceplugins. MaintenanceApplicationPlugin.performUpgrade (MaintenanceApplicationPlugin.java:246) at com.ibm.ws.install.ni.framework.maintenanceplugins. MaintenanceApplicationPlugin.execute (MaintenanceApplicationPlugin.java:60) at com.ibm.ws.install.ni.framework.maintenanceplugins. FixpackApplicationPlugin.execute (FixpackApplicationPlugin.java:45) at com.ibm.ws.install.ni.ismp.actions. InstallMaintenancePackage.execute (InstallMaintenancePackage.java:73) at com.installshield.wizard.RunnableWizardBeanContext.run (RunnableWizardBeanContext.java:21)
Description:
A previous version of the Update Installer can interfere with the Version 6.0.2.x version of the Update Installer.
Customer action: