I had a basechannel centos 6.3 with children and after that I started
with a base channel centos 6 (which is empty) which has children centos
6.4 and centos 6.5 (and all the other children like updates etc)
In your case you each time update the OS repo with the latest (since
.../mirrors/6/ will point to the current release) as far as I understand
your layout.
I wanted specific also the centos 6.3 for example since I have some
custom kernel modules which don't work with 6.4 nor 6.5 right now ...
But anyway I just emptied all the 6.x channels and only resynced the 6.5
channel.
Regards,
G.
On 11/02/14 14:03, Amedeo Salvati 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
