[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spacewalk-devel
Subject:    [Spacewalk-devel] Spacewalk 1.1 preparation
From:       mail () marcus-moeller ! de (Marcus Moeller)
Date:       2010-06-02 16:06:40
Message-ID: AANLkTilPXuyvhUgj18r0zLyd3wTUXuWxuLsS8q4uRPq4 () mail ! gmail ! com
[Download RAW message or body]

Hi Miroslav,

>>>>> I just edited Roadmap to better reflect reality.
>>>>> The last task for Spacewalk 1.1 is support for F-13, which will be nice
>>>>> to
>>>>> have.
>>>>
>>>> Could one also please take care of this one:
>>>>
>>>> http://www.mail-archive.com/spacewalk-list at redhat.com/msg04640.html
>>>
>>> Sounds like Anaconda problem to me...
>>> According to:
>>> ?https://bugzilla.redhat.com/show_bug.cgi?id=592985#c3
>>> you promised to check server side.
>>> Did anaconda sent request to Spacewalk. Do you see it in httpd access log
>>> of
>>> Spacewalk? Did Spacewalk sent 200 back?
>>
>> This problem cannot be verified without Spacewalk, that's why it's up
>> to you now :)
>
> I thought that this happen between Anaconda at F-13 and Spacewalk 1.0. Or why
> could not you reproduce it again?

The bug you mentioned is not related to Spacewalk. We did some tests
to make sure it is a Spacewalk problem before heading up here.

All information (logs and so on) I can provide can be found in the
thread on the spacewalk list. You can easily reproduce this issue by
adding a proxy= append (that points to a valid http proxy) to the
anaconda boot line.

Trying to retreive the kickstart file directly (via complete URL, not
via IP range) works fine.

Btw. as client tools are not available for F13 yet, we are testing
with the ones for F12 (which works so far).

Best Regards
Marcus



[prev in list] [next in list] [prev in thread] [next in thread]