#define AUTHOR "mouse@Collatz.McRCIM.McGill.EDU (der Mouse)"

/*
 * 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.
 * 
 */

#undef AUTHOR	/* "mouse@Collatz.McRCIM.McGill.EDU (der Mouse)" */

It is worth adding that the reason for the difference between the
SunOS 3.x bootblocks and the SunOS 4.x bootblocks is that under SunOS
4.x, for the first time (at least in Sun's history), the size of the
kernel exceeded a megabyte in size; the PROMs apparently had not much
to do with this as I used to run SunOS 4.1.1 on a Sun 3/50 (with a +4MB
daughterboard).  I discovered this when I tried to use SunOS 3.x boot-
blocks to load a SunOS 4.x kernel.  It got so far:

Boot: sd(0,0,0)/vmunix
Load: sd(0,0,0)/boot
Boot: sd(0,0,0)/vmunix
Size: 1148928Data Alignment Error
>

or some such.



				--*greywolf;
--
Are you being infected by a UNIX virus?  If you're receiving OS shipments
from your vendor, you may be subjecting your computer to the worst virus
in history: SVR4.  There is a cure for this virus:  upgrade to NetBSD
(now running on a platform near you).