From owner-freebsd-hackers  Sat May  3 13:36:17 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id NAA14151
          for hackers-outgoing; Sat, 3 May 1997 13:36:17 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA14136
          for <hackers@freebsd.org>; Sat, 3 May 1997 13:36:14 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id GAA18770; Sun, 4 May 1997 06:31:18 +1000
Date: Sun, 4 May 1997 06:31:18 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199705032031.GAA18770@godzilla.zeta.org.au>
To: imp@village.org, thorpej@nas.nasa.gov
Subject: Re: Mounting other people's disks?
Cc: bde@zeta.org.au, hackers@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>In message <199705031641.JAA04537@lestat.nas.nasa.gov> Jason Thorpe writes:
>: The other port that uses MBR partitions, NetBSD/powerpc, uses the
>: "absolute" approach (no "slices" of any sort); if a NetBSD disklabel

I think this thread was originally about OpenBSD labels vs FreeBSD label
handling and I wrote `NetBSD' instead of `OpenBSD' by mistake.

>: is found, its partition information is used, else the information from
>: the MBR is used.  The MBR and the NetBSD disklabel must be consistent
>: for partitions that both OpenFirmware and NetBSD share (such as the
>: FAT where the boot program is loaded from).

>OpenBSD/arc seems to do exactly the same thing.  'c' is the whole
>disk, and there must be an MBR if you wanna use that disk to load the
>OS off of.

I don't think it's the same.  There is no `whole disk' partition in the
i386 MBR (or in secondary BRs), so there is no way for a `whole disk'
`c' partition to be consistent with the MBR.  This is probably why the
whole OpenBSD label is rejected.  FreeBSD does a consistency check that
the 'c' partition is fairly consistent with the slice (it must have the
same offset and must not be larger).

If the `c' partition starts at absolute offset 0, then there are serious
problems locating the label.  The label can't always be in absolute sector
LABELSECTOR=1 (except when the slice starts at absolute sector 0) since
there may be something else there.  If the label is in absolute sector
(start_of_slice + LABELSECTOR), the everything that deals with labels
needs to have machine-dependent code to locate it.  The general case,
with Disk Manager(s) and extended partitions, is quite complicated.

Bruce