bzip2: Compressed file ends unexpectedly
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LAVA Dispatcher |
Fix Released
|
High
|
Paul Larson |
Bug Description
Sometimes jobs seem to fail in the wget | tar bit that streams the tarball down to the board. We need to rethink how this work, and come up with a better long term solution, because there are many possible causes of what can happen here. We were once getting this because the tarball was truncated because it didn't exist completely on the server before it was downloaded. A corrupted tarball could also make this happen. Failing to get the whole tarball from the lava server (or any of it) could also cause it. So it's not easy to debug.
Here's an example:
http://
http://
http://
In these cases, I did some checking and found that the request never seems to hit the web server. I think what *could* be happening here is that the server is super-busy at that time and it's failing to connect before the default timeout for wget.
I've got a patch in-review now to increase the timeout of wget to see if this helps. If it does, then we'll know, if it doesn't help, then it shouldn't cause any issues. In the long term though, we should redesign how we stream the image down to the board.
Changed in lava-dispatcher: | |
status: | New → In Progress |
status: | In Progress → Fix Committed |
importance: | Undecided → High |
assignee: | nobody → Paul Larson (pwlars) |
milestone: | none → 2012.03 |
Changed in lava-dispatcher: | |
status: | Fix Committed → Fix Released |
I have not seen the patch source.
I just have a question about this, why we separate the pipe command to two steps wget and then tar uncompress?
Then we can know it is the wget (get from lava-server) error, or the download error(get from snapshot),
and we also can check the md5sum between the image in lava-server and in master image to make sure whether it is the wget problem. If it is the wget error, may be we can retry for some times.