[Spacewalk-list] Error While Kickstarting

George listmail.gg at gmail.com
Tue Feb 11 11:23:01 UTC 2014 

So today I got my kickstarts working again ...

so I went in a little deeper and got a peek at the current package repos 
online and checksummed them:

a351949c3b473df3ea9b524b1fa02d33 
redhat-logos-60.0.14-12.el6.centos.noarch.rpm.6.4_32
e8846e8f42eb877abc2fce1c8bd2f0e9 
redhat-logos-60.0.14-12.el6.centos.noarch.rpm.6.4_64
a351949c3b473df3ea9b524b1fa02d33 
redhat-logos-60.0.14-12.el6.centos.noarch.rpm.6.5_32
a351949c3b473df3ea9b524b1fa02d33 
redhat-logos-60.0.14-12.el6.centos.noarch.rpm.6.5_64
502fb747b0e28ed38f218d9ab3bb1479 
xdg-utils-1.0.2-17.20091016cvs.el6.noarch.rpm.6.3_32
261220c805ac1ca4207b21c756c4dc32 
xdg-utils-1.0.2-17.20091016cvs.el6.noarch.rpm.6.3_64
502fb747b0e28ed38f218d9ab3bb1479 
xdg-utils-1.0.2-17.20091016cvs.el6.noarch.rpm.6.4_32
261220c805ac1ca4207b21c756c4dc32 
xdg-utils-1.0.2-17.20091016cvs.el6.noarch.rpm.6.4_64
502fb747b0e28ed38f218d9ab3bb1479 
xdg-utils-1.0.2-17.20091016cvs.el6.noarch.rpm.6.5_32
502fb747b0e28ed38f218d9ab3bb1479 
xdg-utils-1.0.2-17.20091016cvs.el6.noarch.rpm.6.5_64


basicly: packages with exactly the same name exist in both centos 6.5 
and centos 6.4 repo (and sometimes also centos 6.3), but their checksum 
is different!

I guess the deduplication engine from spacewalk can't handle that and 
when I imported centos 6.5 it linked some of the packages to the equally 
named package from centos 6.4 and since for kickstart you use the 
repodata on the dvd the checksum on install is different from the 
checksum in the repodata and all the errors like "download does not 
match expected package", "package corrupted" will kill the install.

In conclusion: cleaning out all the OS repos in my spacewalk and only 
syncing the centos 6.5 one fixed it for me ...

Regards,

G


On 10/02/14 22:20, George wrote:
> 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

More information about the Spacewalk-list mailing list