> For security I then tried to install my one setup onto the second
> drive (which I believe I formatted a year ago when I had access to a
> SunOS system).

> I was pleased to see the nice increase in file space with the new fs
> stuff (my older disk had a year old copy of netbsd and says 4.2/4.3
> while the new via dumpfs says 4.4).  After dump/restoring onto the
> new fs (root/usr) I was impressed with the extra space I had.

> Unfortunately I do not seem to be able to correctly label the new
> disk so it can boot.  After adding "memcpy" to the
> sun3/stand/Makefile so the standalone stuff would compile, I followed
> the read-me but without success.  The system monitor says "no label"
> and punts to ie().

Are you sure you put a Sun-compatible label on the disk, not a native
NetBSD label?  The Sun boot roms don't like non-Sun labels.  Check out
my sunlabel program, which provides a raw interface to frobbing
Sun-style labels.  (If you can't find it in the mailing list archives,
I'll be glad to mail it.)

> I've ended up doing a "dd" of the original disk but that does not
> give me access to the nice shiny new fs layout and such...  even
> after "fsck -c 3" I didn't see any space change magic like the first
> transition via newfs/dump.

I suspect the space change "magic" was due not to the new filesystem
layout but rather to the dump/restore.  Most likely, it seems to me, is
that you have files with big potential holes that are filled in on your
current fs, and dump was smart enough to turn the potential holes into
actual holes.  (Of course, whether such behavior really is "smart" is
debatable.  My personal preference would be for dump/restore to create
holes where, and only where, the original had holes, absent explicit
instructions to the contrary.  That's the way my tar works....)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu