Update command - known problems and workarounds

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.




Related tasks
Installing maintenance packages

Known problems in Version 6.0.x

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.

[HP-UX] This is a known problem on some HP-UX systems.

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

_updi

Workarounds for Version 6.0.x problems

The following section describes workarounds for current problems.

Product uninstall

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.

Customer action: Two workarounds exist. Use either of the following workarounds to circumvent the problem:
  • Uninstall all maintenance packages using the update installer program before uninstalling the product.
  • Delete all remaining directories after uninstalling the product.

Relaunch fails

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.

Description: When a refresh pack, fix pack, or interim fix updates the IBM SDK, Java Technology edition (SDK), the update installer program clones the SDK in the product by starting an ISMP process to copy the SDK to 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.

If the cloning fails, copy the SDK before starting the Update Installer wizard:
  1. Copy the app_server_root/java/jre directory to the app_server_root/updateinstaller/java directory.
  2. Change directories to the app_server_root/updateinstaller directory.
  3. Start the installation with the following command:
    ./update -is:javahome app_server_root/updateinstaller/java 

Use the most current version

Problem: Older versions of the update installer program can fail to install newer maintenance packages properly.

Description: If the installation fails, messages about missing prerequisites do not display. Instead of messages about specific prerequisite failures, a blank failure panel displays the following message:
"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.

Control returns prematurely

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.

Description: You can start the Update Installer wizard from the command line in silent mode, to roll back a maintenance package that includes service to the SDK. The following example shows such a command. The command in the example uses a response file to identify a maintenance package and the uninstall action:
 ./update -options responsefiles/uninstall.txt -silent 
If 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.

Customer action: On Linux and UNIX systems, you can work around the problem by copying the SDK yourself before launching the Update Installer. Use the following procedure:
  1. Copy the app_server_root/java/jre directory to the app_server_root/updateinstaller/java directory.
  2. Change directories to the app_server_root/updateinstaller directory.
  3. Start the installation with the following command:
    ./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.

Relaunch failure due to insufficient disk space

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.

When the problem occurs, if you click Relaunch. nothing happens. The relaunch of the Update Installer does not occur. If you attempt to start the Update Installer manually with the ]update[ command, the following error occurs:
  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.

[Linux] [AIX HP-UX Solaris]

Service for profiles can change file owner

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.

For example, Refresh Pack 2 has required service for the Java Database Connectivity (JDBC) resource provider templates. The required service backs up some existing files and creates new versions of the files. The new files are owned by the user who installs the maintenance package. When the root user installs Refresh Pack 2, the root user owns the following JDBC-related files:
  • profile_root/logs/updateProfileJdbcTemplate.log
  • profile_root/config/templates/system/ jdbc-resource-provider-only-templates.xml
  • profile_root/config/templates/system/ jdbc-resource-provider-templates.xml

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.

SDK does not copy correctly

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.

  1. Copy the app_server_root/java/jre directory to the app_server_root/updateinstaller/java directory.
  2. Change directories to the app_server_root/updateinstaller directory.
  3. Start the installation with the following command:
    ./update -is:javahome app_server_root/updateinstaller/java 

Accented characters in profile file path cause problems

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.

Profiles remain at the Version 6.0.2 level after roll back

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.

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.

ISMP incorrectly detects Windows 2003 64-bit AMD

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.

The following example shows entries that might be in the updatelog.txt file:
(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.

Delete previous Update Installer

Problem:

Delete the previous version of the Update Installer before downloading and unpacking the Version 6.0.2.x version of the Update Installer. If you download and unpack Refresh Pack 2 into an existing app_server_root/updateinstaller directory, the Version 6.0.2.x Update Installer can fail with the following symptoms:
(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:

Use the following procedure to avoid the problem:
  1. Install the Version 6.0 (Version 6.0.0.1) or Version 6.0.1 product from the appropriate compact disc or distribution media.
  2. Back up and delete any older copy of the Update Installer before downloading the current Update Installer. To use a newer version of the Update Installer, you must first remove the older version.
    1. Back up any files and subdirectories in the app_server_root/updateinstaller/maintenance directory, if necessary.
    2. Delete the app_server_root/updateinstaller/maintenance directory and all of its subdirectories.
  3. Download and unpack the appropriate Refresh Pack 2 file from the Support site into the installation root directory. Unpacking the refresh pack creates the app_server_root/updateinstaller/maintenance directory. The Update Installer for WebSphere Software is in the app_server_root/updateinstaller directory.
  4. Use the Update Installer to install Refresh Pack 2 for Version 6.0, to bring the fix level of the product to Version 6.0.2.
Reference topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 5:25:00 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-base-dist&topic=rins_update_probs
File name: rins_update_probs.html