[Spacewalk-list] Parent/Child channels and software availability?

Tue Apr 5 03:44:51 UTC 2016

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 <avi.miller at oracle.com> 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 <datakid at gmail.com> 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 <avi.miller at oracle.com> 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 <datakid at gmail.com> 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 <avi.miller at oracle.com> 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 <datakid at gmail.com>
>>> 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
>>> > Spacewalk-list at redhat.com
>>> > 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
>>> 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
>>
>>
>> --
>> 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
>> 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
>
>
> --
> 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
> 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/20160405/a5626d19/attachment.htm>