[Spacewalk-list] Error While Kickstarting

Tue Feb 11 12:23:40 UTC 2014

filed bugreport http://bugs.centos.org/view.php?id=6977

Regards,

G.

On 11/02/14 12:23, George wrote:
> 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