>Number:         5052
>Category:       port-i386
>Synopsis:       sysinst: newfs fails on fake i386 BIOS geoms with heads>255
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 23 18:20:01 1998
>Last-Modified:
>Originator:     Jonathan Stone
>Organization:
	
>Release:        NetBSD 1.3, 1.3.1
>Environment:
	
System: NetBSD Whisk.DSG.Stanford.EDU 1.3_ALPHA NetBSD 1.3_ALPHA (PLACEBO) #0: Wed Nov 26 16:15:18 PST 1997 jonathan@Whisk.DSG.Stanford.EDU:/usr/src/sys/arch/i386/compile/PLACEBO i386


>Description:

Excerpts from discussion on the port-i386 mailing list, in response to
a message by Olaf Seibert <rhialto@polder.ubc.kun.nl> with Subject:
1.3: "Missing operating system".  One level of ">" quotation added for
clarity:

>How-To-Repeat:

See above. Try install NetBSD 1.3 with sysinst on an Adaptec 154x
controller.


>Fix:

#1:

On PCs with SCSI BIOSes, the SCSI controllers lie about the geometry.
For example, Adaptec SCSI controllers reports a bogus C/H/S geometry
with fixed values of H and S. (Controllers with >1gig drives use a
larger H and S if support for >=1 gig drives is enabled).

BusLogic controller do something simiar.

If sysinst creates an MBR, it needs to use this fake geometry in the
MBR or the bootblocks will lose at boot time.
Sysinst should be changed accordingly.


#2:

Some i386 disk controllers report fake C/H/S BIOS geometries to get
around the encoding limits on sectors (S) on BIOS C/H/S values.  This
often results in H and S multiplying out to the right values, but with
huge values for H e.g., 255 on Adaptecs with >1Gig support enabled).

These fake BIOS geometries that are far too big for newfs to handle:
the cylinder groups would require 32k block /2k fragment or
64kblock/8k fragment sizes.

Here, the fix is to use a different geometry in the disklabel (or for
newfs), The fix is as suggested by Rober Baron above: since S is
overconstrained by the BIOS encoding, scale down C and scale up H
while leaving H*C constant. This means finding a divisor of C and H.
(For adaptecs, where C=255, 5 often works; I'm not sure how to handle
remainders.)

Sysinst should detect such cases and handle it automagically,
or at *least*

	a) always warn about impossible BIOS geometries.
	b) always warn about geometries where cylinders are
	   too big for newfs to create cylinder groups.
	c) in either case, compte a suiable re-faked BIOS geometry
	   and provide it to the user as an option when creating
	   an MBR.



See also the discussion in the port-i386 message

>Audit-Trail:
>Unformatted:
>Date: Sat, 7 Feb 1998 01:04:05 +0100 (MET)
>From: Olaf Seibert <rhialto@polder.ubc.kun.nl>
>Message-Id: <199802070004.BAA03275@polder.ubc.kun.nl>
>To: port-i386@netbsd.org, rhialto@polder.ubc.kun.nl
>Subject: 1.3: "Missing operating system"
>
>I just installed 1.3 on a test pc with a SCSI disk connected to an
>Adaptec 1542 controller.
>
>NetBSD detects 2756 cyl, 8 head, 94 sec, 512 bytes/sect x 2074880 sectors.
>
>Sysinst objected to this (more than 64 sectors) and REQUIRED me to
>enter some other geometry. However, the geometry as reported by the
>BIOS (according to sysinst) was identical. So sysinst would not accept
>the values it suggested I should use. Irritation #1.
>
>So I invented some new geometry: 1024 x 16 x 47, keeping the same number
>of sectors/cylinder for convenience.
>
>Then sysinst discovered that my geometry did not account for all sectors.
>It offered to use a fake geometry and I chose the one that gave me most
>sectors (661 x 16 x 47).
>
>When it became time to reboot, I got the message "Missing operating system".
>It seems this comes from the boot code in the MBR.
>
>So, sysinst rendered my test system unbootable. Fortunately I could
>still boot from the boot loader on floppy. I tried different starting
>positions of my NetBSD partition with fddisk, moved the start of c and d
>partitions from 47 to 0, repeatedly installbooted - nothing worked. I
>even re-installed completely without a fake geometry. No go.
>
>And why does sysinst insist in skipping the first track, putting the a
>partition at offset 47? (I suspect this is part of the problem).  This
>happens even though I specified that I wanted to use the entire disk for
>NetBSD.  1.2 lived happily at offset 0.  Sysinst even refuses to let me
>edit the c and d partitions, and editing just the a partition to offset
>0 just ruins the disk. Sigh.
>
>My standard option to get all sectors of the disk is to claim it is
>one cylinder larger than it is, and be careful to allocate no more
>sectors than actually available. This seems much better to me than these
>fake geomeries which usually don't match the disk anyway. This option is
>also not possible using sysinst.
>
>Another irritation: why does sysinst INSIST on pinging a gateway and
>name server? They may not always be necessary, especially not if you're
>installing from a machine on the local subnet.
>
>Anyway, here is the latest fdisk and disklabel info. I see nothing wrong
>with it, but this does not boot.
>
>******* Working on device /dev/rsd0d *******
>Warning: BIOS sector numbering starts with sector 1
>parameters extracted from in-core disklabel are:
>cylinders=2756 heads=8 sectors/track=94 (752 sectors/cylinder)
>
>Figures below won't work with BIOS for partitions not in cylinder 1
>parameters to be used for BIOS calculations are:
>cylinders=2756 heads=16 sectors/track=47 (752 sectors/cylinder)
>
>Information from DOS bootblock is:
>0: sysid 0 (unused)
>    start 0, size 0 (0 MB), flag 0x0
>        beg: cylinder    0, head   0, sector  1
>        end: cylinder    0, head   0, sector  0
>1: sysid 0 (unused)
>    start 0, size 0 (0 MB), flag 0x0
>        beg: cylinder    0, head   0, sector  1
>        end: cylinder    0, head   0, sector  0
>2: sysid 0 (unused)
>    start 0, size 0 (0 MB), flag 0x0
>        beg: cylinder    0, head   0, sector  1
>        end: cylinder    0, head   0, sector  0
>3: sysid 165 (NetBSD or FreeBSD or 386BSD)
>    start 47, size 770001 (375 MB), flag 0x80
>        beg: cylinder    0, head   1, sector  1
>        end: cylinder 1023, head  15, sector 47
>
># /dev/rsd0d:
>type: SCSI
>disk: mydisk
>label:
>flags:
>bytes/sector: 512
>sectors/track: 94
>tracks/cylinder: 8
>sectors/cylinder: 752
>cylinders: 2756
>total sectors: 2072512
>rpm: 3600
>interleave: 1
>trackskew: 0
>cylinderskew: 0
>headswitch: 0           # milliseconds
>track-to-track seek: 0  # milliseconds
>drivedata: 0
>
>8 partitions:
>#        size   offset    fstype   [fsize bsize   cpg]
>  a:    75200       47      4.2BSD     1024  8192    16   # (Cyl.    0*- 100)
>  b:   150353    75247        swap                        # (Cyl.  100*- 299*)
>  c:  2072465       47      unused        0     0         # (Cyl.    0*- 2755*)
>  d:  2072512        0      unused        0     0         # (Cyl.    0 - 2755)
>  e:    75200   225600      4.2BSD     1024  8192    16   # (Cyl.  300 - 399)
>  f:    75200   300800      4.2BSD     1024  8192    16   # (Cyl.  400 - 499)
>  g:  1696512   376000      4.2BSD     1024  8192    16   # (Cyl.  500 - 2755)
>
>
>Date: Sat, 7 Feb 1998 01:04:05 +0100 (MET)
>From: Olaf Seibert <rhialto@polder.ubc.kun.nl>
>Message-Id: <199802070004.BAA03275@polder.ubc.kun.nl>
>To: port-i386@netbsd.org, rhialto@polder.ubc.kun.nl
>Subject: 1.3: "Missing operating system"
>


Which generated a string of replies including:


>From: "Robert.V.Baron" <rvb@gluck.coda.cs.cmu.edu>
>To: Olaf Seibert <rhialto@polder.ubc.kun.nl>
>cc: burgess@cynjut.neonramp.com, frank@wins.uva.nl, port-i386@NetBSD.ORG,
>        rhialto@polder.ubc.kun.nl
>Subject: Re: 1.3: "Missing operating system"
>Message-Id: <886820041/rvb@gluck.coda.cs.cmu.edu>
>In-Reply-To: Olaf Seibert's mail message of Sat, 7 Feb 1998 02:43:28 +0100 (MET)
>
>I didn't do the math earlier.  If you disk is larger than 1Gig, look to 
>see if the 1542 is new enough to support "disks > 1 gig".  If this
>option is enabled then the geometry is, 255 heads and 63 sectors.
>
>NOTE: you can not tell netbsd that your disk had 255 heads.  Instead report
>you have 51 heads and multiply the number of cylinders (you calculated
>by dividing the capacity by 255*63) by 5.  This means that the offset to
>NetBSD (if non zero) would also be multiplied by 5.
>
>
>


>Wouldn't it be a great idea if sysinst could automatically
>compute a suitable lable and suggest that you use it?
>
>I'm not sure I understand this correctly.  I _think_ there are two
>separate issues:
>
>	1) sysisnt wants to use the real geometry in the MBR.
>	  This loses on Adaptecs; it needs to use the BIOS geometry.
>
>	2) the fake Adaptec BIOS geomtetry can cause FFS  headaches when
>	   newfs'ing big disks.
>
>so, to try and recap, to make sure everyone working on sysinst
>understands this :-)...
>
>If we're installing on an Adaptec SCSI controller, then the SCSI BIOS
>will always report the BIOS geometry, C/H/S, as X/64/32, for <= 1gig.
>Newer Adaptec firmware has support for drives >= 1 gig.  or drives>=
>1gig and with the > 1Gig support turned on, Adaptecs use a fake
>geometry of X/255/63.
>
>The problem here is the geometry NetBSD puts in the MBR.  If there's
>no MBR on the disk, NetBSD has to write an MBR, and we have to get it
>`right': the bootblocks use the MBR geometry and if we don't get it
>right, the disk won't boot. (If there's already an MBR, presumably we
>should use whatever geometry is there, so we don't screw up multiboots.)
>
>
>But netbsd can also find the `real' disk geometry reported by a SCSI
>mode-sense, and will recommend that you use that.  This is the WRONG
>THING to use for Adaptec SCSI controller (and maybe scsi controllers
>in general?); you need to use the BIOS geometry. (or, maybe, something
>faked up from it).
>
>fvdl suggests finding all BIOS geometries and letting the user pick
>one.  That sounds OK to me; obviously if there's only one, it's easy:).
>
>
>#2: Assume we have some sensible idea of what the BIOS geometry
>of the target disk is.
>
>The next problem is computing a disklabel geometry for the BSD
>disklabel that doesn't upset newfs.  The X/255/63 geometries are OK.
>The X/255/63 geometries are going to cause newfs to puke, because that
>computes out to _huge_ cylinders, cylinder so big that the FFS is
>going to puke trying to create cylinder groups and inodes.
>
>The workaround for *this* is to fudge the geometry used the BSD
>disklabel slightly, rather than just using the geometry in the MBR (or
>the real disk). We divide heads by some suitable factor and multiply
>cylinders by the same factor.  The prime factorization of 255 is
>3*5*17, so 5 is a good candidate.  (This FFS issue could potentially
>come up anywhere, but the only real place we've seen it to date is x86
>BIOSes for SCSI disks).  As best I've followed the discussion, this is
>only necessary for the >= 1gig case; the <1Gig case is fine.
>
>
>OK. Here's the $64k question: if we do this fudge in the disklabel, do
>we *also* need to do the same fudge in the C/H/S geometry in the MBR
>too, or should it use the exat same values reported by the BIOS?
>
>
>
>From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
>In-reply-to: <886820041/rvb@gluck.coda.cs.cmu.edu>
>Message-Id: <199802070542.VAA04502@Kowhai.Stanford.EDU>
>To: "Robert.V.Baron" <rvb@gluck.coda.cs.cmu.edu>
>To: Olaf Seibert <rhialto@polder.ubc.kun.nl>
>cc: burgess@cynjut.neonramp.com, frank@wins.uva.nl, port-i386@NetBSD.ORG
>Subject: Re: 1.3: "Missing operating system"
>Cc: simonb@NetBSD.ORG
>In-reply-to: <886820041/rvb@gluck.coda.cs.cmu.edu>
>Date: Fri, 06 Feb 1998 21:42:02 -0800