Problem on Fedora Core 4

Problem on Fedora Core 4

[Bargel Jazat]

I am having the following problem and I do not understand whether it is a 
hardware
problem or software.

I am running fc4 on an i386 desktop.

The first time the problem appeared like this: I mirrored some directories 
to
my second hard disk and when I made a diff

$ diff -ru <source dir> <target dir>

I found that the two subtrees were not the same. A few binary
files were different, one text file differed in exactly one character.

The copy was made with rsync, can it be a bug with rsync?
Anyway, I got convinced that it may be a hardware problem (the second hard 
disk
is rather old) and moved everything out of the "bad disk".

But then the problem came out again:

I copied a file from my laptop to the desktop. I copy everything to the 
_new_
hard disk, which is hopefully ok.
It is a long tar/gzip archive (1.4 GB). I also copied a MD5SUM of the file 
and
when I verified the MD5SUM I got an error. In fact the archive was corrupted
and wouldn't unpack.

Problem with rsync? Or with ssh (the problem also occurs with scp)?

Next trial was to split the file in small files, send them individually 
together
with their MD5SUM, verify them, and combine them into the original tgz.
When I verify them I see that some of them are not ok. So I transfer those 
files
again. And here I get some very strange:

I run md5sum -c ...
I get an error.
I run md5sum -c ...
again on the same file, it verifies OK!

Now I am totally confused, how can this be? This means that the _same_
file had different content after 10 seconds.

Can this be some hardware problem? Maybe the disk controller?

Thanks for any suggestion
Giorgio

Re: Problem on Fedora Core 4

[Adam T. Bowen]

Hi,

Bargel Jazat wrote:
[snip]
> The first time the problem appeared like this: I mirrored some 
> directories to
> my second hard disk and when I made a diff
> 
> $ diff -ru <source dir> <target dir>
> 
> I found that the two subtrees were not the same. A few binary
> files were different, one text file differed in exactly one character.

Do the files change size or just content?  Can you send an example diff?

> The copy was made with rsync, can it be a bug with rsync?
[snip]
> I copied a file from my laptop to the desktop. I copy everything to the 
> _new_
> hard disk, which is hopefully ok.
> It is a long tar/gzip archive (1.4 GB). I also copied a MD5SUM of the 
> file and
> when I verified the MD5SUM I got an error. In fact the archive was 
> corrupted
> and wouldn't unpack.
> 
> Problem with rsync? Or with ssh (the problem also occurs with scp)?

Newer versions of rsync are configured by default to use scp so it could 
have been a problem with that, but you say you did a 'mirror' of your 
hard disk.  I am presuming you used a back to back tar to do that?  If 
so then it can't be a problem with any one of these packages.

> Next trial was to split the file in small files, send them individually 
> together
[snip]
> I run md5sum -c ...
> I get an error.
> I run md5sum -c ...
> again on the same file, it verifies OK!

A rootkit could cause that sort of a problem I suppose.  Some of them 
modify checksum programs (badly).  I have used this rootkit checker before:

       http://www.chkrootkit.org/

> Now I am totally confused, how can this be? This means that the _same_
> file had different content after 10 seconds.
> 
> Can this be some hardware problem? Maybe the disk controller?

I would virus and rootkit scan the computer for starters.  If you don't 
find anything then try just copying a whole load of files from one 
directory on the suspect disk to another on the same disk and then diff 
those.  If that causes errors then I suppose it could be a fault with 
the disk or controller.  Is the disk your root disk?  If so then I would 
expect the OS to be pretty unstable too.  It could also be an OS 
problem.  You could try booting with a rescue CD such as Knoppix and do 
the same tests and see if the files still get corrupted.  If so, then 
the case for faulty hardware is strong.  If not, then you could try 
reinstalling/repairing the OS.  FC4 is pretty bleeding edge, so it could 
be that you reinstall the OS and still get the same problems.  In that 
case you could try a different distro I suppose.

Sorry I can't be more help.

Cheers

Adam


> Thanks for any suggestion
> Giorgio
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem on Fedora Core 4

[GH Snijders]

Bargel Jazat <jbargel <at> hotmail.com> writes:

> 
> I am having the following problem and I do not understand whether it is a 
> hardware
> problem or software.
> 
> I am running fc4 on an i386 desktop.
> 
> The first time the problem appeared like this: I mirrored some directories 
> to
> my second hard disk and when I made a diff

[snip MD5 errors]

Perhaps you should try a memtest (in addition to the other message(s)).

It's usually quite hard to get corrupt data from a harddrive without getting
*loaded* with errors; i've seen enough defunct harddrives, but i've never been
able to read from them without getting a lot of errors.
That's why i think i suspect the memory (RAM).

Check out memtest86 (http://www.memtest86.com/).


HTH, HAND


mvg,
   Guus