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.
Related Topics
Parent topic: Troubleshooting Software Updates on Oracle Exadata