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 <[email protected]> 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: [email protected] > A: [email protected] > 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@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@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 >> [email protected] >> https://www.redhat.com/mailman/listinfo/spacewalk-list > > _______________________________________________ > Spacewalk-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
