Subject: Re: Booting sd0 q(disk geometry versus bios geometry)
To: Heiko W.Rupp <hwr@pilhuhn.de>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-i386
Date: 07/10/1998 15:23:54
>First of all - sysinst is a great tool and which helps installing
>NetBSD very much. I did not mean to offend anyone who worked on it,
>but really appreciate the work on it. It is clearly the way to go. I
>was frustrated when I wrote the mail(s), as I went through several
>cycles of booting the install floppy, writing MBR etc, labeling disk,
>installing sets and "No operating system found".

First of all, no offense was taken and I apologize if it seemed
otherwise.  I understand far, far too well the frustration that comes
when our (or other) install tools clobber your drive.


>> That sounds painful.  But have you tried doing that with the 1.2
>> install tools?  Do the 1.2 install tools do a better job of handling

>No. I skipped the 1.2 line completly. My last full install was
>probably at NetBSD1.0 (or even 0.9) the others were upgrades. 

I havent ever had a successful install with the 1.2 tools, so I dont
now for sure, but AFAICT they wouldn't cope any better with a disk
that has more than 1024 cylinders.

You have two choices: set up an MBR slice and make sure your root
partition fits eniterly within the C/H/S boundaries of the MBR and the
BIOS; or (assuming your BIOS isn't doing its own translation behind
the scenes!!) construct a fake C/H/S geometry for the disk in the MBR,
dividing C by 2 or 5 and multiplying S or H correspondingly.



[ "whole disk" install vs. reserving 1st cylinder]

>Yes I understand. That's why I wrote to possibly have two choices.

There are several tradeoffs here, and I don't understand them all
(i've never had to deal with OS/2 systems or the NT partition manager,
for example) but this issue was discussed at length during the 1.3
ALPHA and BETA cycle. The consensus then was that reserving the 1st
BIOS cylinder wastes very little space, and eliminating that waste
just wasn't worth all the potential problems it could cause.

If you want to change that consensus you will have to make a solid
case for it.



>Right. Here sysinst is real handy. Only the bios geometry thing is a
>real problem (at least for me). When DOS fdisk can figure out what the
>bios geometry is, why can't sysinst?

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.

The bootlodaer could get the geometry from the BIOS and pass it to the
kernel, but the kernel might get the mapping to drives incorrect.  And
of course there's always drives with no MBR on them at all.

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.


> I finally had to search a DOS
>floppy, run fdisk and then install succeeded. 

>And as I said: I did not mean to offend anyone personally and I really
>appreciate sysinst.

None taken.  But if sysinst *is* munging MBR geometry info, we should
find out why and stop it.  I often find it difficult to go from a
description of "sysinst hosed my geometry" to figuring out what went
wrong.

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.