This topic contains troubleshooting information for patch management issues. The topic includes the following sections:
Related BMC Communities article
BMC Customers using Automation for Patching use cases depend on OS vendors for Patches and metadata. To view a document that tracks the service status of the different OS Vendors as known to BMC Support, see the following BMC Communities document:
The errors that you might encounter during a Windows patching task can be divided into the sections that follow.
The following table lists issues that you might encounter while running a Patch Catalog Job, and provides troubleshooting information and references to knowledge articles for these issues.
Note
For general information about monitoring the progress and viewing the results of a Patch Catalog Job, see Viewing progress and results of a Patch Catalog Job.
Issue | Troubleshooting information |
---|---|
Unable to download shavlik metadata
| The shavlik metadata may not be downloaded due to the following reasons:
For more information about this issue, you can refer to the Error occurred while downloading shavlik metadata knowledge article in the BMC knowledge base. Steps for debugging the shavlik downloaderTo enable DEBUG logging, add the following text to appserver.cf file: #Downloader debug log4j.logger.com.bladelogic.model.job.compliance.patch.ShavlikResult=DEBUG log4j.logger.com.bladelogic.app.util.DownloadServer=DEBUG |
Patch Catalog Update Job throws the following warning: No mappings were found for the selected product | Product Mappings are subject to change due to updates by Microsoft (and therefore Shavlik). If the updates occur before BMC Server Automation has shipped updates in the product, you can use a Windows Filter Configuration File to update the mappings used by BMC Server Automation.
Note If the No mappings were found for the selected product message persists, the Windows Filter Configuration File needs further update. If you need assistance, contact BMC Customer Support.For the latest information on this issue, see the BMC Server Automation Knowledge Article ID: KA419955. |
ACL issues: Windows Helper Server cannot be reached or access is not authorized | For information about creating an ACL template or ACL policy and controlling server access with agent ACLs, see Managing access. |
Patch object cannot be added or updated due to an RBAC issue | To create Patching Jobs and deploy patches, the patch administrator must be assigned a role that includes the necessary RBAC permissions. For more information, see Minimum permissions for patching. |
Windows Hotfix Patch is not found in the Catalog | For steps on troubleshooting this issue, see Windows Hotfix Patch not found in the Catalog. |
Catalog update job fails because of PD5.cab, or HF7b.cab configuration files. | If you have upgraded to BMC Server Automation 86 or later, you may still be using the PD5.cab, or HF7b.cab configuration files for Windows patching. However, BMC Server Automation 8.6 and later versions do not support the PD5.cab, or HF7b.cab configuration files, and you must use the PD5.xml, or HF7b.xml files instead. The Windows catalog update job fails if you use the .cab configuration files. To update the configuration files used for Windows patching see, Global configuration parameters. |
The following table lists issues that you might encounter while running the Patching Job and the Remediation Job, and provides troubleshooting information and references to knowledge articles for these issues.
Note
The Trace.txt log file and the results.xml file are generated by the Windows Patch Analysis Job or by live browsing Hotfixes .The information in these logs can be used to troubleshoot errors. For more information about analyzing the Trace.txt, see How to analyze Trace.txt generated by a Windows Patch Analysis Job.
Issue | Troubleshooting information |
---|---|
Shavlik metadata was not copied to the target | You can refer to the following articles in the BMC knowledge base for steps on troubleshooting this issue:
If your issue is still not resolved, file a ticket with BMC Support and provide the information from the following logs:
Turning on debug tracing for cl5.exeTo validate the payload, the shavlik engine runs the cl5.exe tool on the target. If this tool is not working properly, you can turn on tracing, using the following command: CL5.exe 2097197 1 <Log Directory> The customary value for maximum log size is 5000000. This command writes some values to the registry. To turn off CL5 tracing, use the following command: CL5.exe 2097197 0 |
One of the BLPatchCheck2 phases did not complete successfully | You can refer to the following articles in the knowledge base for steps on troubleshooting this issue:
If your issue is still not resolved, file a ticket with BMC Support and provide the information from the following logs:
|
Results are not passed back to the Application Server | You can refer to the following articles in the knowledge base for steps on troubleshooting this issue:
If your issue is still not resolved, file a ticket with BMC Support and provide the information from the following logs:
|
Analysis reported unexpected patch as missing | For information about troubleshooting this case, see Windows Patch Analysis Job reports an unexpected patch as missing. You can also refer to the following articles in the BMC knowledge base:
|
Analysis did not report expected patch as missing | For information about troubleshooting this case, see Windows Patch Analysis Job does not report an expected missing patch. You can also refer to the following articles in the BMC knowledge base:
|
BMC Server Automation analysis does not match with other third-party patch solutions | For more information about troubleshooting this case, see Analyzing differences between Windows Patch Analysis Job results and third-party vendors. You can also refer to the following articles in the BMC knowledge base: |
When troubleshooting Yum-based Linux patching it is import to know how the process works in order to narrow down problems. At a very high level the catalog (repo) metadata is copied from the repo location to the target server(s), a custom yum.conf is generated on the target(s) and yum is called using that configuration file (instead of the system's default), analysis is performed and then the analysis results are processed and fed back to the BladeLogic application server. For RHEL 7 targets, the OS's yum binary is used and for all other rpm-based platforms a custom 'blyum' that is part of the RSCD install is used instead.
The following table discusses issues that you might encounter when performing Linux patching.
Issue | Troubleshooting information |
---|---|
Yum failed to execute | Scenario 1: STDERR: cat: rpm-includes.lst: No such file or directory ERROR::YUM dry run failed. ERROR::cmd: failed! For more information, see Yum failed to execute - Scenario 1. |
Scenario 2: Could not find repodata.tar.gz corresponding to OsArch: ‘[ARCH]' in the catalog ( at location '//<repo>/catalog_XXX/[ARCH]/repodata.tar.gz'). For more information, see Yum failed to execute - Scenario 2. | |
Yum failed to complete | Scenario 1: For more information, see Yum failed to complete - Scenario 1. |
Scenario 2: For more information, see Yum failed to complete - Scenario 2. | |
Scenario 3: For more information, see Yum failed to complete - Scenario 3. | |
Deploy Job failed
| Scenario 1: [rpm-version.arch]: Caching enabled but no local cache of //<staging>/blrepos/repo/packages/[rpm-version.arch].rpm from repo. For more information, see Deploy Job failed - Scenario 1. |
Scenario 2: For more information, see Deploy Job failed - Scenario 2. |
The following scenario describes the No such file or directory
error that you might encounter when the yum file fails to execute, as well as steps to troubleshoot the issue.
Error Message | STDERR: cat: rpm-includes.lst: No such file or directory ERROR::YUM dry run failed. ERROR::cmd: failed! |
Description | The error messages suggest that either blyum is not found on the target or it is found but some libraries that are needed to run blyum were missing. |
Troubleshooting | To fix this error or research further, review the analysis_err.log error log file in the staging directory. This error is usually encountered when the supported agent version or architecture is not installed. So, to troubleshoot this issue, validate that the supported agent version or architecture is installed. |
Logs to collect | Log files to collect from the application server:
Log files to collect from the target:
|
The following scenario describes an error in the execution of the yum file, as well as steps to troubleshoot the issue.
Error Message |
|
Description | This error message indicates that the Catalog Job did not succeed at a target where the repodata.tar.gz file was not generated. As a result, the Analysis Job was run against an invalid target whose OS level or architecture did not match. This problem might be caused by an issue on the Repo Server. |
Troubleshooting | To fix this error, perform the following:
|
Logs to collect |
From the target
From the Repo server
|
The following scenario describes an error where the yum file fails to complete, as well as steps to troubleshoot the issue.
Error Message |
|
Description | Both rpm1 of the specified version and rpm2 are installed on the target. A newer version of rpm1 is found in the Catalog and set to be updated. The installed version of rpm1 is also a dependency to rpm2. To approve the installation of a newer rpm1, yum also needs to update rpm2. However, yum cannot find a newer version of rpm2 in repodata.tar.gz, so rpm2 is excluded from analysis. As a new version of rpm2 is not found, the rpm is not offered an update. Because rpm2 is not updated, yum cannot allow the update of rpm1. An error is logged, alerting that rpm1 needs to remain installed to preserve the dependency of rpm2. |
Troubleshooting | To troubleshoot this error, follow these steps:
|
Logs to collect | Log files to collect from the application server Patch Analysis Job log Log files to collect from the target analysis bundle.log (including repodata.tar.gz) |
The following scenario describes an error where the yum file fails to complete, as well as steps to troubleshoot the issue.
Error Message |
|
Description | Neither rpm1 of the specified version nor rpm2 are installed on the target. Yum sets rpm2 to be updated for one of two reasons:
Yum checks if rpm2 needs any dependencies of its own, and detects that rpm1 of the specified version is needed as a dependency. Therefore, yum attempts to set rpm1 to be updated as well, but fails. An error is logged, alerting that rpm1 is required for rpm2 to be installed. |
Troubleshooting | To troubleshoot this error, follow these steps:
|
Logs to collect | Log files to collect from the application server Patch Analysis Job log Log files to collect from the target
|
The following scenario describes an error where the yum file fails to complete, as well as steps to troubleshoot the issue.
Error Message | [rpm1] conflicts with [rpm2] |
Description | Rpm2 is installed on the target, while rpm1 is not. Yum attempts to offer rpm1 to be installed or updated, but then yum detects that some of the files to be updated by rpm1 are used by rpm2. Therefore, yum rejects the installation or update of rpm1. An error is logged, alerting that rpm1 cannot be installed. In general, the conflict suggests that rpm1 and rpm2 cannot coexist if rpm versions matter. |
Troubleshooting |
|
Logs to collect | Log files to collect from the application server Patch Analysis Job log Log files to collect from the target
|
Error Message | [rpm-version.arch]: Caching enabled but no local cache of //<staging>/blrepos/repo/packages/[rpm-version.arch].rpm from repo |
Description | Prior to installing the packages, the Deploy Job runs a preliminary yum analysis. During this analysis scan, rpm-version.arch is found as missing. The Deploy Job does not find rpm-version.arch in the list of staged missing patches, and, therefore, the job cannot proceed. An error is logged, alerting you that the patch payload is not found and cannot be installed. This error indicates that a discrepancy was found between the regular Patch Analysis and the preliminary yum scan during Deploy, or that rpm-version.arch was not copied during staging. The error message is written in either the Deploy Job log or the bldeploy log. |
Troubleshooting |
|
Error Message | package [rpm-version] is already installed |
Description | The Deploy Job installs the patches that were found missing during Analysis. In this case, the Analysis Job packaged the rpm-version, even though it is already installed. |
Troubleshooting |
|
Logs to collect | Log files to collect from the application server
Log files to collect from the target
|
The following issues and limitations exist while patching on SUSE Enterprise Linux: The following issues and limitations exist while patching on AIX: After you create and execute an online AIX patch catalog job with the SUMA download option enabled, you cannot cancel the patch catalog job.The SUMA process continues to run in the repository even after you cancel the job. AIX remediation job fails to deploy 'rsct.lapi.rte 3.1.6.0' on some targets due to a problem in the third-party patch. For more information about this issue, see the following third-party resource: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ80922. AIX remediation job fails to deploy 'rsct.lapi.bsr.bsrpd.odmdel' (rsct.lapi.bsr 3.1.5.0) on some targets due to a problem in the third-party patch. For more information about this issue, see the following third-party resource: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ80922. After deploying AIX 6.1 TL9SP1 on a target, the 'bos.rte.install 6.1.9.1' fileset enters a broken state if you try to Undo the deploy job. This 'bos.rte.install 6.1.9.1' fileset enters a broken state even if you reject the fileset manually. Workaround: To fix the 'bos.rte.install 6.1.9.1' fileset in the broken state you can take the following corrective actions: If you are still unable to fix the fileset in the broken state, contact IBM support team for further assistance. The following issues and limitations exist while patching on Oracle Solaris: The following issues and limitations exist while patching on Oracle Enterprise Linux: The following issues and limitations exist while patching on Windows: If patch KB2810009 is found missing during patch analysis, BMC recommends that you first separately deploy patch KB2810009 and then re-run the remediation job for the other missing patches. This KB2810009 missing patch needs to be deployed separately because of dependency issues. Issues while patching on SUSE Enterprise Linux
Workaround: For this Catalog Update Job, ensure that you specify a repository location on a SuSE Enterprise Linux host computer.
Workaround: You must check the version of create-repo and python-urlgrabber in the repository server and either ensure that the lower versions are installed or remove the higher versions, if they exist. In addition, you must ensure that rpm-python exists on the system and the version of rpm-python is compatible with the create-repo version that is shipped with the product.
Workaround: You must decide which of these files must exist on the SUSE target and mark the other file as excluded.
Workaround: If you encounter this package conflict, you must exclude the conflicting kernel-default rpm by using the include/exclude functionality in the Patching Job.Issues while patching on AIX
Workaround: BMC recommends using the GNU tar (gtar) utility to extract the offline downloader package. Issues while patching on Oracle Solaris
Workaround: BMC recommends using the GNU tar (gtar) utility to extract the offline downloader package. Issues while patching on Oracle Enterprise Linux
Issues while patching on Windows
1 Comment
Matin Shaikh