+++ This bug was initially created as a clone of Bug #1055571 +++ --- Additional comment from Vasyl Kaigorodov on 2014-01-20 09:53:56 EST --- When creating a kickstart to provision RHEL6 x86_64, in the logfile /root/ks-rhn-post.log below error is observed: error: Failed dependencies: libc.so.6 is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.0) is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.1) is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.1.3) is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.2) is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.3) is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.3.2) is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.3.4) is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.4) is needed by libxml2-2.7.6-14.el6.i686 libc.so.6(GLIBC_2.7) is needed by libxml2-2.7.6-14.el6.i686 libdl.so.2 is needed by libxml2-2.7.6-14.el6.i686 libdl.so.2(GLIBC_2.0) is needed by libxml2-2.7.6-14.el6.i686 libdl.so.2(GLIBC_2.1) is needed by libxml2-2.7.6-14.el6.i686 libm.so.6 is needed by libxml2-2.7.6-14.el6.i686 libm.so.6(GLIBC_2.0) is needed by libxml2-2.7.6-14.el6.i686 libz.so.1 is needed by libxml2-2.7.6-14.el6.i686 In the kickstart file /root/ks.cfg it's seen that after installed the base operating system from it’s kickstart tree, just before registering - it tries to install some optional packages: libxml2-python-2.7.6-14.el6.x86_64.rpm pyOpenSSL-0.10-2.el6.x86_64.rpm libxml2-2.7.6-14.el6.i686.rpm rhnlib-2.5.22-15.el6.noarch.rpm Note the architecture of libxml2-2.7.6-14.el6 - it's incorrect, and causing issues. --- Additional comment from Stephen Herr on 2014-01-20 12:47:35 EST --- This new issue is related to the fix for bug 787718. Previously libxml2 was installed by default on new installations. Then it was not, so bug 787718 explicitly requires the package to be installed to get rid of a harmless error message in the kickstart logs. This issue is that we are explicitly requiring libxml2 to be installed, but it's trying to install the wrong arch version, i386 instead of x86_64. We are treating libxml2 the same way we have always treated rhnlib, libxml2-python, and pyOpenSSL, so I have no idea why this problem is cropping up now and not before. The root problem is that the latest_package_equal_in_tree query makes no distinction for package architectures, so if your kickstart tree contains the i386 and x86_64 versions of a package which one you get is quasi-random. Given the many possible package architectures that could be in a channel (for example in an x86_64 channel we could have noarch, i386, i486, i586, i686, athlon, ia32e, amd64, x86_64, src, and nosrc packages, and the above is repeated for every possible channel architecture) it's impossible to know exactly what the arch "should be" for the package that we really want. However, there would be some common cases and some extremely uncommon (never actually happen?) cases. i386 vs x86_64 packages would be the most common case, followed probably by s390 vs s390x packages or sparcv9 vs sparc64. I think in those cases we would want to choose the x86_64, s390x, and sparc64 versions almost always, so a heuristic that returned those might be good enough. --- Additional comment from Vasyl Kaigorodov on 2014-01-21 07:25:39 EST --- This does not prevent a machine from registering to Satellite, overall in the end system is operational.
This change should resolve this issue for any kickstart profile created or modified after the update has been applied. To updating an existing profile, simply change something about it that will regenerate the kickstart file and then change it back. For example, set a Kernel Option of "a", update the kickstart, and then change it back and update again. Committing to Spacewalk master: a2149b9d5c1532e867173100d8fe1c109c58a32d
Spacewalk 2.2 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes22