Red Hat Updates fail to install with Error Codes

Products

Patch Management Solution for Linux Patch Management Solution for Windows

Issue/Introduction

Red Hat Clients run the Software Update Cycle and return the following:

Installing Software Update Bulletin 'RHSA-2015:2504'...
Progress: [###################################] 100%
Finished. Installation failed with error code 3.
Reason: Unknown. Examine the installation log for more details.

warning: /opt/altiris/notification/swuagent/var/packages/{F5A765AC-F19E-A123-C2EB-5BC350888D5C}/chkconfig-1.3.49.3-5.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
error: Failed dependencies:
chkconfig = 1.3.49.3-2.el6 is needed by (installed) ntsysv-1.3.49.3-2.el6.x86_64

RunJobByID: Job {GUID.EN_US}, command completed with the message: Command finished with error code: (3) No such process

Environment

ITMS 8.x

Patch Management 8.x

Cause

The Client has missing dependencies for the Software Update to be applied. These dependencies are not provided by Patch Management for they could be conflicting to software already installed on the client so this will need to be managed by the Administrator.

Additionally, the Linux Admin may be maintaining a lower version of software as there are environmental dependencies that require the lower version remain intact.

One additional cause may be in the Channels section of the Red Hat MetaData Import Task if all options are are not checked.

Resolution

For the channels selected in the MetaData Import task, in one case where only Red Hat Enterprise Linux 9.2 was installed, selecting only the Red Hat Enterprise Linux (v.9 for 64 -bit) resulted in many such failures. Selecting all version 7, 8, and 9 options resolved that issue. Further testing was not done to narrow down this list, but one option is to add one at a time and test.

Patch Management Solution is working as designed, for the Red Hat Clients are not at current level to be updated from the vendor and apply the current Software Updates.

Utilize the following on the client to view what dependencies are required:

rpm -q --requires (list package requirements)
rpm -q --provides (list package provisions)

Note: Most Fedora systems use YUM, which makes use of the rpm API to resolve dependencies; however, DNF may also be utilized, for both of these tools have a robust dependency resolver build in.

Additional process for resolving dependencies:

Review the Client Logs to pull the missing dependencies as outlined in the 'Error Message' section above.
Run the following CMD on the Red Hat Client to isolate the missing dependency: yum whatprovides */chkconfig
Utilize Software Management Solution (SMS) to deploy these missing dependency packages.
- Caution: SMS can distribute any software package that can be executed via a command line, and one of the main concerns is the possibility that the software could be executed regardless of whether or not it is applicable. Additionally, if the software install requires a reboot it could cause issues with the management task losing track of the state of the task when the reboot takes place and that could result in a returned failed/incomplete status, so SMS will need to be used with extreme care that the targeted dependencies are being resolved as desired by the Linux Administrator.

Lastly, if there are multiple updates that the above process would be too time consuming; review the following:

Note all software types from the warnings in the Client Logs (Search on: dependencies).
Go to https://pkgs.org/ (particularly the 'Fedora' sections as they are the best of the listings) to obtain the packages needed for each software dependency.
Utilize Software Delivery Solution to deploy these missing dependency packages.

Note: It may be possible to script a job to utilize Yum to auto-update the clients, installing all dependencies, and that could put the client in a supported state for Patch Management to be able to deploy the Software Updates. A couple examples; this script could be as simple as Example #1 Advisory: Yum updating may also be custom scripted to update individual dependencies.

Caution: This process would be best practice on a test client to ensure there are not conflicts, and once confirmed in order, deploy that to the managed Red Hat Clients.

Advisory: The Software Update Policy can be slimmed down, to hold updates from the released month or even single Bulletins per policy, and that will help to ensure the targeting updates that do not have dependencies can install without failures, and work through the solution listed above to bring those dependencies up to a supported level.