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