[Spacewalk-list] Unable to kickstart via spacewalk proxy

[Stephen Herr]

On 12/08/2014 03:12 AM, Patrick Hurrelmann wrote:
> I tried to debug this some more and I can confirm the findings of Rolf.
> I too use a master channel like centos-6x or centos-7x as parents with
> no packages assigned.
>
> Kickstarting using this channels fails with the mentioned "package not
> in mapping error". See log athttp://ur1.ca/j1pu7
>
> In this scenario the channels are setup the following:
> centos6.x-base
>   --> centos6.6-x86_64
>   --> centos6.6-updates-x86_64
>
> Kickstart tries to download the following rpm:
>
> broker/rhnBroker._initConnectionVariables('set self.rhnParent:
> http://proxy.example.com/ks/dist/centos6.6-x86_64/Packages/python-ethtool-0.6-5.el6.x86_64.rpm',)
>
> and tries to fetch locally first (before going up in the chain):
> broker/rhnBroker.__local_GET_handler('Retrieve from local repository.',)
>
> and then it tries to cache the rpm using the parent channel:
>
> broker/rhnRepository.getPackagePath('python-ethtool-0.6-5.el6.x86_64.rpm',)
> broker/rhnRepository._cacheObj('package_mapping:centos6x-base:',
> '20130308120245', ())
> broker/rhnRepository._getPkgListDir('/var/spool/rhn-proxy/list',)
> broker/rhnRepository.getPackagePath('ERROR', 'Package not in mapping:
> python-ethtool-0.6-5.el6.x86_64.rpm')
>
> Imho there is no fallback to the lower channel (which contains rpms).
> The same is happening for centos7 kickstarts due to the same channel layout.
>
> For testing I cloned my centos-6.6-x86_64 channel and made it a
> standalone top-level channel and kickstarting is working again.

Thanks for the great investigative work Patrick, Rolf, and Michael, I 
have created a bz to track this problem:
https://bugzilla.redhat.com/show_bug.cgi?id=1172738

Interested parties can add themselves to the CC list.

-Stephen