[Spacewalk-list] Unable to kickstart via spacewalk proxy

[Michael Guidero]

Additional info:  Populating the base channel, rather than having a child
channel with the base package set, fixes this issue.

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.


On Mon, Dec 8, 2014 at 9:08 AM, Michael Guidero <mg at sococo.com> wrote:

> 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.
>
> On Mon, Dec 8, 2014 at 8:25 AM, Patrick Hurrelmann <
> patrick.hurrelmann at lobster.de> wrote:
>
>> On 08.12.2014 17:16, Paul Robert Marino wrote:
>> > did you by any chance include the updates channel during the kickstart?
>> > this is known to cause occasional conflicts. if the updates are in the
>> > base channel thats fine because it will actually use the repomd file
>> > from the installation disk instead of the one in the repo; however if
>> > you have additional repos with updates added to the distro it will
>> > utilize them and this often creates problems for the kickstart process
>> > because anaconda is not as smart as yum about resolving potential
>> > conflicts.
>> > Your best bet is not to include any updates during the installation
>> > then update immediately after the first boot.
>> >
>> > Also you are better off using the base channel for the packages from
>> > the installation disk. you can at your option also include the updates
>> > in the base channel but if you do so they will be ignored during the
>> > kickstart which is correct behavior.
>>
>> Yep, that are known issues. At least on 6, 7 works fine with update
>> channels. But that's not the issue here. The 6 kickstarts do not contain
>> any update channels and the kickstart works fine when performed
>> directly. It only fails when kickstarting over proxy. And that is
>> reproducible. Trying to reuse the logged GET request for downloading a
>> rpm always fails on the proxy and succeeds on spacewalk itself.
>>
>> Regards
>> Patrick
>>
>> --
>> Lobster SCM GmbH, Hindenburgstraße 15, D-82343 Pöcking
>> HRB 178831, Amtsgericht München
>> Geschäftsführer: Dr. Martin Fischer, Rolf Henrich
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
>
>
> --
>
> Michael Guidero
> Sococo IT
> 650-265-7013 Ext 1000
>
>


-- 

Michael Guidero
Sococo IT
650-265-7013 Ext 1000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20141208/00b98a36/attachment.htm>