I'm duplicating a drive with the following command:

However, I'm getting the following:
write: No such device or address
132868+0 records in
132868+0 records out
blah blah blah

Is using DD to make an IDENTICAL copy a bad idea? Can anyone tell me why I'm getting these errors? Is this likely to work once dd completes?

EDIT: Didn't read properly...

Are you working on SPARC or x86 hardware ?
Are there mounted partitions on the source disk ?

SPARC. The source disk is entirely 100% blank, as in straight out of the packaging. I reckon it will work, I've done something similar before and got a perfectly 100% identical drive (this was actually a bad thing as I DD'd 9gb onto a 180gb drive, hehe - it worked though).

Also there aren't any mounted partitions at all, I'm running safe mode off the cd, I think mounting and then running DD is a bad idea. Guess we shall see! It's been going for about 4 hours now and has done 2 slices, both with the error mentioned above.

Did you duplicate the vtoc first (prtvtoc | fmthard) ?
Why aren't you just copying slice 2 which encompass the whole disk ?

I was under the impression the VTOC was on the first slice (slice 0) on the first cylinder and thus would get copied with dd, perhaps I'm wrong though. If slice 2 is the whole disk then this will take twice as long as it should do wont it... Oops! Should I just miss out the 2 in my if statement and start over? These "no such device or address" errors, are they anything to worry about? Do you think this will work once complete?

Indeed. The vtoc isn't in slice 0, slice 0 isn't including the first cylinder, slice 2 does. Outside slice 2 which overlap the whole disk, remaining slices aren't necessarily numbered the way they are ordered.
Indeed.
Better dd'ing only slice 2.
They is certainly something to worry about with such errors. Probably due to the wrong vtoc on the target device.
I'm quite skeptical.

1 members found this post helpful.

I've just been reading through the following webpage (here) which does exactly as you suggest, just dd the second slice. I don't think this process will fail but it will take significantly longer than it should do. The author even suggests duplicating the second slice in the first paragraph, so I'm pretty confident this will work.

I've got a few servers to do, so on my second server I'll make sure I do as both you and the author have suggested and just dd the second slice.

Thanks for your help, I'll mark this page as complete tomorrow if it finishes properly. I think the errors are either due to slices being used for swap (possible) or slices not existing on the new disk (also possible) rather than actual problems with the process.

Your process will fail if slices 3 to 7 exist on the target drive and aren't located exactly where their source are.
This is a write error so I hope you aren't writing to an active swap partition, which might lead to various crashes up to kernel panics. Nonexistent slices are more likely. Next time, use a larger block size than 1024. Such a low value explains why it is so slow now.

1 members found this post helpful.

Running this:
dd if=/dev/dsk/c0t0d0s2 of=/dev/dsk/c0t1d0s2 bs=2048 conv=noerror,notrunc

No errors I think using sync was a bad idea, I didn't and still don't really understand what conv=sync does, but it's got rid of the errors. When googling sync I've seen it used numerous times when duplicating DVDs/CDs.

I'll leave this running over night and let you know how I get on tomorrow.

Thanks for your help.

Any other ideas on how to do this? It's taking a loooong time to copy a 9gig drive, the systems a 220R and is VERY low spec but it's still taking a stupidly long ammount of time.

How long is "a loooong time" ?
What data r/w rate are you observing (eg: what says "iostat -xntc 5 5")?

Well it's a 9gb disk and has been going for around 3 hours or so, as this is single user mode I can't issue commands to check on the status. I left it running overnight but it was still in the same state in the morning so restarted with a higher block size? Should this be /dev/dsk and not /dev/rdsk? I'm happy to leave it running for longer, but if there's a reason it's taking so long then I'd like to eliminate it, otherwise I can just wait for it to complete.

Why don't you launch the dd in the background or put it there with ^Z + bg ?
That will give you a chance to investigate where the bottleneck is. I would expect copying 9 GB to take minutes, not hours or days. Stay with rdsk which should be faster than dsk as the cache is bypassed.

try bigger block size. bs=128k or 256k that should speed up the process.