Frequently asked questions

The questions and answers in the section can help you to better understand Patch for Red Hat Enterprise Linux.

The Manage Download Plug-ins dashboard is not reflecting any data. What do I do?
Here are some steps you can do to troubleshoot the issue:
  • Gather the latest Patching Support site.
  • Activate the Download Plug-in Versions analysis, available from the Patching Support site.
  • Clear the BigFix console cache.
What are superseded patches?
Superseded Fixlets are Fixlets that contain outdated packages. If a Fixlet is superseded, then a newer Fixlet exists with newer versions of the packages. The newer Fixlet ID can be found in the description of the superseded Fixlet.
Where are the deployment logs located in the endpoints?

The logs are in the EDRDeployData folder, under the client folder: /var/opt/BESClient/EDRDeployData.

Endpoint Dependency Resolution - Deployment Results in the Linux RPM Patching site can be used to view the deployment logs on the BigFix Console.

If the latest plug-ins are registered, why do downloads still fail?
Patch number 8.0.627 has a known issue of not recognizing the whitelist for dynamic downloads. Upgrade to the latest version of BigFix to resolve the issue. You can also add the following lines in the download whitelist on your server:
  • RHSMProtocol://.*
What needs to be done when the action reports back with EDR Plug-in failure, Invalid set of initially installed packages?
There is at least one conflict between the packages that exist on the system. The resolver does not work until the conflicting packages are removed.
Why is there XML in the deployment results?
The XML is from the error output of the resolver when the resolver fails to produce a solution. You can look at the description in the 'errorType' tag to gain a better understanding of why the failure occurred.
What must be done when the deployment results display a 'Dependency Resolver Failure, noSolution"?'
If the resolver finds that there is no solution, the system cannot install all targets and dependencies. This is caused by a conflict between these files and the endpoint files.
How often are new dependency graphs generated?
Dependency graphs are generated every Monday, Wednesday, and Friday.
What steps must be taken when an action reports back with an installation failure?
Check to see whether the conflict is caused by a vendor-acquired package. These packages must be removed for the installation to occur.
Why does the resolver function select a lower priority package over a higher priority one?
The resolver does not select a preferred package when selecting that package creates a conflict with another package. Therefore, it is possible for a lower priority package to be selected.
What are the dependency issues in RHEL 3 and 4, and how do they affect the deployment?
See the Dependency Issues section of this document.
How do I verify that the download plug-in was registered correctly?
Run a Fixlet with an action task to verify that the download plug-in is registered correctly. Verify that the patch download is successful. Otherwise, you might need to unregister the download plug-in and register it again.
How do I register a download plug-in? Do I use the register download plug-in task or the Manage Download Plug-in dashboard?
To register a download plug-in, you must use the Manage Download Plug-in dashboard in the Patching Support site. Existing register download plug-in tasks are being deprecated. To learn more about plug-in registration, see Registering the RHSM download plug-in.
Note: You must also use the Manage Download Plug-in dashboard to unregister, configure, and upgrade download plug-ins. The existing unregister and edit download plug-in tasks are being deprecated. For more information about the dashboard, see the topic on Manage Download Plug-ins dashboard in the BigFix Information Center.
The password should be obfuscated, but is still in clear text. Why is that?
If your download plug-in version is earlier than 2.1, you are still using an old version of the download plug-in that stores credentials in clear text. To encrypt credentials, upgrade your download plug-in to version 2.1 or later from the Manage Download plug-ins dashboard in the Patching Support site.
Which version of the YUM native tools must be used?
The Patches for RHEL native tools site requires version 3.2.19-18 or later.
An action failed and the logs contain YUM-specific errors. How do I troubleshoot the failed action?
For more information about YUM and errors that are related to it, see the YUM documentation at and the YUM-related articles in the Red Hat Customer Portal.
What version of YUM is required to use the RHEL Custom Repository dashboard?
You must have a minimum YUM version of 3.2.19-18.
Which Red Hat Enterprise Linux is supported by the RHEL custom repository dashboard?
The dashboard supports Red Hat Enterprise Linux versions 5 and 6.
Which version of the BigFix server supports the RHEL Custom Repository dashboard?
The RHEL Custom Repository dashboard supports version 8.2 and later of BigFix.
When deploying patches, should I use the existing method or go through the custom repository? Can the two methods co-exist?
The two methods can exist together. However, when deploying patches for single clients, you must choose between using the native tools or through the custom repository method.
How are dependencies resolved the RHEL Custom Repository dashboard is used?
YUM uses the metadata to resolve the dependencies to know which packages are needed.
Can the custom repositories be used for software installation?
Yes, you use custom repositories for software installation. To use custom repositories for software installation, follow these steps:
  1. Ensure that the clients are registered through the Custom Repository dashboard.
  2. Create a Fixlet in the custom site with the actionyum install<space><package name>. Ensure that you set the correct relevance or success criteria, that is, whether the Fixlet takes action against that client or endpoint. To learn more about creating Fixlets, see the Console Operator's Guide.
Note: It is important to ensure that the repositories and satellites are updated. Actions can fail if the packages are not available.

For satellites: The dashboard only helps to run bootstrap scripts and the rhnreg_ks command to subscribe the endpoints to satellite servers. The channels that the endpoints use must be configured through the satellite servers.

While registering a repository, I was prompted to enter an activation key. Where can access this activation key?
Red Hat Network Satellite administrators create and manage these activation keys. For more information about activation keys, see
Can previously configured repositories be configured again?
Yes, you can configure again a previously configured repository.
From the logs, can I tell if I am using the normal YUM process to the satellite or repository in the log?
Yes, the log indicates whether the normal YUM process in the satellite or repository is used.
What is the difference between registering a repository and importing a repository?
Use the import feature if you have existing repositories that are not included in the Repositories list in the dashboard. Use the register feature if you already have a repository in the Repository list, but you still need to link the repository with the endpoint.
What happens when the repository does not contain the package?
When a package is not found, the Fixlet fails. You can troubleshoot from EDR_DeploymentResult.txt, which is where the YUM output is logged.
What happens if there are issues with the custom repository solution?
Users that encounter issues with the custom repository resolution can revert to the standard BES server solution. Users can run the task that is called Disable custom repository support - Red Hat Enterprise Linux.
In the Endpoints tab of the RHEL Custom Repository Management dashboard, are the repositories that are listed in the lower part of the window that is used in sequence?
There is no sequence in the repositories that are listed in the Endpoints tab. When YUM queries the repositories, the repository that first gets the fetch query replies, including the package and its dependencies.
Through the RHEL Custom Repository Management dashboard, a patch was deployed through a custom repository that is not a mirror of the manufacturer site. The deployment failed and the EDR logs indicate that the rpm files could not be opened. What should I do?
When a custom repository that is not a mirror of the vendor site is used, it is possible that the default gpgcheck is being done as part of the installation and the gpg signature files might not be included. The rpm files might not be checked for authenticity and the installation might fail. To resolve this, ensure that when you register the endpoints in the RHEL Custom Repository Management dashboard, you added 'gpgcheck=0' to Additional fields.
Does BigFix support Red Hat satellite servers?
BigFix does not support nor provide Fixlets for Red Hat Satellite servers. For more information about the scope of BigFix support for Red Hat Enterprise Linux, see:
BigFix does have the capability to register and connect your existing satellite repositories to endpoints using the Custom Repository feature. For more information about custom repositories, see
Can I install several packages using 'Task: Install packages by using YUM'?
Yes, you can install several packages with the task. Use a space to separate the rpm names.
I'm trying to deploy Fixlets and received the following warning message: Warning: execute prefetch plug-in command taking more than 2 seconds to complete. It took 4 seconds. ActionLogMessage: (action:1343) Missing required argument size=. What is causing the error and how could I remedy this?

Users who are subscribed to EDR and native sites might also encounter this message. Try the following actions to troubleshoot the failed deployment.

  • Check if the gpg keys are installed and enabled.
  • Gather the latest version of the Patches for RHEL site.
  • Delete the /var/opt/BESClient/yum folder and run the action again.
  • Check if sha1 is present in the EDR_PackageSpec files. The EDR_PackageSpec files can be found in the /var/opt/BESClient/_BESDATA/Patches for RHEL 7 folder.
  • Check if bzip2 is available in the environment. If not, install bzip2.
What version of YUM does the YUM Transaction History dashboard support?
You must have a minimum YUM version of 3.2.28.
Which version of Red Hat Enterprise Linux does the YUM Transaction History dashboard support?
The dashboard supports Red Hat Enterprise Linux 6 and later versions.
In the YUM Transaction History dashboard, what is the difference between rollback and undo?
The rollback command will undo all transactions up to the point of the specified transaction. The undo command will revert the selected transaction only.
What is the difference between the YUM Transaction History log and YUM Logs analyses?

Patch Management for Red Hat Enterprise Linux generates the YUM Transaction History log, which records the results of the actions that are taken in the YUM Transaction History dashboard. The log is located in /var/opt/BESClient/EDRDeployData/yum_history.log.

The YUM log is the official log that is generated by YUM in /var/log/yum.log by default. To change the default location, modify the log file settings in /etc/yum.conf.

Does the YUM Transaction History dashboard show only yum -update all?
Aside from yum -update all, the Command Line column in the dashboard also shows the different transactions such as the following installation commands.
  • install bzip2
  • install net-tools
  • install vim enhance
  • install wget
To learn more about YUM commands, see the Red Hat Enterprise Linux website:
How does the YUM Transaction History dashboard work if you have configured the BigFix client to use YUM repository or satellite servers?
The YUM Transaction History dashboard does not adversely affect your deployment if you have configured the BigFix client to use YUM repositories or satellite servers. If you already use a local YUM repository or satellite server, it might be easier to provide the packages for rollback.
I'll be using the RHSM download plug-in and I saw that it is highly suggested that a few tasks be applied before deploying Fixlets. Why do I need to do this?

Users are highly suggested to apply the tasks described before deploying Fixlets to avoid issues with GPG keys and the execution of the prefetch plug-in.

Red Hat requires the use of GPG keys. The following two tasks import the GPG keys to the endpoints.

  • Import RPM-GPG-KEY-redhat-release - RHEL 6 (from the Patches for RHEL6 Native Tools site)
  • Import RPM-GPG-KEY-redhat-release - RHEL 7 (from the Patches for RHEL 7 site)

Use the Change Timeout for Prefetch Plugins task, which is found in the Patching Support site, to avoid an error with the execution of the prefetch plug-in. The error is caused by a short prefetch timeout setting. To remedy this, run the task to change the timeout to 30 minutes.

After running the task to change the timeout settings, restart the BES client with the TROUBLESHOOTING: Restart BES Client on RHEL/SUSE task. The task is found in the BES Support site.

What to do when Fixlets fail to install with the following message in the EDR log? "Warning: Nothing to install. Please check if you are using the latest kernel."
This message appears only in case of Fixlets that deploy kernel packages. A kernel Fixlet becomes relevant if the endpoint does not have the target kernel package installed or if the endpoint's active kernel is at a lower version than the target kernel package. An endpoint is still considered subject to kernel vulnerabilities even if it has the latest kernel installed but not using it actively.

To remediate the issue, restart the endpoint and ensure it is using the latest kernel available.