[Spacewalk-list] CentOS 5.2 - a warning]

Wed Apr 22 16:20:59 UTC 2009

Two emails responded to in one....

Date: Wed, 22 Apr 2009 08:50:51 +0100 (BST)
From: John Hodrien <J.H.Hodrien at leeds.ac.uk>
On Tue, 21 Apr 2009, m.roth2006 at rcn.com wrote:

>> Well, I've succeeded in reverting to a pre-upgrade snapshot, 
>> reregistered the system, and did the upgrade.
>
>> This is all CentOS 5.2. I'm still on Spacewalk 0.4
>
>> HOWEVER, as an FYI, a warning: for some reason, in the x86_64 
>> repository, there are a number of i686 packages, including the kernel.

> kernel?  Where have you got this from?  CentOS 5.2 doesn't 
> have i686 kernel packages in the x86_64 repo.  It contains
> shedloads of i386 packages, and a few i686 packages.  But 
> big deal, that's correct.

Sorry, the kernel module may have been in there due to problems back when I created the repository with reposync. However, at an official mirror, there *are* serious i686 packages. See my response, below. 

> Apparently, when I tell Spacewalk upgrade, its select picks the first 
> package, and so got the i686 32-bit packages. The result of this was, 
> when I tried to reboot, it would hang 100% of the time with "request_module:
> runaway loop modprobe binfmt-464c" repeated several times.

Spacewalk /was/ notoriously broken at properly handling x86_64.  I know not the current state, but I was under the impression it was now mostly fine.

Not having real problems with Spacewalk, once I got rid of the i686 packages under x86_64.

> Personally I'd have been happier about trying an upgrade 
> from 5.2 to 5.3 by subscribing to the 5.3 base channel, and 
> issuing a custom command through spacewalk of 'yum -y 
> upgrade'.  That way you're not relying on spacewalk's 
> package upgrade logic, you're just relying on yum.  If 
> yum's logic is broken, you're probably screwed anyway.

I'm not sure I want to do that. The folks here want to use Spacewalk for possibly provisioning a number of systems at once, and to be able to select a number of identical ones, and say "uprade", not to have to issue custom commands for each system. Also, to me, that sort of defeats part of the point of Spacewalk.

But the first part of what you suggest is what I did: unsub'd the test client from 5.2, sub'd it to 5.3 & child channels, and said upgrade.

>> Once I went to manage software channels, packages, and looked there 
>> and found them, and then removed them, I had no problem.
>
>> Btw, I just looked at the CentOS 5.2, and doing a find at the top 
>> level of .../pub/centos-5.3-x86_64, I find only two such packages:
>> ./base/CentOS/glibc-2.5-34.i686.rpm
>> ./base/CentOS/openssl-0.9.8e-7.el5.i686.rpm

> Stop getting so excited about i686 packages (unless you've 
> uncovered a juicy bug in spacewalk to do with how they're 
> handled).  They're nothing special.

Well,yes, they are. I know what the 686's are. The big thing was this: when they were in the Spacewalk repository, the query that Spacewalk did on its d/b got them uniquely. So when I told it to upgrade, it did it with those packages. Then, when I went to reboot, that failed coming back up, with the error "request_module: runaway loop modprobe binfmt-464c" repeated three or so times.

As soon as I removed them from Spacewalk's d/b by deleting that package, the upgrade went fine. The explanation that led me to that was at <http://saalwaechter-notes.blogspot.com/2008/10/requestmodule-runaway-loop-modprobe.html>

So, my thinking is that the i386 libs are fine, as you mentioned, but that the 686's try to *replace* the x86_64 ones, and then it croaks.

<snip>
>> On the other hand, when I click on a package name on the
>> system->software->upgrade page, expecting the same info that I see 
>> system->software->going
>> through channels->packages, I get a 500 error.

> It's almost like the reported bug against 0.4.

Kindly note that I said I was running 0.4.

Date: Wed, 22 Apr 2009 11:52:24 +0200
From: Ralph Angenendt <ralph+redhat at strg-alt-entf.org>

I wrote:
John Hodrien wrote:
>>> So, folks, be warned.... This is *not* a Spacewalk problem - I 
>>> suppose I should tell the CentOS folks, but since I know there are a 
>>> number of other folks working with CentOS here, thought I'd mention it.
>
>> Only report it if you're really really really sure you're not wasting 
>> their time.  I just don't see anything to backup your claims of doom.  
>> 5.2 repos look a whole lot like 5.3 repos, and look perfectly fine to me.

>Multiarch sucks (sometimes), but there really isn't anything >wrong with our repositories regarding i686 packages (and >there is no i686 kernel in the 5.2/5.3 repositories). >Luckily the original poster didn't look for
>i386 packages <vbeg>.

Wrong. At
<http://mirror.anl.gov/pub/centos/5.2/updates/x86_64/RPMS/>, I find
glibc-2.5-24.el5_2.2.i686.rpm (a real killer)
openssl-0.9.8b-10.el5_2.1.i686.rpm
xen-devel-3.0.3-64.el5_2.1.i686.rpm
xen-libs-3.0.3-64.el5_2.1.i686.rpm 

And at <http://mirror.anl.gov/pub/centos/5.3/os/x86_64/CentOS/> is
glibc-2.5-34.i686.rpm 
openssl-0.9.8e-7.el5.i686.rpm 

So, they really are in the repository, and incorrect.

       mark