CRC check failed

[Ramon Diaz-Uriarte]

John, thanks a lot for your fast answer!!

On 11/6/06, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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/commands.py", line
623, in run_bzr_catch_errors
(...)
  File "/usr/lib/python2.4/site-packages/bzrlib/tuned_gzip.py", line
129, in _read
    self._add_read_data(self.decompress.decompress(buf))
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,

Best,

R.


> John
> =:->
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFT3irJdeBCYSNAAMRAiHpAJ9PRMGqs2jQO5CAaH7Tnb+VZvQQXACfTgW5
> ix9DPfDOtBHxCjnXSITn1p8=
> =mdWO
> -----END PGP SIGNATURE-----
>


-- 
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bzr.log.when.in.new.hd
Type: application/octet-stream
Size: 39766 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061106/434994fb/attachment.obj