>  -- NetBSD mounts `/dev/sd0a' on `/', regardless of what drive it was
>     booted from.  I expected, and would have preferred, the SunOS
>     behavior of mounting the root file system from the `a' partition
>     on the boot device.

1.0 did this.  -current attempts to do what you want, at least if your
kernel was built with "swap generic"; of course, nothing will help if
the kernel was explicitly configured with "root on sd0a".  I think the
-current code to do this is broken, though; Theo de Raadt has fixed it,
but based on the recent flap, I suspect the fixes may not have made it
into the tree yet (though I haven't checked).

>  -- [...fsck...]  Also, it sure would be nice if `fsck' had at least
>     one of the two relatively recent features of the SunOS version:
>     (1) it knows when a filesystem has been synced since its last
>     write, so that `fsck'ing isn't necessary, and (2) it works on all
>     disks simultaneously, checking one filesystem from each disk at a
>     time.

cgd replied that (2) has always been there (why would you think it
isn't there?) and that -current does (1).  Unfortunately, unlike SunOS,
there is no flag to -current to make it ignore clean bits.  (I have,
twice, gotten a filesystem with its clean bit set and non-clean data.
It was from reinstalling /sbin/init, but IMO if the clean bits can't be
trusted, they shouldn't be there.)  I have a patch to fsck to add a -i
option that makes it ignore clean bits, which I will send-pr at some
point.

>  -- The installation instructions say nothing about `pwd_mkdb'!  I
>     had to do some sleuthing to find this sucker.

As mrg says, why weren't you using vipw?

>     The instructions should really say specifically how to install
>     one's SunOS `passwd' file:

...namely, fire up vipw, read in the SunOS file, add the extra fields,
and write-save-exit.

>  -- It would be nice if NetBSD came with a precompiled version of
>     `tcsh', since the SunOS executable doesn't work (yet?).

It doesn't?  Every SunOS binary I've ever tried has worked, including
shells.  (Modulo bugs in the binary; one binary I tried failed because
it made implicit assumptions about how the TCP stack worked.)

>  -- To run many SunOS executables, it is necessary to
>       # ld -s /usr/libexec/ld.so /usr/lib
>     At least, I guess this is the right thing to do -- it seems to work.

Do you mean "ln -s"?  I can't see how "ld -s /usr/libexec/ld.so /usr/lib"
would do anything useful.

If you really want to run SunOS dynamically linked binaries, you're
much better off putting a SunOS ld.so and lib*.so in place.  I've found
that SunOS binaries often work with SunOS ld.so and libraries, but fail
dismally with the NetBSD ld.so and libraries.

> After I got the system running, it became evident that the SunOS
> binary compatibility is not quite where I need it to be to
> permanently change over to NetBSD.  I tried to start my SunOS X11R5,
> but `xinit' got a bad system call error.

I think this is probably because you're using the NetBSD ld.so and
libraries.  Try with the SunOS ones:

	# mkdir /sunos-compat-hacks
	# mount -r sunos_host:/usr/lib /sunos-compat-hacks
	# mount -t union -r -o -b /sunos-compat-hacks /usr/lib

> What is the degree of commitment to the SunOS compatibility?  Is 100%
> compatibility a goal, or even possible?

Not possible.  There are too many little details that are different.
For example, it strikes me as extremely unlikely that anyone will ever
make it sufficiently compatible that SunOS trace(1) will work, and it
could never work for tracing native NetBSD executables.

> When I try an executable and it doesn't work, how can I get more
> information about what went wrong?

Syscall tracing is most likely to be useful.  Use ktrace(1), or since
you're running 1.0, you can install my ptrace and use trc.

> Do I have any hope of fixing the problem or will that take a wizard?

Depends on what the problem is. :-)  As I said, try the SunOS ld.so and
libraries; that will likely fix lots of what you're seeing.

> Are any of these problems likely to have been fixed already in the
> latest version?

Yes, several of them, per above.

You also ask

> Should I try a -current?  I'm really not into being on the bleeding
> edge.

There are at least two binary snapshots made from -current as of
recently; for example, I have one made from May 9th sources, which is
known to "work" - or at least, I have found only a couple of very minor
bugs in it, not the sorts of things that will be encountered unless
you're into OS development work.  I think pk also recently put up a new
snapshot on ftp.netbsd.org, but I cannot personally speak even for its
existence, never mind how well it works.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu