> The root problem here PC BIOS braindamage.

I agree.

First, what I probably don't understand is whether the BSD disklabel
fictitious geometry needs to use the same number of heads and
sectors/track numbers as the BIOS fictitious geometry, i.e. whether
these numbers impact where the first-stage boot loader reads the
second-stage boot loader from.  (I've tried to read the installboot
code, but I've not been able to grasp exactly what it's doing, much
less what (if anything) it's doing wrong, and what impact the BSD
disklabel and the BIOS geometry has on the end result.)

> I think what you need to do is accept an LBA-compatible, bootable,
> BIOS geometry, like 2055c/255h/63s, for the MBR, but when you
> construct a NetBSD disklabel, factor that down to 16h/63s to keep
> Kirk's filesystem happy.

I thought I tried that, but I'll have a go at it again, especially
considering that my first attempt was probably from trying to boot
from the "other" and so far untouched disk drive...

> 2.  If you mean 255h for the BSD disklabel, then no.  FFS won't let
> you _do_ that. Its internal sizing heuristics (I think ultimately due
> to the size of offset fields in a cylinder group?) require that you
> use a 32k/4k filesystem with cylinder groups that big, even for a
> one-cylinder CG. And that may be bigger than FFS supports.

Well, I did manage to use 255h overall (both BIOS, MBR partition
table and BSD disklabel) and had thus to create 32k/4k file systems.
This went fine, and I extracted the distribution with that, but the
disk was *still* not bootable.  This really got me scratching my
head.

> With SCSI we can do a mode-page sense to figure out how many blocks
> the disk really has, and then fudge with the gemoetry in the BSD
> disklabel to get disklabel entries at least as big as the disk, but
> with c/h/s factored down (factor h, divide it by a factor k, multiply
> c by k) so that the BSD disklabel "geometry" matches FFS's
> 1984-vintage ideas of how big a disk is.
>
> I dont know if we can do better for IDE, but maybe we should try.

NetBSD-current of the end-july vintage printed the total capacity in
number of blocks; in my case 33022080.  (NetBSD 1.3.2 thought it was
an 8GB disk...)  I'm not sure how it's done, but "if it works, don't
argue"... ;-)

Oh, BTW, this machine is "new", i.e. has not been put into service
yet, so I can toy around as I like with the drives and the BIOS with
no immediate harm.


- H=E5vard