[Spacewalk-list] Error While Kickstarting

Mon Feb 10 21:20:18 UTC 2014

Hello again,

I think I figured out the problem:
when kickstarting anaconda fetches the packages from the url (for a 
kickstart with centos 6.5 x86_64):
http://spacewalk/ks/dist/centos-6.5-x86_64/Packages/*

One of my kickstarts failed for example at the package xdg-utils:
http://spacewalk/ks/dist/centos-6.5-x86_64/Packages/xdg-utils-1.0.2-17.20091016cvs.el6.noarch.rpm

So I did a wget of this package and compared the sha256sum to a the 
webinterface and another package from a public mirror

the sha256sum is and should be:
a371df77e3e50d353c77a7965be90c796a755f0413f8dd62d4fc50b993fe9f69
but the file I wget from the url above shows:
2d1ae581c04ffd265220e5e8befb1f40c77de7e9299d65d95f1f4a4a33ae4264

when I lookup xdg-utils it says that it's the same version in centos 6.5 
x86_64, centos 6.3 ia32, centos 6.4 ia32

when I do a search for that package I also find a package which matches 
the sha256sum from the package I wget (and which fails to install on 
kickstart) in the channel centos 6.4 x86_64 and centos 6.3 x86_64

so to conclude:

spacewalk is making mistakes when it seperates channels ... it takes 
wrong packages in wrong channels ...
Cleaning up all my channels now and re-syncing only the centos 6.5 
x86_64 packages ...

Come to think of this I have seen this behavior before ... but only with 
1 package and there I also deleted this particular package and resynced 
it again from a mirror.

Any developer could dig in the code and try and find why this happens?

Regards,

G.
On 17/01/14 01:43, George wrote:
> Hello,
>
> recently I encountered the same behavior,
> did you find a solution for this in the end?
> It seems to be a terrible problem from which I cannot seem to recover
> ... I tried deleting all packages from a channel, deleting the repodata
> cache and re-fetching the whole lot and rebuilding repodata to no avail.
> One train of thought is that it has something to do with proxy stuff ...
> but I am not so sure how spacewalk exactly works on that part ... I know
> the httpd runs an proxy_ajp module or something but not sure how this
> all plays together ...
>
> I am at a complete loss here ... if I can't get it fixed in due time I
> see no other option but to install a new spacewalk server and redo my
> whole setup :-(
>
> centos 5.10 x86_64 with spacewalk 2.0 (upgraded a couple of months ago
> from 1.6, but up to now it looked to run fine ... )
>
> I checked httpd logs but they just say similar things like described
> below a code 206 and no relevant errors in the catalina.out either.
>
> I tried with several -working fine up to last week- profiles but none
> seem to want to install.
>
> Regards,
>
> G.
>
> On 01/10/13 15:57, Wojtak, Greg wrote:
>> SELinux is permissive.  I checked /var/log/httpd/error_log, nothing.
>> Something in /var/log/httpd/access_log caught my attention though -
>>
>> 1.2.3.4 - - [01/Oct/2013:09:51:58 -0400] "GET
>> /ks/dist/CentOS-6.4-x86_64/Packages/gdbm-1.8.0-36.el6.x86_64.rpm
>> HTTP/1.1"
>> 206 7504 "-" "CentOS (anaconda)/6.4"
>>
>> Looks like it is getting a 206 response code and only about 7K of the
>> rpm,
>> which is about 15K short.  According to RFC2616, 206 is a Partial Content
>> response code, which I'm not really familiar with.
>>
>>
>> Any ideas about that?  Is there some httpd setting I need to tweak?
>>
>> -- Greg Wojtak Senior Unix Systems Engineer Office: (313) 373-4306
>> Mobile: (734) 718-8472 On 10/1/13 9:20 AM, "Michael Mraka"
>> <michael.mraka at redhat.com> wrote:
>>> >Wojtak, Greg wrote:
>>> >% >% Try 10/10 for
>>> >%
>>>> >>http://<spacewalk-server>/ks/dist/CentOS-6.4-x86_64/Packages/gdbm-1.8.0-3
>>>>
>>>> >>6
>>> >% >.el6.x86_64.rpm failed: [Errno 1] Header is not complete.
>>> >% >% Failed to get
>>> >%
>>>> >>http://<spacewalk-server>/ks/dist/CentOS-6.4-x86_64/Packages/gdbm-1.8.0-3
>>>>
>>>> >>6
>>> >% >.el6.x86_64.rpm from mirror 1/1, or downloaded file is corrupt.
>>> >% >%
>>> >% >% >From the command prompt window, I can wget that url and pull down
>>> >the
>>> >% >file.
>>> >% >%
>>> >% >% I've tried removing the package from the channel and re-adding it,
>>> >the
>>> >% >result was the same.  I've tried creating a new kickstart profile
>>> (from
>>> >% >scratch, not a clone), also with the same result.
>>> >% >%
>>> >% >% Any ideas?
>>> >% >
>>> >% >I'd locate gdbm-1.8.0-36.el6.x86_64.rpm on spacewalk's disk and
>>> >% >run rpm -K to check whether it's ok.
>>> >%
>>> >%
>>> >% Thanks Michael.  The RPM itself appears to be fine:
>>> >%
>>> >% [root at spacewalk satellite]# rpm -K
>>> >%
>>> >redhat/1/66d/gdbm/1.8.0-36.el6/x86_64/66d7e15c29b5215a5723962777734c389ac6
>>>
>>> >b
>>> >% 7f9e726ec362e33277e3c7fe58c/gdbm-1.8.0-36.el6.x86_64.rpm
>>> >%
>>> >redhat/1/66d/gdbm/1.8.0-36.el6/x86_64/66d7e15c29b5215a5723962777734c389ac6
>>>
>>> >b
>>> >% 7f9e726ec362e33277e3c7fe58c/gdbm-1.8.0-36.el6.x86_64.rpm: rsa sha1
>>> (md5)
>>> >% pgp md5 OK
>>> >% [root at spacewalk satellite]# rpm -q --info -p
>>> >%
>>> >redhat/1/66d/gdbm/1.8.0-36.el6/x86_64/66d7e15c29b5215a5723962777734c389ac6
>>>
>>> >b
>>> >% 7f9e726ec362e33277e3c7fe58c/gdbm-1.8.0-36.el6.x86_64.rpm
>>> >% Name        : gdbm                         Relocations: (not
>>> >relocatable)
>>> >% Version     : 1.8.0                             Vendor: CentOS
>>> >% Release     : 36.el6                        Build Date: Thu 11 Nov
>>> 2010
>>> >...
>>> >
>>> >Hmm, permission and/or selinux? Any eeror in
>>> /var/log/httpd/error_log or
>>> >any AVC in /var/log/audit/audit.log?
>>> >
>>> >Can other clients registered to the same channel download the package?
>>> >
>>> >Regards,
>>> >
>>> >--
>>> >Michael Mráka
>>> >Satellite Engineering, Red Hat