Hi Steve: On Mon, Apr 12, 2010 at 19:10, Steve Langasek <steve.langa...@canonical.com>wrote:
> Right, that's the sensible thing to do and we should certainly get this > fixed - but in the *best* case, you're still waiting for 30 seconds or so > for a connection that's going to fail, right? Being able to avoid having > to > wait for *any* timeout, either with a preseed like Mario suggests or by > having the network configured accurately, would seem to shave ~3% off the > *pre-regression* install time, which I guess is nothing to sneeze at when > multiplied by N machines. > > Yes, I think fixing both the original bug that caused this increase in timeouts from continually failing the same server multiple times and a workaround preseed to not even attempt an apt-get update if you know it's going to fail would be a good idea. > Mario, any chance that a change to the DHCP server (i.e., not handing out a > default route) would be viable, and give you a short-term workaround while > this is being sorted? > I wish this were doable, but these servers are outside of the control from my group. As a short term workaround I suppose we can drop the non-functional route in an early script, but there may be implications for doing so for parts of the post-install process that used that route to communicate with process servers. -- System takes forever trying to contact uncontactable sources during install https://bugs.launchpad.net/bugs/556831 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
