On 10/12/10 11:21, Alex King wrote:
I am running squid on a Debian machine, Version: 3.0.STABLE8-3+lenny3 I have a situation where ubuntu updates are corrupted. The end users get a message about hash sum mismatches. If they re-try the update, squid delivers the same corrupted file. Yesterday they reported to me three specific files. I grabbed the three files (with wget) and confirmed they were corrupted. I then purged them from the cache and re-fetched them, and got the correct file. The corrupt and subsequent correct files are the same size. I inspected each of the three cases with vbindiff, and in each case the corruption is similar: the file sizes are identical, but there is one place where 32 consecutive bytes of data are corrupted. This happened neither at the beginning nor end, but at a different point in each case. This does not happen for every file downloaded, but often enough that many updates (of multiple files) or installs fail to work. I guess it could be a problem with the mirror site (http://nz.archive.ubuntu.com/ubuntu/), or it may be squid or something else on the local machine. An earlier version of squid (2.7.STABLE3-4.1lenny1) was also resulting in Hash Sum mismatch errors for the users. It's possible they may get corruption of other resources fetched via squid which I have not heard about. I am at a loss as to what to do next to locate the problem.
Upgrade to 3.1. Backports has a package which fixes the apt pipelining and range problems. If it still occurs the areas to look are at what apt does when a download is half complete and dies. Particularly what it requests out of Squid to resume the file.
Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.9 Beta testers wanted for 3.2.0.3
