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 On Thu, 13 Jun 2013 19:52:15 -0700 Ian Forde <[email protected]> wrote: > (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 > <[email protected]>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ř > > <[email protected]> wrote: > > > On Mon, 3 Jun 2013 23:41:14 +0000 Faye Salwin > > > <[email protected]> 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 > > > [email protected] Red Hat, Inc. > > > > > > _______________________________________________ > > > 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 > > -- Jan Hutar Systems Management QA [email protected] Red Hat, Inc.
pgpbQKWifg2Hu.pgp
Description: PGP signature
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
