From owner-freebsd-current  Wed May 10 22:34:51 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id WAA17618
          for current-outgoing; Wed, 10 May 1995 22:34:51 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA17608
          for <current@FreeBSD.org>; Wed, 10 May 1995 22:34:34 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA06311; Thu, 11 May 1995 15:31:22 +1000
Date: Thu, 11 May 1995 15:31:22 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199505110531.PAA06311@godzilla.zeta.org.au>
To: current@FreeBSD.org, mark@linus.demon.co.uk
Subject: Re: problem with new biosboot?
Sender: current-owner@FreeBSD.org
Precedence: bulk

>  # fdisk /dev/sd0
>  ******* Working on device /dev/sd0 *******
>  parameters extracted from in-core disklabel are:
>  cylinders=2448 heads=12 sectors/track=69 (828 blks/cyl)

This geometry is a merge of the geometry reported by the drive and the
geometry guessed from the partition table.  Since the partition table
is bogus, and is detected to be so, no geometry was guessed from it,
and you ended up with the geometry reported by the drive.

>  The data for partition 3 is:
>  sysid 165,(FreeBSD/NetBSD/386BSD)
>      start 0, size 50000 (24 Meg), flag 80
>          beg: cyl 0/ sector 1/ head 0;
>          end: cyl 1023/ sector 63/ head 255

>The geometry is the untranslated version.  The bogus slice isn't what I
>remember setting it up as when I upgraded to FreeBSD 2.0 (950210 SNAP),
>but probably happened when I used disklabel -e to specify non-zero RPM,
>etc. (?)  ...

Correct.

>Curiously, the compatibility device shows me an MBR table with the translated
>geometry:

>  # fdisk /dev/sd0d
>  ******* Working on device /dev/sd0d *******
>  parameters extracted from in-core disklabel are:
>  cylinders=1003 heads=64 sectors/track=32 (2048 blks/cyl)

It doesn't make any sense to run fdisk on the compatibility slice, especially
on the d partition in it.  The d partition just happens to start at offset 0
on the whole disk, so fdisk reads the MBR from the right place.  It reads
the label from a different place (the in-core label for the compatibility
slice, which is different from the in-core label for the whole disk).  The
geometry is whatever you put in the label.

>Which of these is relevant, and where on the disk is the other one stored?!

Neither is relevant to the current problem :-).  The one for the whole disk
is constructed when a device on the disk is first opened.  It currently
just holds the (currently guessed) BIOS geometry.

>My disklabel uses translated geometry:

>  # disklabel -r sd0
>  # /dev/rsd0c:
> ...
>  sectors/track: 32
>  tracks/cylinder: 64
>  sectors/cylinder: 2048
>  cylinders: 1003
>  ...
>  8 partitions:
>  #        size   offset    fstype   [fsize bsize bps/cpg]
>    a:    36864        0    4.2BSD     1024  8192    16   # (Cyl.    0 - 17)

Booting from partition 'a' should work.  It surely is all below cylinder 1024
in the BIOS geometry, whatever it is, and you don't use bad144.  The whole
disk is probably below cylinder 1024, so even booting from the 'c' partition
should work.

I can't explain the problem.

Bruce