[Spacewalk-list] Error While Kickstarting

Paul Robert Marino prmarino1 at gmail.com
Tue Feb 11 15:33:55 UTC 2014


are you using any of the errata sync scripts by any chance?
if so then you are probably hitting a known bug
https://bugzilla.redhat.com/show_bug.cgi?id=834569

by the way spacewalk handles it just fine its yum that can't deal with
it I would need to see the actual error but I bet its seeing two
packages with the same name with different checksum's in the same
channel.



On Tue, Feb 11, 2014 at 8:03 AM, Amedeo Salvati <amedeo at oscert.net> wrote:
> Hi George,
>
> but you have created a base/child channels for every minor release of
> centos?
>
> Usually I create only one base, and relative child channels for every centos
> major release (5.x or 6.x) by pointing to:
>
> ....../mirrors/CentOS/6/os/x86_64/
> ....../mirrors/CentOS/6/updates/x86_64/
>
> and if you want a specific centos release (6.1, 6.2, 6.3...) you can use
> cloned channel or spacewalk-clone-by-date command
>
> best regards
> a
>
>
> Da: spacewalk-list-bounces at redhat.com
> A: spacewalk-list at redhat.com
> Cc:
> Data: Tue, 11 Feb 2014 13:23:40 +0100
> Oggetto: Re: [Spacewalk-list] Error While Kickstarting
>
>> 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"
>> >>>> wrote:
>> >>>>> >Wojtak, Greg wrote:
>> >>>>> >% >% Try 10/10 for
>> >>>>> >%
>> >>>>>> >>http:///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:///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
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




More information about the Spacewalk-list mailing list