[Spacewalk-list] libxml2-python and kickstart

Fri Jun 14 02:52:15 UTC 2013

(To Jan) Question.  Given that this is discussed in
http://bugs.centos.org/view.php?id=4978 (going back almost 2 years now),
and is still an active issue, I'm wondering if the "official" answer is to
not use the updates repo during installation or not.  But if this is just a
metadata bug, as described above and in the referenced bugzilla entry, can
someone please elaborate on what we, the users, can do to help get this
resolved in a way that we can specify additional repositories during
installation safely, as described in
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-pkgselection-x86.html
(section
9.18.1) and
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html
(via
the "repo" keyword)?  Or are we just SOL?

(To Paul) Can you please elaborate on this?  As noted in the
above-referenced bugzilla entry, people are still fighting with this issue
2 years later, but if you've got a working solution to this problem, I'm
sure that many folks would like to know more about it...

Thanks,
 -Ian

On Thu, Jun 13, 2013 at 8:02 AM, Paul Robert Marino <prmarino1 at gmail.com>wrote:

> One thing I found is that you need to use the image files from the
> "Everything" install disk when creating the kickstart distribution or
> you will run into problems like the one you described with the update
> channel.
>
>
>
> On Mon, Jun 10, 2013 at 8:08 AM, Jan Hutař <jhutar at redhat.com> wrote:
> > On Mon, 3 Jun 2013 23:41:14 +0000 Faye Salwin
> > <Faye.Salwin at betfair.com> wrote:
> >
> >> Centos6 updates contains libxml2-python and Spacewalk pulls
> >> THAT version (as it is the latest available version within any
> >> child channels of the selected distribution) of the RPM when
> >> building kickstart files instead of a package from a channel
> >> enabled for kickstart (The Java code pulls these files using
> >> the "file download url")
> >>
> >> This works:
> >>
> http://x.x.x.x/download/package/2ca68cda56a77523c946e69ca5dc8d34e0f45f01/0/1/885/libxml2-python-2.7.6-8.el6_3.4.x86_64.rpm
> >>
> http://x.x.x.x/download/package/1e2379d4dadc3fef16c422d3aa705ff83264b469/0/1/5811/pyOpenSSL-0.10-2.el6.x86_64.rpm
> >>
> http://x.x.x.x/download/package/704fdbe78c79726bab6d1e5f8461045ef7f0a194/0/1/11132/rhnlib-2.5.55-1.el6.noarch.rpm
> >> rpm -Uvh --replacepkgs
> >> --replacefiles /tmp/rhn_rpms/optional/pyOpenSSL*
> /tmp/rhn_rpms/optional/rhnlib* /tmp/rhn_rpms/optional/libxml2-python*
> >>
> >> If the Updates repo is disabled in the kickstarter, but
> >> available as a child channel of the install tree, then
> >> libxml2-python fails to install as it cannot supply the
> >> dependencies to libxml2-python (*12-el6_4*) which are in the
> >> Updates repo too.
> >>
> >> I have read that one shouldn't enable the Updates Repo during
> >> Kickstart, but if I do not delete libxml2-python from the
> >> updates repo then a kickstart which does not include the
> >> updates repo will fail.  If I do install the updates repo to
> >> kickstart then it will lag the install for a long time while
> >> it tries and retries to access a comps file which does not
> >> exist. (there are comps files for EPEL and Spacewalk which I
> >> have to include during kickstart to install the rhn_client,
> >> rhncfg-client etc.  I have restricted EPEL to only those
> >> packages which the Spacewalk repo depends upon.  I believe
> >> that the kickstart will continue to function from the time
> >> that libxml2-python from updates is added until the kickstart
> >> profile is updated at which point it will re-evaluate the
> >> includes.  It doesn't seem like a good solution to delete
> >> libxml2-python every time you update kickstart and then
> >> re-sync.
> >>
> >> What is the best practice here?  Should I kickstart from a
> >> tree with updates present?  What happens about the Comps
> >> (groups file) in this case?  I've also noticed that cloning
> >> child channels (using the manage channel lifecycle script at
> >> least) does not clone the RHNCHANNELCOMPS row that is relevant
> >> which caused me a few frustrations early on.
> >>
> >> Is it not possible to kickstart just one distribution &
> >> channel selection and then switch parent channels at
> >> activation time?  That would simplify a lot of the workflow
> >> (perhaps allow you to have a single kickstart for all your
> >> lifecycle locations and validate that the parent channel is a
> >> clone of the one you are activating?)
> >>
> >> Why does the Kickstart file create java code include files
> >> that are from repos not included in the kickstart channels?  I
> >> am guessing it is so that you don't have to include the
> >> spacewalk repo as a child, but if you don't do that, it can't
> >> find rhnreg_ks for example (unless you use one of the many
> >> workarounds that have been posted in this list eg. tar ball of
> >> spacewalk files)
> >>
> >> It is entirely possible that I am just "doing it wrong" in
> >> which case a pointer to best practice would be appreciated.
> >>
> >> Thanks
> >>
> >>
> >> Faye
> >
> > Hello,
> > you should kickstart with only base channel enabled (ideally no
> > additional child channels/repos). After install you can assign
> > additional child channels and update your system (you can assign
> > these channels using activation key in your kickstart profile).
> >
> > If you have kickstart profile with base channel only and
> > satellite generated these "http://..." download links pointing
> > to packages which are not in the base channel, that is a bug and
> > please report it to the Bugzilla or here.
> >
> > Regards,
> > Jan
> >
> >
> >
> > --
> > Jan Hutar     Systems Management QA
> > jhutar at redhat.com     Red Hat, Inc.
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130613/4488d55f/attachment.htm>