You can try several ways to troubleshoot Patch for Red Hat Enterprise Linux. This section also has references that are specific to the RHSM enhancements.

Troubleshooting actions

The action reported back as a failed download
Make sure your download plug-in is updated to the latest version and is registered with the correct credentials.
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.
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.
An action has failed and the EDR logs state that the private key is missing for some RPM files
When the EDR logs show the following entry when the action fails, this suggests that the RedHat Release Key is not accepted by the rpm command on the system where the action failed:

rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 37017186 Public key for <RPM files> is not installed.

You can resolve the issue in two ways:

  • Use rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release.
  • Set gpgcheck=0 in /etc/yum.conf. This option only for the native tools sites.
It is suggested that you use the first command. The second command gpgcheck allows other unsigned packages to be installed.
An action has failed and the EDR logs do not give any information about the failing action
The last six lines of the deployment and test actions are intended to delete the temporary files that are created during the action execution. If the deployment logs do not give information about the reason for the failure, delete the following two lines to troubleshoot:
  • To see the YUM configuration used during the action, delete "{parameter "EDR_YumConfig"}"
  • To see the YUM output that is generated during the dependency resolution, delete "{parameter "EDR_YumResolveOutput"}"
When these two lines are deleted out, the following files are placed in the site folder for the Patches for RHEL Native tools site:
  • EDR_YumConfig_<fixlet id>
  • EDR_YumResolveOutput_<fixlet id>
An action failed and the logs contain YUM-specific errors.
For more information about YUM and errors related to it, see the YUM documentation at and the YUM-related articles in the Red Hat Customer Portal.

Troubleshooting the RHEL Custom Repository Management dashboard

Try the following steps to troubleshoot failed deployments in the RHEL Custom Repository Management dashboard.
  • Ensure that you enable the task that is called Enable custom repository support - Red Hat Enterprise Linux task from the Patching support site.
  • Ensure that when you register the endpoints, you added gpgcheck=0 to Additional fields.
  • Check that the client setting _BESClient_RHEL_AllowYumDownloads in the endpoints is set to 1.
  • Verify that the downloads went through the custom repository through the https service logs in the custom repository.
  • Refer to the following logs:
    • /var/opt/BESClient/EDRDeployData/register-repo.log
    • /var/opt/BESClient/EDRDeployData/register-satellite.log
    • /var/opt/BESClient/EDRDeployData/unregister-repo.log
    The following example shows a log for a standard repository:
    Processing /etc/yum.repos.d/test-repo.repo/etc/yum.repos.d/test-repo.repo
    Done with /etc/yum.repos.d/test-repo.repo
  • Check the repository configurations that are stored in /etc/yum.repos.d/. The configurations include the user name and password of the repositories that the users have.

To check the deployment logs in the endpoints, go to /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.

Note: 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

Troubleshooting the RHSM Download Plug-in

When problems occur, you can determine what went wrong by viewing messages in the appropriate log files that provide information about how to correct errors.

  • Download plug-in log and configuration files

    Enhanced logging with clearer error reporting and error handling to improve troubleshooting.

    Lists the results of the downloads related to the execution of the RHSM download plug-in. The amount of information depends on the logging level.
    The log can be found in the following locations:
    • On Windows systems: %PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\RHSMProtocol
    • On Linux systems: /var/opt/BESServer/DownloadPlugins/RHSMProtocol
    The configuration log can be found in the following location: <BES Server install location>\DownloadPlugins\RHSMProtocol\plugin.ini.
    • On Windows systems, the file is in the BigFix server installation directory. For example, %PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\ RHSMProtocol.
    • On Linux systems, the file is in the root directory tree occupied by the download plug-in. For example, /var/opt/BESServer/DownloadPlugins/RHSMProtocol.
  • Client log file
    The following log file can be found in the client folder in the directory /var/opt/BESClient/EDRDeployData.
    Lists the results of the EDR deployment and the Yum output.

Error when /var is mounted as noexec

All available Fixlets use an executable that by default runs directly from the /var directory, a partition on the endpoint. The Fixlets will not work when /var is set with the noexec option, regardless of whether the RHSM Download Plug-in or Custom Repository solution is used. Therefore, ensure that the /var directory is not set with the noexec option by doing the following steps:

  1. Check the client log to see if the prefetch plug-in returned the exit code 126. For example:
  2. Run mount as the root user to check the mount option that is currently used:
    [root@host ~]# mount
    /dev/mapper/vg_data-lv_root on / type ext4 (rw)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    devpts on /dev/pts type devpts (rw,gid=5,mode=620)
    tmpfs on /dev/shm type tmpfs (rw) 
    /dev/sda1 on /boot type ext4 (rw,nodev) 
    /dev/mapper/vg_data-lv_var on /var type ext4 (rw,noexec,nosuid,nodev) 
    none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
If /var is set to noexec, you must take one of the following actions:
  • Remove the noexec mount option.
  • Move /var/opt/BESClient to a different partition, which is not noexec, and create a symbolic link to it in its place.
  • Run the Set the path for _BESClient_LinuxPatch_executable_directory Fixlet and specify an alternative directory to run the executable for patching. The directory path must be a valid, absolute path name. It can contain only alphanumeric characters, forward slashes, and underscores.