CRC check failed

Ramon Diaz-Uriarte rdiaz02 at
Mon Nov 6 22:22:29 GMT 2006

John, thanks a lot for your fast answer!!

On 11/6/06, John Arbash Meinel <john at> wrote:
> Hash: SHA1


> > bzrs at ameiva:/Disk2/bzr-repositories/RJaCGH$ bzr check
> > bzr: ERROR: CRC check failed 3753648892 2779940560
> bzr doesn't use CRC's. It uses sha1 checksums, etc.

Thanks. I wasn't aware of that.

> So what you seem to be encountering is disk-level corruption. If you
> want to confirm something like this, on the machine you are getting CRC
> errors, try running:
> find . -type f -print0 | xargs -0 cat > /dev/null

I did that but the command run smoothly (apparently).

> Which should be trying to read the contents of all the files. My guess
> is that one of these will actually trigger the CRC error.
> Further, you could try to do this on both sides:
> find . -type f -print0 | xargs -0 sha1sum > ../SHA1SUM
> If you used rsync to copy things, the data should be identical on both
> sides. If you use bzr push/pull/branch, things may not be identical (one
> side could have unreferenced texts, slightly different sort order, etc).

This was strange: I did use rspush, I swear. But the SHA1SUM files
differ quite a bit between the origin and the destination.

In fact, the whole thing got even more strange: so I kept getting the
CRC thing, and right before formating the device, I did another bzr
check, and now I got a different error. Exactly the same error I get
when running bzr check in a backup copy of the repository in an
(apparently) OK HD.

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/bzrlib/", line
623, in run_bzr_catch_errors
  File "/usr/lib/python2.4/site-packages/bzrlib/", line
129, in _read
error: Error -3 while decompressing: invalid code lengths set

return code 3

I am attaching the log. I am not sure whether I should fill a bug
report, or if this is just a downstream consequence of the previous
problems and thus not really a bug.

> So CRC is usually an indication of a disk-crc check failure. Which is do
> to your setup. bzr is not generating the error itself. You can also look
> in ~/.bzr.log to see if there is any more information available.

Thanks. You are right: the log was showing a Python exception related
to IOError. I should have looked there before emailing.

Anyway, I guess it was a disk problem. Actually, we had to reboot that
machine earlier in the day because of some kernel oops (something
we've done for the first time in maaaany months).  I reformated the
disk (and got rid of encryption), I've been testing it (smartctl says
its OK), and after rspushing again, all bzr checks work fine.

Thanks again,



> John
> =:->
> Version: GnuPG v1.4.5 (Cygwin)
> Comment: Using GnuPG with Mozilla -
> ix9DPfDOtBHxCjnXSITn1p8=
> =mdWO

Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/octet-stream
Size: 39766 bytes
Desc: not available
Url : 

More information about the bazaar mailing list