Special issues for patch management

The following topics present special issues and limitations that exist while creating a patch catalog or running a patching job. Most issues are caused due to specific third-party patches, and have been classified based on the target that it is deployed on:

Tip

See Troubleshooting Patch Management issues for additional issues.


Patch management issue for version 8.7 agents

The following OS versions are supported as patching targets, only if the target system has an 8.7 P4 agent version installed on it.

  • RedHat Enterprise Linux version 5 (and earlier)
  • Oracle Enterprise Linux version 5 (and earlier)
  • SuSE version 10 (and earlier)

For targets on any of these platforms, do one of the following:

  • Update the version 8.8 agents with the component template fix available from Knowledge Article 000120867.
  • Use an earlier version of the agent (for example, version 8.6).

Issues while patching on Red Hat Enterprise Linux

The following issue exists while patching on Red Hat Enterprise Linux:

  • You maybe unable to install or update the open-vm-tools-deploypkg (from the VMware repository) on a RHEL7 target due to a known issue with this patch. See https://access.redhat.com/solutions/1449563, for more information about this known issue.
    Workaround: You can try excluding the all open-vm-tool patches during the patch analysis job or removing open-vm-tools-deploypkg from the target server.
  • Run the ldconfig command on your RHEL 7 target, if you encounter the following type of error during patch analysis:
    Error 03/07/2017 12:22:25 STDERR: There was a problem importing one of the Python modulesrequired to run yum. The error leading to this problem was:   libcurl.so.4: cannot open shared object file: No such file or directoryPlease install a package which provides this module, orverify that the module is installed correctly.It's possible that the above module doesn't match thecurrent version of Python, which is:2.7.5 (default, Feb 11 2014, 07:46:25) [GCC 4.8.2 20140120 (Red Hat 4.8.2-13)]If you cannot solve this problem yourself, please go to the yum faq at:  http://yum.baseurl.org/wiki/Faq  ERROR::cmd: yum -c "./yum.conf"
  • We need to run the ldconfig  command on the machine (ldconfig is a command that is used to maintain the shared library cache. This cache is typically stored in the file /etc/ld.so.cache and is used by the system to map a shared library name to the location of the corresponding shared library file)

Issues while patching on SUSE Enterprise Linux

The following issues and limitations exist while patching on SUSE Enterprise Linux:


  • While updating a SUSE catalog with the SUSE 9-x86_64 filter, the count of the Downloaded patches displayed by BMC Server Automation may be incorrect. The count of RPMs that do not contain release version and osArch information do not appear in Downloaded count field, even though they are added to the catalog.
  • While creating a SuSE Linux Catalog, certain rpm files might cause the Catalog Update Job to fail, with the following message: "BLPAT1700 - RPM verification failed on selected repository location. Please use SuSE platform repository location and run the catalog.". This issue is due to SuSE Enterprise Linux limitations. For this Catalog Update Job, ensure that you specify a repository location on a SuSE Enterprise Linux host computer. 

Note

If this error occurs even when you are using a SuSE repository location, the issue might be caused due to zero byte rpms or corrupted rpms in the repository location. To resolve this issue, delete all zero byte size rpms and corrupted rpms from the repository location and update the catalog. Use the following commands on the SuSE repository server:
To list all the zero byte rpms

ls -s|grep -E "^ *0"

To delete all zero byte rpms

 ls -s|grep -E "^ *0"|sed "s/^ *0 //g"|xargs -i rm "{}"


  • While you are creating a SuSE Linux Catalog in the Online mode, the Catalog fails with an rpm-python dependency. The error message states rpm-python needed by createrepo-0.4.6-1.el4.rf.noarch. 

    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.

  • For SUSE Linux Enterprise version 10 SP1, hplip17-hpijs-1.7.2-0.15.x86_64.rpm and hplip-hpijs-0.9.7-19.9.x86_64.rpm packages obsolete each other during installation. If hplip17-hpijs-1.7.2-0.15.x86_64.rpm is installed, the hplip-hpijs-0.9.7-19.9.x86_64.rpm package is removed from the SUSE target and the other way around. Therefore, when one of these packages is installed, the other package is shown as missing on the next Patch Analysis Job run.

    Workaround: You must decide which of these files must exist on the SUSE target and mark the other file as excluded.


  • For SUSE Linux Enterprise version 10, the SP3 Pool catalog contains a lower version of the SPident-0.9-74.27.8.noarch.rpm file. If you perform an analysis on a SUSE Linux Enterprise version 10 SP3 target (for example, by using the Online mode catalog), the SPident-0.9-74.27.8.noarch.rpm is reported as missing. This issue occurs due to a conflict in the repositories provided by Novell and can be ignored. This issue will be resolved when Novell updates its repository with a newer version of the rpm.

  • For SUSE Linux Enterprise version 10 SP4, the Patch Analysis Job fails with an error message for the kernel-default rpm: STDERR: cat: rpm-includes.lst: No such file or directoryERROR::YUM dry run failedERROR::sysconfig conflicts with kernel-defaultERROR::cmd: failed! This issue occurs due to a conflict in the repositories provided by Novell and will be resolved when Novell updates its repository with a newer version of the kernel-default rpm.

    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

The following issues and limitations exist while patching on AIX:

  • For AIX, the Patch Analysis Job fails in the Install Mode because of missing filesets in the repository. A single repository will contain updates for all available packages. The Install Mode is intended to install new packages on the target. Hence, BMC recommends the use of Install Mode on selective packages, rather than using the Install Mode on the complete repository.
  • To cancel an AIX patch catalog job that is running with the SUMA download option, you must perform the following steps:

    1. Cancel the Catalog Update Job (CUJ) from the Console to stop the job running on the Application Server.

    2. Log on to the repository server and manually kill the SUMA download process.

  • 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 'idsldap.srv64bit62.rte 6.2.0.16' on some targets due to a problem in the third-party patch.

  • 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 'bos.rte.archive 5.3.0.51' is deployed on an AIX 5.3 target, the target goes into reboot mode and fails to restart.

  • 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 the broken fileset is an update, reinstall the update using options in the installation program that will apply, commit, and automatically install the required software without saving the replaced files (-acgN flags).
    • Reinstall the entire fileset at the base level with the desired updates by using the FORCE option (-F flag).

    If you are still unable to fix the fileset in the broken state, contact IBM support team for further assistance.

  • Error while extracting the offline downloader tar package, because of the length of file path input string.
    Workaround: BMC recommends using the GNU tar (gtar) utility to extract the offline downloader package.
  • You might encounter dependency errors while performing patch analysis on AIX 6.1 TL09 for security fixes. Before you run the analysis job, add AIX 6.1 TL08 to the catalog filter and run the catalog update job to add AIX 6.1 TL08 content to the catalog.

  • You cannot edit a patch catalog of a deprecated AIX platform version, even if the patch catalog was created in an earlier version of BMC Server Automation. For more information about which AIX platform versions are supported for patching, see the System requirements section.

Issues while patching on Oracle Solaris

The following issues and limitations exist while patching on Oracle Solaris:

  • Error while extracting the offline downloader tar package, because of length of file path input string.
    Workaround: BMC recommends using the GNU tar (gtar) utility to extract the offline downloader package. 

Issues while patching on Oracle Enterprise Linux

The following issues and limitations exist while patching on Oracle Enterprise Linux:

  • For Oracle Enterprise Linux, the Patch Analysis Job fails in the Install Mode because of missing rpms in the repository. A single repository will contain updates for all available packages. The Install Mode is intended to install new packages on the target. Hence, BMC recommends the use of Install Mode on selective packages, rather than using the Install Mode on the complete repository.

Issues while patching on Windows

The following issues and limitations exist while patching on Windows:

  • You may encounter errors if you try applying more than one patch or hotfix, on a Windows target, at the same time. To resolve this issue, BMC recommends applying only a single patch or a single hotfix at a time. Note that patches and hotfixes must be applied on Windows targets only if it is required to solve a specific issue. For best practices while applying patches and hotfixes, see MSDN - Best Practices for Applying Service Packs, Hotfixes and Security Patches.

  • Before you apply multiple hotfixes, you must check whether the hotfix changes are available in the latest released service pack. This is because, Shavlik recommends that it is better to apply the latest service pack instead of applying several hofixes on the server. For best practices while applying patches and hotfixes, see MSDN - Best Practices for Applying Service Packs, Hotfixes and Security Patches.

  • 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.

  • BMC Server Automation automatically creates the required pre-installation and post-installation environment on a Windows target server for patching Java installation files. However, BMC Server Automation does not decide whether to reboot the Windows target server.. The target must be rebooted after each version of Java installation patch is deployed on the target. You can specify this reboot option while creating a Deploy Job, see Deploy Job - Job Options for more information.

Was this page helpful? Yes No Submitting... Thank you

Comments