Possible Root Causes for unsuccessful Linux patching activities

There are multiple options for patch installations failures. Some may be addressed before the installation, with our predictive patching and endpoint readiness mechanisms. But other cases, might be tricky and provide some further investigations. 

 

yum priority plugin related failures

This section will highlight a specific case in Linux servers, where a yum priority plugin is installed on your endpoint and causes the patching actions to fail. 

 

If the "Collect endpoint update" activity was successfully executed BUT "execute patch installation" has failed and activity output or yum list updates returned the following 

packages excluded due to repository priority protections

This means that you might have an issue with repositories priority configuration. 

 

To further investigate and validate please perform the following actions: 

1. SSH to your Linux (RHEL / CentOS) endpoint

2. Check for available updates. The 'repoquery' is part of yum-utils and will return the needed packages 

repoquery -qa --pkgnarrow=updates --queryformat '%{name} %{arch} %{epoch}:%{version}-%{release} %{buildtime:isodate}' --quiet 1>"$temp_file" 2>&1

3. If the endpoint requires updates from step 2, use that package to mimic an installation. 

yes n | yum update <package name> -d3

• The output of the last command will show if this is related to the yum priority plugin. 

• If the command output includes your package name and exact version as "excluded (priority)", this means that the priority of the repository is not configured properly.

4. Based on the output, identify the repository name and run the following command 

grep '\[<repo name>\]' -A 10 /etc/yum.repos.d/*.repo

This means the repository is probably in a very low priority (default priority is 99 which is the lowest priroity) and it should be modified in the yum repository configuration on your endpoint:

• modify the local repo file (location can be found based on grep output)
• To each excluded priority repository add the following line: 
  • priority=1
  • It should now look like this :

[local-base]
name=CentOS Base
baseurl=http://repos.test.lab/base/
gpgcheck=0
priority=1
enabled=1

• save and exit the file

After you have modified all the relevant repositories, repeat step 3 and make sure you are able to install the package via JetPatch or by running 

yes y | yum update <package name> -d3

 

Rollback is failing because previous package version are missing in repositories

JetPatch is leveraging Linux built in capabilities to install and remove packages. When reverting a patch installation process, JetPatch uses the  OS-level undo functionality to remove all related packages. In order for that procedure to succeed, the previous package version must exist in the repository. In such case, there is nothing that can be done and the activity will keep failing. 

If you encounter a rollback which constantly fails and you are not really sure why, this might be the case. To verify it is indeed related to missing previous package versions perform the following -

1. Navigate to Endpoints > Activities
2. View the related "execute patch installation" activity that fails and download the activity output
3. The failure code should be similar to this 

Explanation

JetPatch told the endpoint to revert transaction #53. This transaction upgraded ‘parted’ package from v. 3.1.23 to 3.1.32. Upon reverting the transaction, the ‘parted’ package should be downgraded from 3.1.32 to 3.1.23.

The issue is that v. 3.1.23 does NOT exist in known repositories and hence the downgrade is unsuccessful.   

 

Low disk space - /var/cache/yum is filling up very often

Add a workflow pre post task to clear cache yum clean all

Note: yum clean all only clears cache for repositories that are currently enabled. To remove all cache you can remove the contents of /var/cache/yum/ manually:

# rm -rf /var/cache/yum

 

Other: generate full activities log and analyze output

See instructions