On 06/10/2011 12:39 PM, Chris Lalancette wrote:
On 06/10/11 - 10:03:16AM, Steven Dake wrote:
> On 06/10/2011 09:00 AM, Steven Dake wrote:
>> On 06/10/2011 07:29 AM, Chris Lalancette wrote:
>>> On 06/09/11 - 01:09:17PM, Steven Dake wrote:
>>>>> Before doing that, though, I think I would like to try watching the
CD-ROM for
>>>>> activity. If that does the trick, I'd much rather go that route
than
>>>>> increasing the timeout.
>>>>>
>>>>> I'll whip up a patch for you to test tomorrow.
>>>>>
>>>>
>>>> sounds good i'm happy to test it out.
>>>
>>> Attached is a patch which I think should do the trick. At least, it should
>>> be monitoring the CD for activity as well as the destination disk image.
Let
>>> me know if this improves the situation for you.
>>>
>>> Thanks,
>>>
>>>
>>
>> Same problem occurs. I'll spend a bit of time debugging to see if
>> BlockStats is behaving as expected by the patch and see if I can sort
>> something out.
>>
>
> I added a debug log when the following values are set. They don't
> appear to change after the image install starts even as it is "counting
> up" from 0 to 100%. The first is the first device (vda) the second is
> the second device (hdc).
>
> rd_req 334 rd_bytes 1368064
> rd_req 1168 rd_bytes 138235904
>
> The value of rd_bytes starts at 0, then increases a bit during the
> install process, then jumps to this 13mb value when the image loading
> starts.
Yeah, OK. As we discussed on IRC, this is probably because you are doing
a URL based install from a far-away location, and it is taking more than
5 minutes to fetch the second anaconda stage. The attached patch monitors
the network for activity as well; can you give it a whirl?
Thanks,
No go on this patch - this version fails:
oz.OzException.OzException: No disk or network activity in 300 seconds,
failing