Subject: Re: pmax miniroot bootblocks...
To: Jonathan Stone <jonathan@dsg.stanford.edu>
From: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>
List: port-pmax
Date: 03/28/1996 01:44:54
> >A random comment about the process, since i'm writing this mail:
> >
> >nit'd be sort of nice if the miniroot image was filled with zeros
> >before being newfs.  some 'random data' from a disk block in the first
> >(always-empty) 8k of the file system ... can look confusing.
> 
> 
> The miniroots were put together using the VND driver.  For
> reasons I don't understand at _all_,  doing a newfs on a filesystem
> under a VND driver, on a pmax, appears to reserve space for
> bootblocks.  (this is, as far as I can tell, the source of the
> "extra" 16 sectors that has confused many would-be installers.)

This is not a 'pmax thing' this is a file system thing.

The first 8k of all BSD fast file systems is unused, to leave room for
things like boot blocks and disklabels.  (i believe this is true for
LFSs, as well, and that ISO-9660 file systems can have variable
amounts of boot block space at the front...  I dunno all the details.)

Zeroing the file system first also is nice, because it makes it
compress better, and because it keeps random data on your system from
being exported to the rest of the world...


> *However*, and this is the point, I can't find any way to write
> a bootblock (or disklabel) to those 16 sectors.  Is this deliberate
> or a bug?  If it's deliberate, why are things set up that way?

I dunno why that would be; certainly, when i was creating NetBSD/i386
boot images with 'vnd', i had no problems doing it...

There is what i'd call ... a little bit of 'cache weirdness,' because
of the way the vnd driver does some things.  Take a look at the
distrib/i386 makefiles (esp. the kc-common Makefile.inc) to see  what
i did.  "worked for me!"  8-)


cgd