<div dir="ltr"><div>Additional info:  Populating the base channel, rather than having a child channel with the base package set, fixes this issue.<br><br></div>I would prefer to have the base channel empty, however, as we occasionally need to "version lock" a base package set and associated updates.  It's much easier to go back and forth when they are all child channels under a single empty base.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 8, 2014 at 9:08 AM, Michael Guidero <span dir="ltr"><<a href="mailto:mg@sococo.com" target="_blank">mg@sococo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'd like to state that my problem is identical.  We can successfully kickstart the same profile directly from our main Spacewalk server, it is only the proxy that fails.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 8, 2014 at 8:25 AM, Patrick Hurrelmann <span dir="ltr"><<a href="mailto:patrick.hurrelmann@lobster.de" target="_blank">patrick.hurrelmann@lobster.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08.12.2014 17:16, Paul Robert Marino wrote:<br>
> did you by any chance include the updates channel during the kickstart?<br>
> this is known to cause occasional conflicts. if the updates are in the<br>
> base channel thats fine because it will actually use the repomd file<br>
> from the installation disk instead of the one in the repo; however if<br>
> you have additional repos with updates added to the distro it will<br>
> utilize them and this often creates problems for the kickstart process<br>
> because anaconda is not as smart as yum about resolving potential<br>
> conflicts.<br>
> Your best bet is not to include any updates during the installation<br>
> then update immediately after the first boot.<br>
><br>
> Also you are better off using the base channel for the packages from<br>
> the installation disk. you can at your option also include the updates<br>
> in the base channel but if you do so they will be ignored during the<br>
> kickstart which is correct behavior.<br>
<br>
Yep, that are known issues. At least on 6, 7 works fine with update<br>
channels. But that's not the issue here. The 6 kickstarts do not contain<br>
any update channels and the kickstart works fine when performed<br>
directly. It only fails when kickstarting over proxy. And that is<br>
reproducible. Trying to reuse the logged GET request for downloading a<br>
rpm always fails on the proxy and succeeds on spacewalk itself.<br>
<br>
Regards<br>
<span><font color="#888888">Patrick<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Lobster SCM GmbH, Hindenburgstraße 15, D-82343 Pöcking<br>
HRB 178831, Amtsgericht München<br>
Geschäftsführer: Dr. Martin Fischer, Rolf Henrich<br>
<br>
_______________________________________________<br>
Spacewalk-list mailing list<br>
<a href="mailto:Spacewalk-list@redhat.com" target="_blank">Spacewalk-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/spacewalk-list" target="_blank">https://www.redhat.com/mailman/listinfo/spacewalk-list</a></font></span></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr"><br>Michael Guidero <br>Sococo IT <br><a href="tel:650-265-7013%20Ext%201000" value="+16502657013" target="_blank">650-265-7013 Ext 1000</a> <br><br></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><br>Michael Guidero <br>Sococo IT <br>650-265-7013 Ext 1000 <br><br></div></div>
</div>