Troubleshooting
Problem
Running an Install Factory created Customized Installation Package (CIP) against a previously-installed WebSphere Application Server (WSAS) to apply a fix pack upgrade produces the following message within the log.txt: The file lafiles/LA_cs could not be replaced.
Symptom
Customized Installation Packages (CIPs) are created using Installation Factory. A CIP is capable of installing WebSphere Application Server (WSAS) and updating it to a higher fix pack level in a single installation session. A CIP can also upgrade an existing WebSphere Application Server to a higher fix pack level.
The issue described below occurs when an existing instance of WebSphere Application Server is upgraded to a higher fix pack level with a CIP. (Or alternatively, the CIP may deliver a set of interim fixes to an existing WebSphere Application Server instance.) The particular issue discussed below does not occur if WebSphere Application Server is installed for the first time.
After attempting to apply an update to an existing WebSphere Application Server instance, you may notice these errors in the installation log.txt file. In this case, the log file would be located in WAS_HOME/logs/install.
msg1, Updating component: was.webcontainer.bundle, percent complete: 100%
msg1, Installing com.mycompany.WAS_7.0.0.17was.primary.pak
msg1, Initializing component: legal, percent complete: 0%
err, duplicate entry: repository/legal/lafiles/LA_cs
err, The file lafiles/LA_cs could not be replaced.
err, com.ibm.ws.install.ni.framework.NIFException: The file lafiles/LA_cs could not be replaced.
at com.ibm.ws.install.ni.ismp.mediaspanning.InstallNIFMaintenanceMediaSpanning.executeThisInstallPackage(InstallNIFMaintenanceMediaSpanning.java:270)
at com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance.performExecution(InstallNIFMaintenance.java:379)
at com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance.execute(InstallNIFMaintenance.java:77)
at com.installshield.wizard.RunnableWizardBeanContext.run(RunnableWizardBeanContext.java:21)
Caused by: com.ibm.ws.install.ni.framework.NIFException: The file lafiles/LA_cs could not be replaced.
at com.ibm.ws.install.ni.framework.install.NIFPackageApplicationPlugin.backupIfNecessary(NIFPackageApplicationPlugin.java:421)
at com.ibm.ws.install.ni.framework.install.NIFPackageApplicationPlugin.execute(NIFPackageApplicationPlugin.java:114)
Notice the "Updating component" message, followed by a message that states that a "was.primary.pak" component is being installed. The CIP's Package Identifier is affixed to the front of the "was.primary.pak" component name.
After those messages, the error occurs. The log states that a file in the "lafiles" subdirectory "could not be replaced", and the reason given is that there is a "duplicate entry" for that file.
Cause
When a Customized Installation Package (CIP) is created, you must assign a unique Package Identifier to that CIP. This is the name you use to identify this CIP, and this name is also used internally by the CIP installation software.
When an existing WebSphere Application Server product is updated with a CIP, the CIP's Package Identifier must be "universally unique". In other words, it must be different than the Package Identifiers of other CIPs which previously installed and updated this product. If the Package Identifier of a new CIP is not unique, then the new CIP's Package Identifier will conflict with a previously-used Package Identifier. This causes the "duplicate entry" error seen in the logs.
In this example, the error message shows that the new CIP's Package Identifier is "com.mycompany.WAS_7.0.0.17". The issue is that the Pacakge Identifer "com.mycompany.WAS_7.0.0.17" was already used by the CIP that had previously updated this copy of WebSphere Application Server.
Resolving The Problem
Build a new CIP (and all future CIPs) using unique Package Identifiers. Just add an increment to the version number, or use a build number or build date as part of that version identifier. For example, you can use new CIP Package Identifiers like these:
| If the original Package Identifier was this: | Then the next Package Identifier could be this: |
| 7.0.0.17a | 7.0.0.17b |
| 7.1.0.17_1234 | 7.1.0.17_2345 |
| 7.1.0.17_2011-10-26 | 7.1.0.17_2011-11-09 |
After building a new CIP with a unique Package Identifier, you can then install it on the existing WebSphere Application Server product. The CIP software will note that the previous installation operation failed, and it will automatically clean up the failure before proceeding to apply updates to the existing product.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21570397