puddledud

This activity was based on some work of Gregory K. Meyer which is available on the net and which looks at updating files and fixing errors in Mandrake iso downloads.


The problem I had was essentially the same that downloads of large Linux iso's were unreliable and I was looking for a method to deal with this problem of corrupted files.


The operating system we normally use for Internet access is Windows XP so I decided to try booting a live KNOPPIX disk to see if I could fix the problem using rsync.

Booting a KNOPPIX live DVD on the machine which usually runs XP I found that I had immediate access to the net as the Vigor2800 router stores the account settings - so far so good.

The Komander GUI was then used to mount the disk partition on which the iso was stored.

The partition was set to read/write in the Komander GUI. Right click the disk icon and select the option.

A commandline window was then opened and the directory was changed to the directory which held the iso.

At some point I created a test file using vi to see that I could write to the directory.

This command was then issued:

rsync -Pz --stats --inplace --ignore-times (continued on next line)
rsync://mirror.<provider address> (continued on next line)
fedora-linux-releases/9/Fedora/ppc/iso/Fedora-9-ppc-DVD.iso .

[the final <space> followed by a period instructs the update to occur in the selected directory]
[--ignore-times is an effort to get past short cut checking based on just the time stamp]

The command appeared to run to completion and gave stats on the data transferred etc.

When I checked the file with md5sum I got the result: ebaa71d96d38afe7c4ff33001d8c75f6

This is as it was - no change.

The checksum listed on the ftp server is given as: ff803781d4bf748a23dbfed812c592de78907739

If I burn the DVD and try to install it then the installer complains that the file is corrupt.

It seems that the file is actually not being updated even though it says it is.

I've seen reports that KNOPPIX doesn't deal with ntfs file systems.

I am aware of other postings using: rsync -av rsync options.

Anyone got any ideas on why no update appears to be taking place?

Would it all work if I moved the file to a device which was not ntfs formatted?

puddledud

Further exploration reveals the following:

I was using md5sum rather than sha1sum to calculate the checksum and this was the reason for the different checksum values. It had probably been correct for a long time - perhaps even from the beginning.

Knoppix 5.3.1 is a better alternative to Knoppix 5.1.1 which is what I started with. It identifies the hard disk partition as hda2 rather than sda2. The machine I'm using has 1GB RAM.

The mirror site I was using has some rsync options turned off - importantly --checksum.

Hence, I cannot say with certainty that the checksum was corrected but the technique is usable - certainly the time stamp of the file was updated after running rsync on the iso.

Ironically, the Fedora iso I was working on is still rejected as corrupt by the ppc installer.

Anyone using rsync should be aware that there might be a considerable delay between the time that the mirror sends an acknowledgement and the time that the output starts to appear on the screen but once it commences the download it all happens relatively quickly.

puddledud

It is a while since I posted this information and I had forgotten the details - even that I had made the posting.

But I came across the posting again by accident and am happy to note that the rsync technique still works well to overcome this particular corrupted file problem even in a foreign operating system environment.

On this occasion I used cwRysnc as the code source for the rsync utility and so was able to run it without first installing a live Linux.

After repairing the 5.4GB iso I had downloaded, as described in the earlier postings, I was able to verify that the file was now correct by generating a md5 checksum.