>The concept of `geometry' is basically
>meaningless at this point, and is merely an artifact of old software
>interfaces.

True, but we still have to deal with that old software.  And aren't
there still some machines out there that do use C/H/S addressing?
We still should support them, if they exist.

>And what would you have fdisk(8) do?  Use some mechanism behind the

I'd rather not have to use fdisk to find the "geometry".  I'd like to
have sysinst be able to get accurate information from the kernel.
Then one could tell fdisk what geometry to use, if indeed it has to be
used. (see below.)

>And what would you have fdisk(8) do?  Use some mechanism behind the
>user's back?  What if I'm installing on a spare SCSI disk, and I plan
>to move it to a different machine, with a SCSI BIOS that uses a
>different geometry?  I'd be f*cked.  By always using the label, I can
>simply change the geometry in the label to match the target machine,
>and it will work.  (Note: This is a real situation!)  The system
>should not ever make it impossible for me to do fiddle with the
>parameters.

I assumed we were trying to make it easier for "joe average user" to
install on a machine they have.  This situation sounds much more like
what a developer might do.  At least the user would have more
knowledge about the system than "joe average user".  And yes, I agree,
if a disk was moved from one SCSI controller to another one with
different BIOS C/H/S parameters, you would loose if the partition
didn't start at sector 0 or such.  But that is a problem I suspect is
not unique to NetBSD.  That just shows how poor the MBR design is.
	
>Sorry, but I don't buy this.  The BIOS doesn't look at the partition
>table; it just loads the MBR, checks the `signature', and runs it.
>(There may also be some tweaks for `virus detection', such as checking
>the first instruction.)  I have tested dozens of machines, and not a
>single one did anything else here.
>
>I need firm proof, not just anecdotes.

Ok, please tell me how to do the dedicated install.  I tried many times
with no luck.  I will try it again.  And what would be considered
"firm proof"?

>That could be, on older machines.  That's unfortunate.  However, this
>is specifically why I suggested providing all the BIOS geometries as
>options to the user, if the matching failed -- so that they don't have
>to deal with cranky BIOSes.

No, that was a newer machine.

Do you want the kernel to present these to the user at boot?  (I would
think not.)  I'm presuming you are talking about the install tools.
So how does the install tools get all the BIOS geometries and how does
it know which disks have been successfully matched and which one have
not?

>I don't believe that's possible.  In particular, unless you're doing a
>`whole disk' installation on a newer machine (one with `large disk'
>support -- again, assuming the boot block is fixed), then you *have*
>to deal with the 1024 cylinder limit.  Documenting this in an obscure
>section of the manual in the hope that people won't have to look at it
>is merely wishful thinking.

I would think a simple message telling the user that the NetBSD a
partition must be located entirely within the first X Mb of the disk
would be sufficient.  You could even put in a reference to the
description of why this is needed.  X will need to be computed 
by the install program depending on the C/H/S of the BIOS.

>BTW, even the `geometry' that the drive reports often doesn't cover
>the whole disk.  It seems to me that an arguments about this are
>really non-sequiturs, since using a different geometry than the BIOS
>doesn't actually solve any problems.

Ok, that does answer one question I had.  So what we really want
from all the disks is the capacity and totally ignore C/H/S unless
	a) Some BIOS really do require the first track to be
	   left alone or
	b) NetBSD is to be installed along side another OS and
	   we need to boot via a C/H/S MBR.
In those 2 cases we have to know the MBR C/H/S values to be able
to instruct fdisk how to set up the MBR properly.  We also need
to know if we have to restrict the a partition to the first 
1024 cylinders.


It now sounds to me like we may have discussed this enough and it is now
time to do something. Please, Charles, when you have your scheme
implemented and working, let me know.  With a full definition of how
to get all the information, I'll try to get sysinst to do the right
thing.  If you would prefer, you can also do the work on sysinst.

My interest in sysinst from the start was to make it easier for
"joe average" to install NetBSD. (read my students.) I do think
the current state of sysinst is much better than the 1.2 install
process, but it is obvious more needs to be done.  As I see it,
the biggest problem with sysinst is the disk partitioning and
MBR manipulations.  Once that is done correct, all other problems
are just annoyances or "it would be nice if it did" type problems.
I have no axe to grind that says I must do the work on sysinst.

-- 
Phil Nelson
phil@steelhead.cs.wwu.edu (NetBSD/pc532 machine)
phil@cs.wwu.edu (work)
http://www.cs.wwu.edu/~phil