I think I just found another problem.
sys/arch/i386/stand/installboot/installboot.c creates a 'fraglist' array of
block numbers + block counts, which (I presume) the boot sector uses to
load the 2nd-stage boot program.  The boot sector definitely uses the
fraglist values as physical sectors.  installboot, however, generates the
values as follows:


	/* convert to disk blocks */
	blk = fsbtodb(fs, blk);
	nblk = fs->fs_bsize / DEV_BSIZE;

Now, fsbtodb, as originally written, converts file system frags to physical
sectors.  So the first assignment yields a sector number, but the second
assignment yields a DEV_BSIZE count!  This is certainly wrong.

I'm not sure how to fix it, though.  I've gone through all of the ffs_*
files, and with the exception of the two questions I had posted earlier,
every use of fsbtodb and dbtofsb is intended to convert frags to/from
DEV_BSIZE units.  The installboot code above is a rare exception.  As Bill
stated earlier, we are tracking other code bases, so I wanted to keep
changes to the kernel at a minimum.

The choices are: A) change every instance of fsbtodb and dbtofsb in the ffs
code to something else, and let fs_fsbtodb be defined is frags -> physical
sectors; or B) change fs_fsbtodb to convert frags -> DEV_BSIZE blocks
(dynamically, when the fs is mounted) and just fix the exceptions.

In either case, that second assignment in installboot needs to be fixed.
But the fix requires having the physical sector size, which is not passed
to the function.  Should we A) derive the sector size from fs_fsbtodb, and
hope it's correct; or B) get the drive's sector size dynamically, and
change the calling parameters for add_fsblk()?

-----------------------
Trevin Beattie          "Do not meddle in the affairs of wizards,
trevin@xmission.com     for you are crunchy and good with ketchup."
      {:->                                     --unknown