<div dir="ltr">That's what I was getting at. ;) I knew that your answer couldn't be considered "official", given the circumstances. Which is why I posted to see if there's a way through to a solution rather than a workaround...<div> </div><div style> -I</div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Jun 14, 2013 at 4:40 AM, Jan Hutař <<a href="mailto:jhutar@redhat.com" target="_blank">jhutar@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry, can not give you "official" answer/recommendation. From the bug you have linked it is not clear if it is CentOS or Anaconda or Spacewalk issue. Sorry, Jan <div class="HOEnZb"><div class="h5"> On Thu, 13 Jun 2013 19:52:15 -0700 Ian Forde <<a href="mailto:ianforde@gmail.com">ianforde@gmail.com</a>> wrote: > (To Jan) Question. Given that this is discussed in > <a href="http://bugs.centos.org/view.php?id=4978" target="_blank">http://bugs.centos.org/view.php?id=4978</a> (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 > <a href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-pkgselection-x86.html" target="_blank">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-pkgselection-x86.html</a> > (section 9.18.1) and > <a href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html" target="_blank">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html</a> > (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 > <<a href="mailto:prmarino1@gmail.com">prmarino1@gmail.com</a>>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ř > > <<a href="mailto:jhutar@redhat.com">jhutar@redhat.com</a>> wrote: > > > On Mon, 3 Jun 2013 23:41:14 +0000 Faye Salwin > > > <<a href="mailto:Faye.Salwin@betfair.com">Faye.Salwin@betfair.com</a>> 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: > > >> > > <a href="http://x.x.x.x/download/package/2ca68cda56a77523c946e69ca5dc8d34e0f45f01/0/1/885/libxml2-python-2.7.6-8.el6_3.4.x86_64.rpm" target="_blank">http://x.x.x.x/download/package/2ca68cda56a77523c946e69ca5dc8d34e0f45f01/0/1/885/libxml2-python-2.7.6-8.el6_3.4.x86_64.rpm</a> > > >> > > <a href="http://x.x.x.x/download/package/1e2379d4dadc3fef16c422d3aa705ff83264b469/0/1/5811/pyOpenSSL-0.10-2.el6.x86_64.rpm" target="_blank">http://x.x.x.x/download/package/1e2379d4dadc3fef16c422d3aa705ff83264b469/0/1/5811/pyOpenSSL-0.10-2.el6.x86_64.rpm</a> > > >> > > <a href="http://x.x.x.x/download/package/704fdbe78c79726bab6d1e5f8461045ef7f0a194/0/1/11132/rhnlib-2.5.55-1.el6.noarch.rpm" target="_blank">http://x.x.x.x/download/package/704fdbe78c79726bab6d1e5f8461045ef7f0a194/0/1/11132/rhnlib-2.5.55-1.el6.noarch.rpm</a> > > >> 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 > > > <a href="mailto:jhutar@redhat.com">jhutar@redhat.com</a> Red Hat, Inc. > > > > > > _______________________________________________ > > > Spacewalk-list mailing list > > > <a href="mailto:Spacewalk-list@redhat.com">Spacewalk-list@redhat.com</a> > > > <a href="https://www.redhat.com/mailman/listinfo/spacewalk-list" target="_blank">https://www.redhat.com/mailman/listinfo/spacewalk-list</a> > > > > _______________________________________________ > > Spacewalk-list mailing list > > <a href="mailto:Spacewalk-list@redhat.com">Spacewalk-list@redhat.com</a> > > <a href="https://www.redhat.com/mailman/listinfo/spacewalk-list" target="_blank">https://www.redhat.com/mailman/listinfo/spacewalk-list</a> > > -- Jan Hutar Systems Management QA <a href="mailto:jhutar@redhat.com">jhutar@redhat.com</a> Red Hat, Inc. </div></div></blockquote></div> </div>