Error during update

[Ian Francis]

W:Failed to fetch gzip:/var/lib/apt/lists/partial/mirror.as29550.net_archive.ubuntu.com_dists_trusty_main_binary-i386_Packages Hash Sum mismatch
, W:Failed to fetch gzip:/var/lib/apt/lists/partial/mirror.as29550.net_archive.ubuntu.com_dists_trusty_universe_binary-i386_Packages Hash Sum mismatch
, E:Some index files failed to download. They have been ignored, or old ones used instead.

[Brian Murray (brian-murray)]

This may be an issue with your mirror, try using a different one.

[Brian Murray (brian-murray)]

If it still doesn't work with a different mirror use 'apport-collect 1311652' to add more information to the bug report.

[Ian Francis (iffy1960)]

Hi, Sorry, but I do not know how to use a different mirror. The update is automatic, I have not had to enter any information, so would not know how to change it. Please can you advise? Thanks

[Alex Muntada (alex.muntada)]

I'm running an official mirror (http://ftp.caliu.cat) and i've been struck with this issue too when upgrading from precise to trusty.

I've been trying to figure out whats the problem since this afternoon and this is the summary:

* changed the way we updated our mirror from our own rsync recipe to the ubumirror package (no change);
* used https://github.com/marblenix/fix-apt-mirror-hash-sum-mismatch to make sure that the files in our mirror were up to date (no change);
* downloaded the offending files with wget from both archive.ubuntu.com and ftp.caliu.cat, compared them and were exactly the same;
* search our nginx log files for errors: the only surprise was that offending files are downloaded as partial content (http 206) and sometimes ranges fail (with http 416);
* figured out that the only difference between country level archives and our own is that ours uses nginx and the others apache;
* it happens that mirror.as29550.net uses nginx too.

I'm not sure yet, but i'm afraid that there's been some change in the way apt manages files (trying to fetch partial content in some cases) and some servers fail to work correctly making apt complain about the network. Does this makes any sense?

[Ian Francis (iffy1960)]

I found out how to change the mirror.

I changed it to the United Kingdom mirror, and the upgrade seems to have worked correctly now.

[Wei Mu (mw2010a)]

I'm running a local mirror for my university and I've met the same problem.
I thought it was hard disk problem so it took me about a week before I finally figure out the reason.
I did a lot of test, read through RSYNC logs and contacted with upstream mirror.
I've come to the conclusion that it was caused by filesystem error in the upstream.

The interesting point here is that:
RSYNC CANNOT FIX CORRUPTED FILES if they have the SAME TIMESTAMP and SIZE but are wrong in content.

There are at least two ways to fix this problem.
* Manually download the corrupted files (most of them are .bz2 index files in my case) through http.
  However, there's no way you can figure out how many files have been damaged before.
* Use rsync --checksum option to fix the whole archive.
  But as far as I know most mirror sites refuse -c option because of cpu consumption.
  I managed to fix the problem by rsync -c with official archive.ubuntu.com.
  Be aware, connection may be closed if too many files are being compared with checksum,
  so I wrote a script to rsync smaller sub-folders in traversal way:
ubuntu/dists/devel
ubuntu/dists/devel-backports
...
ubuntu/pool/main/a
ubuntu/pool/main/b
...
ubuntu/pool/universe/a
ubuntu/pool/universe/b
...
ubuntu/pool/multiverse/a
ubuntu/pool/multiverse/b
...
ubuntu/pool/restricted
ubuntu/indices

Hope this may help for mirror sites.

[Wei Mu (mw2010a)]

According to the rsync man page, rsync does not cause hash-checksum-mismatch problem, because rsync uses atomic operations for files by default.
So if mismatch problem occurs, there might two reasons:
* Network caching problem in http (for users of Ubuntu)
* Some serious problem with upstream mirror or disk (for mirror sites)

In most occasions, network caching is the reason for this problem.
Some ISPs are using network caching machanism to redirect frequent downloaded links.
If you use wget to repeat the process, you may see a 302 redirection, then this might be the reason for the problem.
Try to use another mirror until everything looks fine.