> Yes, I'm assuming you have a working system with a full set of 
>binaries for the machine you want to clone.  Note that you may have an
>install housed on a machine which itself is not the machine running the
>installation, i.e. an NFS server serving a bunch of diskless clients.  In
>this instance, it's OK to copy the binaries from the NFS server to the
>client, the machine you're turning into a clone of the other, without
>worrying about the endianness of the NFS host.  For example, you have I386

Ah, yes.  Good point!  I tend to let each type of machine hold
binaries specific to that machine.  The only place things tend
to "mix" is on my tape server (for obvious reasons)

>binaries housed on a Sparc NFS server, that you want to copy to another
>I386 host.  As long as the I386 binaries are fully self contained in their
>own filesystems, you can dump |restore from the Sparc to the I386 with no
>ill effects.  Dump and restore take care of any necessary byte swapping.


OK.

>>>7.  Create a symlink from /tmp to a new /tmp directory on your newly
>>>mounted /mnt partition.
>>
>>Hmmm... why?  Oh, perhaps restore likes to scribble there
>>as a staging area?
>Yes, it does, and the mfs filesystem doesn't contain enough space
>for these scribbles.

OK.

>>I don't understand the role of "f0" arg to dump?  (sorry, I don't 
>>use it!)  <:-(
>
>It means dump the entire filesystem, level 0, to file "-" which in turn
>means standard output.


OK.

>>If you have more than one filesystem on the working system that you
>>want to clone, make sure you dump each one in turn.  Before you dump, be
>>sure to cd to the directory on your new system where the filesystem was
>>mounted on the working machine.  For example, if you have /usr on the
>>working system, and it is a different filesystem from /, then cd /mnt/usr
>>on your new system before running the dump |restore pipe as shown above.


Yes, understood.

Thx!
--don