IBM Endpoint Manager, Version 9.2

Troubleshooting

When problems occur, you can determine what went wrong by viewing messages in the appropriate log files that provide information about how to correct errors.

Log files

The following log files can be found in the client folder in the directory /var/opt/BESClient/EDRDeployData.
EDR_DeploymentResults.txt
Lists the results of the EDR deployment and the Zypper output. The log file indicates if the normal Zypper process is used for either a standard repository or SMT.
register-repo.log
Lists the results of the repository registration action of the SLE Custom Repository Management dashboard.
register-SMT.log
Lists the results of the SMT registration action of the SLE Custom Repository Management dashboard.
unregister-repo.log
Lists the results of the unregister repository action of the SLE Custom Repository Management dashboard.
unregister-SMT.log
Lists the results of the unregister SMT action of the SLE Custom Repository Management dashboard.
snapper_rollback.log
Lists Btrfs snapshot rollback feature that is available from the SLE Btrfs Snapshot Management dashboard.
pkg_upgrade_output.txt
Lists the results of the Check Available Package updates - Solaris 11 task.

Understanding dependency failures

Some dependency requirements cannot be determined by Fixlet relevance. In some cases, multiple levels of dependencies or conflicting third-party packages can prevent the installation of a Fixlet content.

You can manually review these details by using the EDR_DeploymentResults.txt file, which is written locally on an endpoint in the client folder by the EDR Plug-in. You can also review the analysis Endpoint Dependency Resolution - Deployment Results (ID# 14) in the Linux RPM Patching site.

The EDR_DeploymentResults.txt file is a text file that contains several lines for each Fixlet that runs on the system. Each line contains a date or time stamp and the associated Fixlet ID number. The log shows the type and status of the installation, whether or not it was a test run and if it was successful or failed.

If the deployment was successful, the log lists out the packages that were successfully installed or upgraded during the action.

If the deployment failed, the log shows the error output from the EDR Plug-in.

Common <type> tag errors found in the EDR_DeploymentResults.txt file

The most common <type> tag errors that are found in the EDR_DeploymentResults.txt file are as follows:

No solution (noSolution)
This error means that the requested target packages cannot be installed on the system, because there are conflicts between the target packages and the existing packages on the system.
Incomplete baseline (incompleteBaseline)
This error might appear if third-party packages are fulfilling dependencies and are not recognized by the resolver.

If the <type>incompleteBaseline</type> tag is found in the EDR_DeploymentResults.txt file and <name>name of RPM</name> tag is NOT in the /var/opt/BESClient/EDR_UnsupportedPackages.txt file, then you must install the RPM separately.

However, if the RPM is in the EDR_DeploymentResults.txt file, you must downgrade to a version that is supported. You can use the <sanityCheckError> tag from the EDR_DeploymentResults.txt file to identify what version of RPM is supported. You can only proceed with patching the system when the supported RPM version is installed.

Forbidden package list error (packageInForbiddenList)
This error is caused by a package on the target, which is listed in the forbidden package list. You must remove the package from the forbidden package list to successfully run the Fixlet.
Empty solution (EmptySolution)
This error means that the resolver cannot find a solution with the given set of information. For example, the packages that are installed on the system or the packages that it is trying to install. To resolve this error, it is often better to have the system as standard as possible. Installing additional third-party software and removing packages from the base operating system can make this more difficult for the resolver to resolve all dependencies. It is suggested to move toward using the Native Tools site instead.

Bash script error

If you get an error similar to the following error message: 
Hard failure exit code 'execute prefetch plug-in' "/bin/bash" 
"{parameter "sitefolder"}/ResolveDependencies.sh" …...." 
(action 159317) Exited with exit code of 2
You must complete the following steps:
  1. Open the mentioned bash script and add the following after line 2 of the script:
    set -x
logpath=</path/of/your/choice>
exec >$logpath 2>&1
  2. Deploy the action immediately after you update the script.
    Note: The client might override the file, so do not to wait too long between updating the script and deploying the action.
This procedure creates the file that is mentioned in the log path, with a line-by-line detailed output for the script.

Issues when the custom repository is not a mirror of the vendor

When you use a custom repository that is not a mirror of the vendor site, it is possible that the default gpgcheck is being done as part of the installation. The GPG signature files might not be included in the repository. The files are not checked for authenticity and might cause the installation to fail.

To resolve this issue, ensure that when you register the endpoints in the SLE Custom Repository Management dashboard, you add gpgcheck=0 to Additional Fields.

Mirror server is not working

To check whether the issue is due to an incorrect URL or mirror server credentials, check the plugin.ini file in the directory<BES Server directory>/DownloadPlugins/SuseProtocol.

Novell account lockout

One possible reason for an account lock out is due to invalid credentials.

Ensure that you use the mirror server configuration from Novell when you register or configure the download plug-in. Account lockouts are common but temporary. Contact Novell Support if you get locked out of your account.

Error deploying Fixlets from custom sites

The Fixlet site name is hardcoded in the relevance of the Fixlets because the relevance can only accept one value. When you deploy Fixlets from a custom site, the Fixlets would fail because they are still referencing to the original Fixlet site. To resolve this issue, ensure that your endpoints are subscribed to the original Fixlet site so that they can grab all the relevant site files.

If you do not want to stay subscribed to the original Fixlet site, but be able to deploy custom Fixlets successfully, do the following steps:
  1. Make a custom copy of the necessary site files.
  2. Host the site files either in your own custom site or online.
  3. Modify the custom Fixlet appropriately.

Package installation using a custom repository failed

If you get the error message: Install Failure: zypper -n install - Error:

Consider the following steps to troubleshoot the issue:
  1. Ensure that the custom repository is enabled. To check, the Disable custom repository support - SUSE Linux Enterprise task (ID#16) in the Patching Support site must be relevant to the endpoint.
  2. The endpoint must has the required repositories. To check, run zypper repos.
  3. Ensure that the latest site is gathered.
  4. Run a Fixlet from a site and collect the following logs when the action is completed:
    • The Client log is located at /var/opt/BESClient/__BESData/__Global/Logs.
    • The EDR_DeploymentResults.txt log is located at /var/opt/BESClient/EDRDeployData.
  5. If the EDR_DeploymentResults.txt log file shows that the zypper command interprets each string after InstallPackages.sh -f as a package to install, check whether the bc package is installed on the endpoint. To check, run any of the following commands: 
    which bc
    or
    rpm -q bc

Feedback