8.11.3 Troubleshooting a Failing Prerequisite Check Due to Dependency Problems on Exadata Database Server

When you run a prerequisite check or an update on Exadata database servers that have custom rpms installed, conflicts may cause the prerequisite check or update to fail.

When doing a prerequisite check or an update, the update utility makes two dependency checks: checks against "minimum dependencies" and checks against "exact dependencies".

To triage a dependency failure, look in the log file. This can be either dbnodeupdate.log on the target Exadata database server or <hostname>_dbnodeupdate.log in the log directory from where the update utility (patchmgr) was launched.

To locate the start of each run in the log file, search for a line that starts with zzz. For example:

zzz - /u01/patches/YUM/dbnodeupdate.sh called with arguments -u -l
/u01/patches/YUM/p23564643_121232_Linux-x86-64.zip -v -N at  2016-08-23 23:31:54

The date stamp should match the time of the run you are researching. Each run is identified with a unique runid which can also be found at the start of each run in the same log file:

[1472009516][2016-08-23 23:31:59 -0400][INFO][/u01/patches/YUM/dbnodeupdate.sh][InitLogfile][]  # dbnodeupdate.sh script rel.
 : 5.160809 started at  (runid :230816233155)

You can check for custom rpms, if any, by looking at the diag file of the specific run. The diag file is identified by the runid and can be found in /var/log/cellos on the target Exadata database server or in the directory driving the update utility. The filename for this example would be dbnodeupdate.230816233155.diag. In that file, look for the section with heading RunDetectCustomRpmsSh and rpm -qa --qf "%{n}-%{v}-%{r}.%{arch}"\n. You can find details on the (additional) packages installed (if any).

In the log file, search down from the start (zzz) for "Exact dependencies" (case sensitive) for the results of the dependency checks. In this case it says:

Exact dependencies     : Will fail on a next update
Minimum dependencies   : Will fail on a next update

As long as the minimum dependencies check passes, updates or prerequisite checks won’t fail. When both minimum and exact dependencies fail, you need to find out what caused the error.

In order to find the dependency that is causing the error, search for [ExecUpgrade][] Performing yum package dependency. This is where YUM is run (typically a dry-run first). When there is a dependency problem, you should see a YUM message starting with Error:. For example:

--> Finished Dependency Resolution
Error: Package: krb5-devel-1.10.3-33.el6.x86_64 (@ol6_latest)
Requires: krb5-libs = 1.10.3-33.el6
Removing: krb5-libs-1.10.3-33.el6.x86_64 (installed)
        krb5-libs = 1.10.3-33.el6
Updated By: krb5-libs-1.10.3-42z1.el6_7.x86_64 (exadata_generated_160616114412)
          krb5-libs = 1.10.3-42z1.el6_7
You could try using --skip-broken to work around the problem

In the example error message above, the krb5-devel-1.10.3-33.el6.x86_64 (krb5-devel) package is installed from a non-Exadata channel (ol6_latest). This krb5-devel package depends on krb5-libs. However in this Exadata update the krb5-libs package is not available. YUM fails the dependency check because updating krb5-libs is not possible without also updating krb5-devel. Because a new version of krb5-devel is not included in the Exadata update the package should be either pre-updated or removed. Pre-updating means updating the individual package manually before running the Exadata update. This can be done using the command rpm –Uvh <package-name>.

Removing the custom package is recommended and should be done using the following rpm command:

[root@dm01 ]# rpm –e krb5-devel

After removing the rpm that is causing the error, restart the update or prerequisite check.