> : If we only tweak MBR's while the BIOS is available, presto, no geometry
> : problems.
> 
> Hm.
> 
> We can't somehow cache the BIOS's interpretation of drive geometries, and
> make it available via an ioctl?
> 
> (Or was this addressed, and I never saw it because I didn't read the
> thread?)

It was addressed -- sorta. There were a couple of battling proposals.

All the current machinery could be made perfectly operable if we could
somehow make two BIOS calls from the netbsd environment:
    a. query BIOS geometry of disk N
    b. read block 0 of disk N

If we can manage these two, then it's trivial to isolate a single selected
disk -- write 00's to its block 0, read every block 0 using the BIOS,
write FF's to its block 0, and read every block 0 using the BIOS again.
The only disk whose block 0 changes during the procedure is the one we want.


However, since this solution is not already being used, I have a sinking
feeling that it isn't really feasible. It would be great if it were.

IIRC the PC BIOS supports 7 bits of fixed disks. So if we can allocate 128
somethings in the boot loader for the install disk, and pass them into the
kernel, then an ioctl would indeed be available to help us divine the
missing information.

Suppose for each disk we store its geometry plus a C-H-S triple and a hash
of the sector addressed by that triple. First thing we do is try hashing
block 0 of every disk, but if any of them are duplicates then we skim the
first few megs of their disk looking for a block that hashes uniquely (once
we find a candidate, we do need to check the other disks to make sure the
same sector does not hash identically on those disks). This is designed to
get around cases like mostly empty new disks, or where you dd /dev/zero over
the first meg or so of a disk to mark it as unused.

One exception is that duplicate hashes are okay IFF their reported geometry
is also the same. This lets you plug in two identical, zeroed disks without
automatically foiling the algorithm.

If at this point there are still any duplicate hashes because we were
unable to find unique ones, punt to the user and ask him to select from
a list of geometries that match, or to partition the disk outside of netbsd
and run the installer again.


In general, any disk which has been partitioned outside of NetBSD should
hash well enough on block 0 because the geometry info is in its MBR. We
could just recommend to people that any disks they want to boot off of
should be minimally partitioned with normal PC partitioning tools, first.

Todd Whitesel
toddpw @ best.com