Comment 1 for bug 954197

Revision history for this message
Colin Watson (cjwatson) wrote :

This is a complex problem that has been known in the Debian installer since at least 2004. I'm going to try to break it down here in the hope of making some progress on it.

1. Download error handling in debootstrap is arranged wrongly

  In particular, it doesn't deal correctly with corrupted files, and will tend to muddle on until something fails as a consequence of the corruption. In some cases it's possible for debootstrap to complete successfully despite a corrupted download! There's a patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618920 that improves things, although I've been working on a better version of it.

2. No retry option

  As Joey notes in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283600, there's only a fairly limited communication channel between debootstrap (which is a separate tool invoked by the installer to do the hard work) and the parts of the installer that can actually interact with the user. This means that it's hard to set up a "retry" option that just retries a single download, because debootstrap doesn't wait for user interaction on errors and it would be a substantial amount of work to rearrange it to do so.

  What we might be able to do is as follows: if debootstrap fails at the retrieval stage before it actually starts unpacking anything, then we could offer an option that simply tries the whole thing again, keeping the previous contents of /target (so that would also preserve anything you'd wgetted by hand, but it would also try to redownload any other missing files for itself). This is a little less neat, but would do the job. In fact, if we borrowed some ideas from net-retriever, we could even let you choose a different mirror.