Part Two - Common SUM Issues. FAQ, Troubleshooting and Solutions.
This is part two of a SUM article series:
SUM Part One
Following article covers frequently asked questions about Software AG Update Manager (SUM). Such as related to network, connectivity, proxies and other configurations and troubleshooting.
Why I cannot see my Fix for installation?
There are many different reasons why a Fix is not listed in a Fix tree:
- You cannot see a concrete version of a Fix because it is not the latest one. In a tree, only the latest version of a Fix is listed.
If you want to see an older version you should start SUM with the following parameter:
-showAll true
- A Fix has in its MANIFEST different requirements. E.g. for wMFix.NATBase.SOL_9.1.3.0007-0019:
Manifest-Version: 1.0
Display-Fix-Name: Base Environment 9.1 SP3 Fix 7
Require-Fix: wMFix.NATBaseJar.ALLUX;version=9.1.3.0007
Release-Date: 07/03/2022
Require-Product: wMProduct.NATBase;version=9.1.3
Empower-Fix-Id: NAT_9.1_SP3_Fix7
Display-Group-Name: Natural Products.Natural
Fix-Name: wMFix.NATBase.SOL
Require-Platform: SOL
Fix-Version: 9.1.3.0007-0019
Require-SUM-Build: 11.0.0.0001-0221
Require-Product-Codes: NAT
As a result, you need to have the Require-Product installed in order to see the fix - Require-Product: wMProduct.NATBase;version=9.1.3
The product should match the version too, e.g. 9.1.3
Another filter for Fix listing is Require-Platform. You should be on the Platform required. e.g. Require-Platform: SOL
-
The User used should have the licenses needed for the products in order to be able to install their the corresponding fixes.
-
The Fix may have EM (i.e. Extended Maintenance) set. In this case, the User should have paid for EM in order to be able to see the Fix.
This is marked in Fix’s MANIFEST file with the following attribute:
EM-Phase: true
- If you create an image you should set the proper Platform to be used (e.g. SOL) that matches the Fix to be added in the image.
Also, there are two major options. To base the image after a “Product directory” (limits the Fixes to the ones applicable to a given Product) or see “All licensed” (shows all Fixes
a user has access to not considering a concrete Product).
Not able to install the latest fix even if the Fix was listed for installation and SUM shows it? “Checksum failed” issues.
If there was a previous attempt to install a fix with SUM then it was already stored/cached under the following location:
<UpdateManager Directory>\profile\p2\org.eclipse.equinox.p2.core\cache
As a result, SUN uses the same location to first lookup for the fix.
Usually, if there are any issues with the fix installation after the first attempt it is possible to have a broken local copy of the fix. E.g. you may have seen the following in the log files:
Checksum failed for [wMFix.integrationServer.Core/10.11.0.0006-0007](http://wmfix.integrationserver.core/10.11.0.0006-0007):
expected=dfcf6671796351bcfed1a1466753d1ee1ff1a0df4c316b286e7382175750a040
actual=adb93c26580eff07b55f5277d1bdb2c21f147acbe07fe42f9ca3d273aff84766
If present you should delete the ‘cache’ and try installing the fix again.
The reasons could be a network glitch or Antivirus program, as a result the Fix was not downloaded/stored properly.
This is the command to execute in order to clear the cache:
UpdateManagerCMD.bat -clearCache true -installDir <installDirWhereToClearTheCache> <installDirWhereToClearTheCache> - the directory of the Installation
I see in the SUM logs this error Error while loading manipulator ?
It is possible that there were manual interactions with the SUM installation. For E.g. SUM installation was moved or copied from one to another directory, separate folders/files were manually modified/copied/deleted, etc.
This is absolutely not allowed AS IT ruins the SUM installation metadata integrity!
Usually, the message in the log is:
SAG product directory was moved, copied from one to another directory’ occurs after 'Initializing connection with repository.
In this case you should collect SUM logs and an archive from the following directories:
<SAG-Products-Dir>\install\products and <SAG-Products-Dir>\install\fix\profile\org.eclipse.equinox.p2.engine\profileRegistry
When you open
<SAG-Products-Dir>\install\fix\profile\org.eclipse.equinox.p2.engine\profileRegistry\self.profile\<LATEST_TIMESTAMP>.profile.gz (e.g. 1610992634406.profile.gz) you can see the install directory used originally. E.g.:
<property name='webm_install_dir' value='/opt/dev/sag_10.5'/>
Then you should compare this value with the PATH logged in SUM debug.log. If you see a different path then there was a manual manipulation of an existing installation. E.g. :
PATH=/opt/sag_10.5
The following error is also a sign of such manipulation:
SUM_ERROR>Adding a profile with duplicate id: self.
is a sign of such manual manipulation.
You can check this by navigating to:
<SUM_HOME>\logs\tempOutput.log
If you read that there are loaded bundles, e.g. “Time to load bundles: 7”, or “Time to load bundles: X”, when X != 0 then the installation should be fine. E.g.:
Debug options:
file:/C:/SAGUpdateManager_V11_B79_27_02/bin/.options not found
Time to load bundles: 7
Starting application: 1584621759784
Unable to rename file: C:\SAGUpdateManager_V11_B79_27_02\UpdateManager\logs\info\info.log
Unable to rename file: C:\SAGUpdateManager_V11_B79_27_02\UpdateManager\logs\debug\debug.log
Software AG Update Manager Version:11.0.0.0008-0316
Connecting to empower for authentication...
Establishing SSL connection to empower...
Initializing connection with repository
Initializing connection with repository
Retrieving available fixes from repository
But if you read this "Time to load bundles: 0":
Debug options:
[file:/C:/Users/ichikawah85/Desktop/UpdateManager11/bin/.options](file:///C:/Users/ichikawah85/Desktop/UpdateManager11/bin/.options) not found
**Time to load bundles: 0**
Starting application: 1581931150709
Software AG Update Manager Version:11.0.0.0007-0320
Connecting to empower for authentication...
Establishing SSL connection to empower...
Initializing connection with repository
Updating SoftwareAG Update Manager
An error occurred while uninstalling
session context was:(profile=self, phase=org.eclipse.equinox.internal.p2.engine.phases.Uninstall, operand=[R]com.softwareag.fixinstall.actions 11.0.0.0007-0320 --> [R]com.softwareag.fixinstall.actions 11.0.0.0008-0316, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.UninstallBundleAction).
Error while loading manipulator.
Connecting to empower for authentication...
Establishing SSL connection to empower...
Initializing connection with repository
Retrieving available fixes from repository
You can see that it contains:
Time to load bundles: 0
This could mean that the SUM installation was moved or modified manually!
Then you should double-check with <SUM_HOME>\logs\tempOutput.log or <SUM_HOME>\UpdateManager\logs\debug for java.lang.IllegalStateException: Error while loading manipulator. error.
2020/01/28 11:31:21.712 CET: An error occurred while uninstalling
2020/01/28 11:31:21.712 CET: session context was:(profile=self, phase=org.eclipse.equinox.internal.p2.engine.phases.Uninstall, operand=
[R]com.softwareag.fixinstall.bpms 10.0.0.0062-4911 --> [R]com.softwareag.fixinstall.bpms 10.0.0.0071-5266, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.UninstallBundleAction).
2020/01/28 11:31:21.713 CET: Error while loading manipulator.
**java.lang.IllegalStateException: Error while loading manipulator.**
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.LazyManipulator.loadDelegate(LazyManipulator.java:59)
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.LazyManipulator.getConfigData(LazyManipulator.java:108)
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.UninstallBundleAction.uninstallBundle(UninstallBundleAction.java:74)
at org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.UninstallBundleAction.execute(UninstallBundleAction.java:32)
at org.eclipse.equinox.internal.p2.engine.ParameterizedProvisioningAction.execute(ParameterizedProvisioningAction.java:38)
at org.eclipse.equinox.internal.p2.engine.Phase.mainPerform(Phase.java:183)
at org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:95)
at org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:47)
at org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:75)
at org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:44)
at com.softwareag.fixinstall.core.SelfUpdateSession.updateSelfProfile(SelfUpdateSession.java:184)
at com.softwareag.fixinstall.app.AbstractFixApplication.updateSUM(AbstractFixApplication.java:1772)
at com.softwareag.fixinstall.cmdlineinstaller.pages.AutoSelfUpdatePage.render(AutoSelfUpdatePage.java:70)
at com.softwareag.fixinstall.cmdlineinstaller.CmdLineWizard.perform(CmdLineWizard.java:119)
at com.softwareag.fixinstall.cmdlineinstaller.CmdLineApp.start1(CmdLineApp.java:45)
at com.softwareag.fixinstall.cmdlineinstaller.Application.start(Application.java:30)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
If you see this “java.lang.IllegalStateException: Error while loading manipulator.” then you should reinstall your SUM.
SOLUTION:
You should reinstall your SUM as your installation has broken integrity due to manual modifications/copy/pastes etc.
Why -showAll parameter should be used only if RnD has suggested it for end users?
The -showAll option lets users see all fixes that are available, not only the latest.
As a rule of thumb, it is something that should be avoided. The best situation for users is to use up-to-date products with all the latest updates and bug fixes. Thus minimizing all the possible combinations of exotic setups. As a result improving the integrity and reliability of their environment.
The best is to stick to the latest versions, which are extensively tested in all test cycles (e.g. SPRO etc.). Using the “-showAll” option is a sign of an issue that should be targeted.
Why -overInstall parameter should be used only if RnD has suggested it for end users? What is the difference between overInstall and reinstall
-overInstall is a destructive action as it does not care about the dependency check.
The difference between Reinstall and Overinstall are:
Reinstall is a common operation that does not require any specific parameter as user input. The SUM detects all fixes that should patch the new profiles but will execute only needed actions. The users could recognize these fixes very easily, there is “(Reinstall)” after the fix display name.
The Overinstall is NOT for end users. It requires a SUM parameter to be provided and will uninstall and install selected fixes BUT information about which fixes need to be overinstalled must be provided by RnD depending on the SAG product installation as this can mess up the entire SAG product directory to unprevertable/unfixable state. The users could recognize these fixes very easily, there is “(Overinstall)” after the fix display name.
The “Reinstall” feature is specifically used when creating/deleting instances of IS, MWS or any product that allows for instance creation.
The purpose of this feature is to apply an installed fix to the newly created instances. Because, if not reinstalled, a fix can be installed inside an installation but not added to the newly created instance.
When SUM is started for installing fixes, it should automatically detect that there is a new instance created, and it will add the installed fix to the new instance.
Users need to be experienced to use this option, they might mess up a configuration or other stuff.
Why can’t I delete a specific fix from SUM backup?
Example: If they have installed IS 10.5 Core Fix 1, IS 10.5 Core Fix 2 and IS 10.5 Core Fix 3, they want to keep Fix 2 and Fix 3. However, they would like to delete IS 10.5 Core Fix 1. So, in effect they should be able to provide IS 10.5 Core Fix 1 as input, in order for the update manager to evaluate and delete IS 10.5 Core Fix 1. The current feature ‘delete backups’ available within the Update Manager allows to delete all fixes (all components) older than a period of time, for eg: 12 months. When the customer gives that criteria of 12 months, they do not know which fixes will be deleted.
Answer: When a user installs fixes during a SUM session, SUM calculates the dependencies, and all the inter-dependent fixes are installed together. Picture the set of inter-dependent fixes as a sort of fabric that holds together. The product teams test that inter-dependent set of fixes together and they cannot be separated. In 10.7 we’re adding a feature to revert entire sessions of SUM during which a fabric of fixes was installed - to kind of go back in time to an earlier state of the installation- and this feature is based on the backups being available, in their complete state of the fabric. The customer’s request would make that feature impossible to use, because unknown pieces of the fabric would be missing. It would break the integrity of the set of fixes that were installed together in a certain session.
What stays behind the current solution is that SUM preserves the integrity of the backups, thus preserving the integrity of the profiles associated with them. So, more or less, if we use an analogy from Git, you cannot just cherry-pick a Fix, because there are some dependencies between the fixes that should not be broken. Otherwise, the internal dependencies links are no more reliable. Additionally, based on these backups, we provide different restore/emergency functionalities our user will be able to benefit from. So, in short, you cannot remove just a single Fix from a backup as these backups are associated with the profiles and their integrity should not be broken.
What are the differences between Installer and Update Manager?
The difference between SUM and the installer is mostly in the possible combinations and actions you can do… this multiplies the possible user paths and test scenarios several times. The major differences are:
- the Installer does not have “optional” dependency between different machines or installation folders, with SUM fixes there is such possibility
- the installer is working only forward, e.g. if you have an over-install for product 1.1 you can install 1.2, but never go back (downgrade). With SUM we must support rolling back and forward any fixes.
- SUM is used much more frequently than the Installer. The customers are mostly installing once, but deploying fixes on top (+ back / forward) much more often… for some versions IS is having 25+ fixes, so 1 installation, 25 fixes deployments
- a lot more people are making fixes / writing custom actions in comparison to the one that are making installations with the Installer. More people in the game, more fixes → more complexity
- It’s hard to write composite templates for CC. In addition, not all products are on CC, and those that are on CC are not consistently implemented – some have some configs, some have others, nothing is 100%, teams don’t have time. Nobody seems to like SPM. Troubleshooting is quite difficult. These and other issues are hindering adoption.
- Customers love the Installer and SUM as they are easy to use and very reliable.
- SUM size is ~300MB, Installer is ~100MB
#Integration-Server-and-ESB#webMethods#Update-Manager#SUM