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!

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Reply via email to