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