[Spacewalk-list] RHEL4 depsolve issue

Jason M. Nielsen jnielsen at myriad.com
Fri Nov 11 18:42:07 UTC 2011


SW 1.5,Oracle 11g backend, both on RHEL 5.5 x86_64.

Updating RHEL 4.3 64bit to 4.8.

This has been done in the past successfully on systems that 
theoretically should have been configured identical from a package 
perspective and SW client perspective.

I am perturbed and at a loss but I am encountering a depsolve issue for 
some packages. So far I have narrowed it down to "openldap" and 
"nfs-utils-lib". There are more though I have been unable to determine 
which ones at this point and am now stumped.

In /var/log/up2date client side I see:

[Fri Nov 11 07:54:36 2011] up2date solving dep for: ['gcc', 
'audit-libs', 'authconfig', 'openldap', 'curl', 'evolution28-cairo', 
'evolution28-gtk2', 'evolution28-pango', 'gcc', 'gcc', 'gcc', 'gcc', 
'libgomp', 'ghostscript', 'ghostscript', 'glibc', 'gnutls', 
'initscripts', 'udev', 'krb5-libs', 'krb5-libs', 'lam-libs', 
'liblam.so.0()(64bit)', 'libmpi.so.0()(64bit)', 
'libgcc_s.so.1(GCC_4.2.0)(64bit)', 'libgcc_s.so.1(GCC_4.2.0)', 
'libgcc_s.so.1(GCC_4.2.0)(64bit)', 'libibverbs.so.1', 
'libibverbs.so.1(IBVERBS_1.0)', 'libibverbs.so.1(IBVERBS_1.1)', 
'libpng', 'gcc', 'nagios-common', 'glibc-devel', 'openldap', 'openldap', 
'openldap', 'libibcommon.so.1()(64bit)', 'libibumad.so.1()(64bit)', 
'openib', 'libibumad.so.1()(64bit)', 
'libibumad.so.1(IBUMAD_1.0)(64bit)', 'openssh', 'openssh', 'openssl', 
'openssl', 'pam', 'python', 'python', 'python', 'rpm', 'rpm-libs', 
'rpm', 'rpm-libs', 'selinux-policy-targeted', 
'libsgutils.so.1()(64bit)', 'perl(Archive::Tar)', 'perl(Archive::Tar)', 
'perl(IO::Zlib)', 'system-config-netboot-cmd', 'systemtap-runtime', 
'python', 'vim-common', 'xorg-x11-libs']


Using up2date --dry-run I narrow it down to "openldap" and the only way 
I can get this rpm to install is to download them manually and then 
force their installation with --nodeps (yes I know you should never use 
but 1)this is a test system and 2)I have found no alternative). A 
--dry-run shows that issue resolved.

Attempts to update again result in more and similar errors this time its 
"nfs-utils-lib". I "fix" in the same fashion but further attempts result 
in again similar errors at which point I have been unable to identify 
the culprit(s).

My first concern is why this is happening in the first place. I am all 
but positive that nothing regarding the RHEL4 channels nor relevant 
items in SW have changed. Or at least anything that I manually change or 
am aware of. Though the chance is there that perhaps a package was added 
etc.

Anyone have a clue what might be causing this? The dependencies exist in 
the channel, are visible to the client and manual installation works if 
I grab all of the deps manually.

Also looking for any input as to what might be fubar in the last 
instance of the depsolve failure and parsing each package (as I did the 
others) with --dry-run has been unsuccessful in identifying the 
troublesome package.

Thanks!




More information about the Spacewalk-list mailing list