Page tree

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.

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

    Workaround: For this Catalog Update Job, ensure that you specify a repository location on a SuSE Enterprise Linux host computer.
     
  • 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:

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

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.