Subject: Re: Booting sd0 q(disk geometry versus bios geometry)
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Heiko W.Rupp <hwr@pilhuhn.de>
List: port-i386
Date: 07/13/1998 11:26:41
Hi,

On Fri, Jul 10, 1998 at 03:23:54PM -0700, Jonathan Stone wrote:
> I'm not an expert here, but AFAIK, primarily it's because the BIOS
> reports back geometry in terms of DOS drive numbers. Mapping those
> numbers to NetBSD's idea of a controller/unit is at best heuristic.

Ok.

> But we can (and IMHO probably should) do better for either signle-disk
> systems or for SCSI controllers, like Adaptecs, where two fields of
> the C/H/S geometry is fixed for all disks on a given controller.

Yupp.  I tried to enter the Adaptec translation (100c,64h,32s) at the 
point where I can enter C/H/S and sysinst afterward told me, that this 
does not address the whole drive, so I can now either use teh real geometry
(1219c) or use one of the fake geometries. This went away when I used
the dos fdisk. I am not sure wheter sysinst is "too smart" at this
point.

> description of "sysinst hosed my geometry" to figuring out what went
> wrong.

Yes. I hope my description above helps.

> Sometimes the problem really _is_ that a user fed the SCSI mode-sense
> geometry into the MBR, causing chaos. I'm not sure what we can do
> about that.

Hmmm. When we know that the user wants the entire disk for NetBSD,
then sysinst can find out on what controller the drive is. If it is an
adaptec, get the size from the mode-sense, see if it is larger or
smaller than 1GB and calculate the number of Cylinders with one of the
two adaptec translations. THen prompt the user that she has to enable 
the extended translation of the adaptec for drives > 1? GB and skip
the "ask the user for geometry" thing totally.

-- 
          See <a href="http://www.netbsd.org">NetBSD</a> for a multiplatform OS
... ich kann labern!   -- Cutie am 12.11.1993 im Pizzahaus