Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Yesterday I reinstalled Ubuntu 13.04 64-bit on my computer (4GB RAM), and for the first time I decided to use Full Disk Encryption (all default settings).

Today while running backups my computer crashed twice.

Now I continued to work on my backups and when checking the hash of a backup of mine I found out that sha256sum showed a wrong result for a big file.

I skimmed over /var/log/syslog and I did not find any error, and the Disk utility also says that the Disk is OK.

I tried to reproduce that error, and for small files I didn't have this problem, but for big files I do:

$ dd if=/dev/zero of=zeroes bs=1M count=4000 && sha256sum zeroes && sha256sum zeroes
4000+0 records in
4000+0 records out
4194304000 bytes (4,2 GB) copied, 54,0345 s, 77,6 MB/s
ad6637bd22568145039a053da5cbf4c31d3eda5ef95c29646fa66b0cacd15a8c  zeroes
8ea0d0c9ad97de182335e98045a1f197456ceee782fa6e801fd3e68bea4d35d3  zeroes

$ md5sum zeroes && md5sum zeroes 
8097877e1c991721dae7ffe228ae2f5a  zeroes
fbd1e7fcd3861446310c87abf72066bf  zeroes

This is really bad if I can't rely on any of my data, so I would really appreciate if somebody could help me out finding out what the problem could be.

share|improve this question
Please run a full memtest ( It's very likely that your memory is corrupting here. Please also try to run the same test in a tmpfs partition (ramdisk) with a smaller file (say 25% of RAM). If it still happens on a tmpfs, then you're sure you have to replace your RAM. – gertvdijk Aug 15 '13 at 15:03
Thanks gertvdijk, you were right, one of my 2 RAMs was defect, and it was just a weird timing coincidence that after switching to full disk encryption having random errors (not from the file system but from the RAM). – Christian H. Aug 15 '13 at 17:24
Good to hear you found the error. I've provided it as an answer now. – gertvdijk Aug 15 '13 at 19:17
up vote 2 down vote accepted

You're looking at a hardware issue here. Memory in consumer hardware lack integrity checks (ECC), so errors in the memory go mostly undetected at system level. As you noted you were seeing crashes too, and that is to be expected if memory is faulty.

By running a memtest on your system you can verify this. Memtest with Ubuntu 12.04 live CD

You'll now also have to verify all backups as I/O goes through memory it's likely that backups made with this faulty RAM are corrupted too. Note that is can be slightly corrupted and hard to spot.

share|improve this answer

Nicely found :D

Reproduction failed in my environment. (ofcourse)

I have 4G ram, but my coreutils[1] is version 8.13 (yours 8.20), and my disk is NOT encrypted.

I assume this problem did not exist before 13.04, because such a problem does not go unnoticed. So I looked at the changelog:

Then I saw a patch that might be related to this problem:

coreutils (8.13-3.2ubuntu6) raring; urgency=low

  • Backport upstream patch to avoid data-corrupting free-memory-read in cp/mv/install when dealing with a very fragmented and sparse input file on certain filesystems (LP: #1073514). * Build-depend on valgrind in order to be able to run the test for the above fix.

  • Fix 99_sort_-u_data_loss.dpatch so that the added test is actually run.

Can you test the same with version 8.13 of coreutils? (If I have the time I'll test it myself)

Just in case, exactly did you encrypt your computer?

If you want to further investigate this problem, then the changelog is very usefull. It can also be that another patch broke something.

[1]: md5sum and sha256sum are from the package GNU coreutils

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.