Bug#499379: More on 'Hash sum mismatch' error
I get similar errors, for instance with apt 0.7.20.2 on amd64 but on a
variety of other versions too. apt-proxy is not involved. They are
present both with a Squid caching HTTP proxy and without. My
cron-driven updates usually see at least one instance of this error
every night.
They sometimes go away after a manual retry or three, making me wonder
if they are related to mirror update timing.
After a bit of further experimentation I see a lot of this in my squid log:
1240040566.029 55 172.17.207.18 TCP_REFRESH_UNMODIFIED/304 321 GET
http://security.debian.org/dists/lenny/updates/Release.gpg -
DIRECT/212.211.132.32 -
1240040566.186 45 172.17.207.18 TCP_REFRESH_UNMODIFIED/304 323 GET
http://security.debian.org/dists/lenny/updates/Release -
DIRECT/212.211.132.32 -
1240040566.515 37 172.17.207.18 TCP_REFRESH_UNMODIFIED/206 461 GET
http://security.debian.org/dists/lenny/updates/main/binary-amd64/Packages.bz2
- DIRECT/212.211.132.32 application/x-bzip2
i.e. Squid is serving from the cache instead of refetching. Once it has
actually done a refetch the 'Hash sum mismatch' error disappears.
So it looks like one of the following might be happening:
- the s.d.o web server is lying in its responses to requests
with If-Modified-Since
- squid is somehow mishandling If-Modified-Since
- apt is somehow mishandling If-Modified-Since
- some combination of the above!
I guess mirror skew between the s.d.o web servers could also cause it
though I've not fully thought this through.
I see from strace that apt is sending If-Modified-Since but the
timestamps look reasonably sensible to me, which is some evidence
against it being at fault.
It would be nice if apt reported what hash it expected and what it
actually got, as that would help tell whether it was the Release or
Packages file that it was getting an out-of-date copy of.
I'll try to gather more data next time it goes wrong.
ttfn/rjk
Reply to: