CRC check failed
rdiaz02 at gmail.com
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 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
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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 39766 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061106/434994fb/attachment.obj
More information about the bazaar