Subject: Re: i386 booting, take 2
To: Phil Nelson <>
From: Charles M. Hannum <>
List: tech-install
Date: 09/21/1998 12:58:31
> Your proposed method
> of matching the disks could improve the percentage of disks matched
> by a bit.

Improve `by a bit'?  As opposed to what?  No other mechanism was
proposed that would even work on a significant fraction of modern

> But I still believe that the reported geometry via the ioctl that
> gets the geometry should be what the disk reports, not what the BIOS
> reports.

No, it should be what's in the label.  There are many reasons why one
would want to change what's in the label.  And some disks
(particularly SCSI disks) actually let you reformat the disk with a
different geometry.  The concept of `geometry' is basically
meaningless at this point, and is merely an artifact of old software

> The only reason currently that sysinst
> asks about the BIOS geometry is because fdisk is prone to get things
> wrong and we need to ask the user for help.  With a much better
> method of matching disks to BIOS geometry, we don't have to ask.)

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

> As I understand it, to be able to use the entire capacity of SCSI
> disks (and possibly IDE disks), we need to do one of two things:
>         a) choose a fake geometry that allows one to address
>            as much of the capacity as possible (as sysinst now
>            does) or

(How many times do I have to say this?)

>         b) rewrite newfs to use the entire capacity regardless of
>            what the C/H/S geometry says.  (Given that FFS works with
>            cylinder groups, this may be hard.  From what I remember
>            in adapting the FFS code to run under minix and build
>            FFS file systems, the FFS is heavily tied to C/H/S
>            geometry data.)

Actually, it would be fairly trivial, and I know of at least one place
where it's been done.  There are already certain parameters that turn
off cylinder optimizations; all you have to do is tweak newfs(8) to
allow specifying the CG size in terms of sectors rather than

> If I understand what you are saying here, this CAN NOT be done on
> all machines.  I have HP machines here at WWU that refuse to boot
> from any partition that contains the very first track on the disk.
> I can try again, but unless things have changed since 1.2 in
> terms of the boot support, I'm sure it can't be done.

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.

> I have had machines I used where the 
> setup program in the BIOS told me ONLY the "real" (reported) 
> geometry of the disk and not the what the BIOS used.

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.

> In rereading "take 2", it appears that what you wrote is intended to
> be part of the install document.

I did, in fact, specifically state that.

> I believe that we should be able to
> do a good enough job to not have any geometry information in the
> install document except possibly in a section that talks about
> "expert" installations and trouble shooting.

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.