>> [...] as the PROM monitor didn't know how to handle the rsd?a
>> partition using the default filesystem of NetBSD/sparc.  [...]
> The PROM shouldn't care much about the filesystem type.  All it does
> is find the end of the superblock of the rootfs, and load the primary
> bootstrap from there.  The primary bootstrap _does_ care about the
> rootfs type.  NetBSD's boot code can handle both.

There are actually _two_ levels of disk bootstrap.

The ROMs know how to load the next 15 sectors after the disk label
(sectors 1 through 15).  Those 15 sectors contain a program that knows
how to load the next bootstrap.  Under old SunOS (SPARCs may never have
done it this way, but SunOS 3.5 for the Sun-3 does), this program knows
enough about the filesystem to look up "/boot" and load it.  Under
newer SunOS, including all SPARCs I've ever looked at, this program has
a table of disk block numbers in it, and it blindly loads those blocks.
This table is updated by installboot when it writes the boot blocks to
that 7.5K area between the label and the superblock.  (The old scheme
has no installboot; that 7.5K area is written via dd.)

NetBSD uses a scheme very much like the latter (even on Sun-3s).

Under the old scheme, the first-level disk bootstrap does care about
the filesystem layout; under the new scheme, it doesn't.  Under both
schemes, the second-level disk bootstrap knows a good deal about the
filesystem.

Now, it's possible the machine in question has a disk that has an
old-paradigm first-level boot on it which have never been replaced.
This would care about the filesystem, and to the user could well appear
to be part of the PROM boot sequence.  I suppose it's also possible
that the PROMs truly do care about the filesystem, but that seems
unlikely.

It's also possible that the disk somehow managed to acquire a native
NetBSD disklabel instead of a SunOS disklabel; the PROMs will get upset
if they don't see a disklabel at least minimally compatible with SunOS.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu