OK. <goddamn>. It is not true, *in at least my set up*, that the base channel can be empty.
Without any packages in the base (parent) channel, and a child channel called _base that is fully populated, the kickstart fails with the error message: Error the following error occurred while installing. This is a fatal error and the installation will be aborted. error populating transaction after 10 retries. failure: Packages/newt-<version> from anaconda erno 256 no more mirrors to try If I add the single package newt to the base (parent) channel, the installation succeeds. (!wtf!). Note that in the above scenario in which the installation fails, the newt-<version> package is available in the respective child channel that is the base. Strangely, if you look at the packaging.log on a failed install (because there is no newt-<version> package in the base channel, it has found the newt package: 02:25:28,285 DEBUG yum.verbose.YumBase: TSINFO: Marking newt-0.52.15-4.el7.x86_64 as install for 1:NetworkManager-tui-1.0.6-29.el7_2.x86_64 02:25:28,286 DEBUG yum.verbose.YumBase: Quick matched newt-0.52.15-4.el7.x86_64 to require for libnewt.so.0.52(NEWT_0.52.6)(64bit) 02:25:28,286 DEBUG yum.verbose.YumBase: Quick matched newt-0.52.15-4.el7.x86_64 to require for libnewt.so.0.52(NEWT_0.52.13)(64bit) 02:25:28,286 DEBUG yum.verbose.YumBase: Quick matched newt-0.52.15-4.el7.x86_64 to require for libnewt.so.0.52(NEWT_0.52)(64bit) 02:25:28,286 DEBUG yum.verbose.YumBase: Quick matched newt-0.52.15-4.el7.x86_64 to require for libnewt.so.0.52()(64bit) 02:25:28,367 DEBUG yum.verbose.YumBase: TSINFO: Marking newt-python-0.52.15-4.el7.x86_64 as install for authconfig-6.2.8-10.el7.x86_64 02:25:37,695 DEBUG yum.verbose.YumBase: TSINFO: Marking slang-2.2.4-11.el7.x86_64 as install for newt-0.52.15-4.el7.x86_64 02:35:26,928 ERR packaging: error populating transaction after 10 retries: failure: Packages/newt-0.52.15-4.el7.x86_64.rpm from anaconda: [Errno 256] No more mirrors to try. 02:35:26,929 DEBUG packaging: http://emts-res-utils1/ks/dist/org/1/Centos_7/Packages/newt-0.52.15-4.el7.x86_64.rpm: [Errno 14] curl#18 - "transfer closed with 33634 bytes remaining to read" Also interesting in the same log is that there seems to be an attempt to connect to some very strange urls: it's taking the last dirname from my Tree name, and plonking it on the end of the regular url http://emts-res-utils1/ks/dist/ , concatenated with the word child and the child repo name. Note that the usual 1 that happens after the dist is missing. Is this meant to be how it works? Also, why is there space for a proxy setting? 02:25:16,600 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/epel_7_x86_64/Centos_7 (proxy: ; sslverify: True) 02:25:16,627 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/mariadb_x86_64/Centos_7 (proxy: ; sslverify: True) 02:25:16,652 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/slurm_15.08/Centos_7 (proxy: ; sslverify: True) 02:25:16,679 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/cntlm-0.92.3/Centos_7 (proxy: ; sslverify: True) 02:25:16,705 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/slurm_16.05/Centos_7 (proxy: ; sslverify: True) 02:25:16,728 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/spacewalk_x86_64_client/Centos_7 (proxy: ; sslverify: True) 02:25:16,750 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/centos_7_x86_64_base/Centos_7 (proxy: ; sslverify: True) 02:25:16,776 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/cisco_snic_x86_64/Centos_7 (proxy: ; sslverify: True) 02:25:16,802 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/zabbix_x86_64/Centos_7 (proxy: ; sslverify: True) 02:25:16,827 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/centos_7_x86_64_updates/Centos_7 (proxy: ; sslverify: True) 02:25:16,851 DEBUG packaging: retrieving treeinfo from http://emts-res-utils1/ks/dist/child/centos_7_x86_64_extras/Centos_7 (proxy: ; sslverify: True) While I now have a working system, to be honest, there is too much unexplained black magic happening in here for me to feel safe. Cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 4 April 2016 at 13:23, Avi Miller <[email protected]> wrote: > Now that is counter-productive. If this is on the Spacewalk wiki, just > edit it yourself. :) > > On 4 Apr 2016, at 1:09 PM, Lachlan Musicman <[email protected]> wrote: > > It's true, although other documentation clearly states "remove the rpms > once the tree has has the ISO added". > > > > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > > On 4 April 2016 at 13:00, Avi Miller <[email protected]> wrote: > >> It's only something I worked out recently while working with CentOS as a >> kickstart distro for the first time. >> >> Note that our (Oracle) documentation only documents how to use an ISO as >> the kickstart distribution, so this issue isn't seen in that instance, >> because the base packages are available on the ISO alongside the boot >> images. Using an ISO as the kickstart distribution avoids this issue >> completely. >> >> >> On 4 Apr 2016, at 12:29 PM, Lachlan Musicman <[email protected]> wrote: >> >> Ok, thank you. >> >> That should be very clearly stated in the docs. Probably in a pull quote. >> >> Cheers >> L. >> >> ------ >> The most dangerous phrase in the language is, "We've always done it this >> way." >> >> - Grace Hopper >> >> On 4 April 2016 at 11:46, Avi Miller <[email protected]> wrote: >> >>> Hi, >>> >>> Spacewalk doesn't actually enable the parent channel during kickstart. >>> It uses the kickstart distribution and whatever packages are available via >>> the ISO. If you're using a stripped distribution (i.e. the just the boot >>> images, no packages/repodata) then it doesn't work at all. You need to add >>> the full base channel into the kickstart distribution for this to work. >>> >>> I've just been through this myself, as it happens. >>> >>> Cheers, >>> Avi >>> >>> > On 4 Apr 2016, at 11:17 AM, Lachlan Musicman <[email protected]> >>> wrote: >>> > >>> > Hi, >>> > >>> > I've got a strange error that I think someone mentioned here recently >>> but I can't see it in a google search just now. >>> > >>> > >>> > I create a Parent channel, and associate it with a repository, then >>> add child channels and associate them with their appropriate repositories. >>> > >>> > I create the Activation key, associate it with the Parent Channel, >>> create the kickstart profile associated with the channel etc etc. >>> > >>> > When I boot, I get the error : >>> > >>> > You have requested that the package 'x' should be installed. This >>> package does not exist. Would you like to ignore this package and continue >>> with the installation?' >>> > >>> > (in this case x= hwloc-devel, but I think that's irrelevant' - if I >>> answer yes, it just asks for every package) >>> > >>> > When I search the Parent Channel for the software in question, it is >>> definitely in there. (see attachment) >>> > >>> > This is annoying and stops my installation. >>> > >>> > Interestingly, if I create a Child Channel, called centos_7_base, >>> which is the base install (ie, exactly the same as the Parent - associated >>> with the same repo!), then the installation works fine. For some reason, >>> the ks profile can see the packages in the child channels but isn't seeing >>> any in the parent channel. >>> > >>> > Am I wrongly envisioning what the Parent Channel is? Should the parent >>> not have a repo/set of packages? >>> > >>> > How might I trouble shoot this - where are the logs, which commands >>> are failing? >>> > >>> > If I disassociate the Parent Channel with any repos, will this cause >>> any issues? >>> > >>> > Cheers >>> > L. >>> > >>> > >>> > ------ >>> > The most dangerous phrase in the language is, "We've always done it >>> this way." >>> > >>> > - Grace Hopper >>> > <Screenshot from 2016-04-04 >>> 11-12-09.png>_______________________________________________ >>> > Spacewalk-list mailing list >>> > [email protected] >>> > https://www.redhat.com/mailman/listinfo/spacewalk-list >>> >>> -- >>> Oracle <http://www.oracle.com> >>> Avi Miller | Product Management Director | +61 (3) 8616 3496 >>> Oracle Linux and Virtualization >>> 417 St Kilda Road, Melbourne, Victoria 3004 Australia >>> >>> >>> _______________________________________________ >>> 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 >> >> >> -- >> Oracle <http://www.oracle.com> >> Avi Miller | Product Management Director | +61 (3) 8616 3496 >> Oracle Linux and Virtualization >> 417 St Kilda Road, Melbourne, Victoria 3004 Australia >> >> >> _______________________________________________ >> 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 > > > -- > Oracle <http://www.oracle.com> > Avi Miller | Product Management Director | +61 (3) 8616 3496 > Oracle Linux and Virtualization > 417 St Kilda Road, Melbourne, Victoria 3004 Australia > > > _______________________________________________ > 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
