>> We assume here that you have a working machine running NetBSD which
>> is of the same architecture as the machine you want to install.
> Hmmm... presumably becasue you are copying a binary off of the
> working system and onto the "target" system (in step 5)?

Well, cloning a NetBSD/foo system won't be much use if what you want is
a NetBSD/bar system. :-)

> Would endian-ness screw things up (assume m68k <-> i386, for example)
> if you tried to use dd(1)?  (I haven't yet explored the "ENDIAN"
> option in the kernel...)

Yes, cloning filesystems with dd will break if the hosts are of
differing endianness and the target kernel does not have FFS_EI.
(Whether the contents will be of any use even then is, of course, a
completely different question.)

> Hmmm... at this point, isn't my / really MFS?

md, I believe.  (They're both ramdisks, but rather differently done.)

> I'll have to verify restore is statically linked...

If it's in /bin or /sbin, it's supposed to be.

>> rsh <working system> /sbin/dump f0 - /dev/rwd0a |</path/to/restore> rf -
> I don't understand the role of "f0" arg to dump?

dump and restore, like tar, use the "magic first argument" argument
parsing technique.  "f -" specifies "dump to stdout", the "0" specifies
"do a level zero (full) dump".  On the restore side, "r" specifies
"restore", "f -" specifies "read from stdin".

> (sorry, I don't use it!)  <:-(

Me neither.  And unless it's been put through the Zwicky tests and done
better than any dump/restore she tested, I recommend you don't start.

> Perhaps I should archive a tarball to tape just to be safe... :>

Can't hurt. :-)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B