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
