PDA

View Full Version : Input/output failure cloning to USB drive



erd
11-30-2004, 07:57 PM
I'm very much a Linux beginner.

I'm also aware that there are an awful lot of queries posted regarding drive cloning. However, so far I have not found anything that helps with the following issue.

I'm booting into the current version of Knoppix (3.6?). I'm attempting to clone a win98 se internal drive (boot) to an external Archos 20 Gigabyte hard drive. Drive capacities appear to be identical.

Procedurally, I unmount both hard drives, and make the USB drive writeable in the GUI, shell out to console, log on as root (su + passwd), and use the dd command with if and of specified to point to the drives. Everything goes smoothly for the first ten minutes (I'm using USB 1.1 so this is not a speedy operation) then I get an input-output error message at the console and the operation terminates.

If I boot back into Windows and look at the files, the root structure has been created, with all directories and files visible and apparently soundly copied and correctly named. However, if I look into some of the directories, though most are empty, some have cryptically named files and sub-directories (where none should exist). Clearly the cloning process has worked OK at root but I'm troubled by these nonce files.

My questions are:

1. Am I doing something stupid on the command line initially that's causing the termination? OR

2. Are these errors (the input/ouput failure, the odd files and subdirectories likely simply a manifestation of a write failure?

I should say that the drive communicates fine under Windows and I can (for example) do a full multi-hour system file-for-file backup using Dantz Retrospect. However, my backup preference is a bootable clone on the USB drive. This seems better done with Knoppix than any of the Windows utilities out there.

One thing that occurred to me is that perhaps the drive capacities are not exactly equal (though they appear to be). If this is a potential issue, is there a workaround that copies simply files, not blank space (which, I believe, cloning also copies)?

Ted.

Markus
11-30-2004, 09:36 PM
Not sure what's wrong there but I replaced my hda just yesterday by making a slightly larger ntfs partition on the new drive, plugged it in and while booted into live-cd used dd if=/dev/hda of=/dev/hdb and after 55 minutes it was done and the new disk then as hda worked just fine. Later on I added more partitions as the new disk is larger.
Perhaps you have USB 1.1 and it can't write as fast as dd puts out? All in all it must take hours to finish.


Procedurally, I unmount both hard drives, and make the USB drive writeable in the GUI I don't think you have to make it writable, certainly it shouldn't be mounted.
I also dropped down to Ctrl-Alt-F2 and did init 3 to free some memory for the process.


One thing that occurred to me is that perhaps the drive capacities are not exactly equal (though they appear to be). If this is a potential issue, is there a workaround that copies simply files, not blank space (which, I believe, cloning also copies)? The target needs to be at least as big as the source. dd copies bit by bit, if you want just files and not free space you need to use something else.

erd
12-01-2004, 03:22 AM
Thank you, Markus. There are several helpful suggestions in your letter. I am starting to think that the issue really is the equivalence of drive sizes. Maybe if I repartition the boot drive so it is smaller this might go more smoothly. The experiment may be worthwhile. However, I'll try freeing some more memory as you suggest in case this is a factor.

Ted.