> >I'm not sure what you mean by a "primary partition". I think you might 
> >not understand the difference between a BSD disklabel "partition" and
> >an MBR "partition"....
> 
> I thought it might be the distinction between the four partition slots
> in an MBR (called "primary" partitions) , and entries in a "secondary"
> partition table used by "boot managers", augmented DOS MBR bootstrap
> code, and DOS TSRs/drivers to make the extended partitions avaiable as
> DOS drives...
> 
> Such "secondary" partitions aren't bootable (so you can't put NetBSD
> in one) and they're often invisible to other OSes anyway.

Hmm, just some nitpicking:

While I'm sure you know that, but since others might be confused, I'll point
out here that secondary partitions are _not_ in any way related to BSD
disklabel partitions (well, to be _really_ picky, there is some small
relationship on some (one?) platforms, see below).

AFAIK, there isn't any "augmented DOS MBR bootstrap code" nor any "DOS TSRs/
drivers" involved with secondary partitions.  Access to those secondary
partitions is just part of the regular DOS code.

Regarding the bootability of secondary partitions, this depends on the
platform (well, since this is port-i386, you are probably correct in saying
that they are not bootable, but MBR partition tables are now in use by
other types of machines as well).

Now another try to bring this all into perspective (if not otherwise noted,
this applies to the PC hardware):

The MBR is the very first sector of a harddisk.  It includes a table of
up to four partitions, specifying for each partition the start cylinder,
head and sector, the end cylinder, head and sector, the absolute sector
number of the partition's start, the number of sectors in the partition,
a flag that specifies the type of the partition (only for informational
purposes for fdisk like programs) and an active flag (to be described in
a second).

In addition to this table the MBR contains code.  This code, when loaded by
the bios rom into a fixed location in the machine, will search the partition
table (remember this is included in the same sector) for the partition
marked active, load the first sector of that partition again to a fixed
location in memory (actually the same location as where the MBR was
initially loaded) and jump to it.  That code hopefully knows how to boot
the OS that supposedly resides on that partition.

Now the extended partitions:

An extended partition is just as any other MBR partition, having a special
type (namely 5).  Its first sector is in essence just an MBR, with again up
to four partitions, but without the code to load the first sector of those
secondary partitions.  This is the reason that (on PCs) those secondary
partitions are not bootable (which would be easy to correct if someone would
modify the standard MBR code to take the offset into account and place it in
the extended partition's MBR).  Those secondary partitions may in turn be
extended partitions that again contain up to four secondary (tertiary?)
partitions (albeit I'm not sure whether DOS does support this).

On some other machines that do support MBRs to partition their disks (e.g.
some PowerPC based machines adhering to the PReP or CHRP standards) the
MBR doesn't neccessarily contain code to interpret the partition table, but
this code is part of the firmware.  This firmware is (in both of those
standards) required to also support booting from secondary partitions
(and doing this recursively!).

Now BSD disklabels (again on PCs, and I'm not sure how far this applies
to the other BSDs, so take this with a grain of salt if you are not
using NetBSD):

NetBSD doesn't normally use the MBR partition table (nor any extended partition
MBR) to identify the parts of a disk.  It has its own partition table in
its own format, namely the "BSD disklabel".  However, to find this disklabel,
there has to be a BSD partition in the MBR (the type field of this partition
indicates what dialect of BSD this is).  This partitions second sector
has the BSD disklabel.  (The second sector was choosen, since the first
sector contains the code that has to load the OS, and the BSD disklabel
doesn't leave enough place in a sector for this code).

The BSD disklabel can have up to 8 partitions (currently) which need _not_
be in any way related to the MBR partition that does contain this label.
Conventions however say that partition c (the third of these partitions) does
replicate the information for the BSD partition in the MBR while partition
d (the fourth) does describe the whole disk.  Under normal circumstances the
other partitions are all part of the partition c.  One often used exception
is that you might have a partition in the BSD disklabel that replicates the
information for the DOS partition in the MBR in order to allow access to
DOS files.

Now when you have a harddisk that does have a MBR but doesn't have a BSD
disklabel, NetBSD constructs a virtual BSD disklabel from the MBR:
It constructs a d partition representing the whole disk, and replicates
the information for the partitions found in the MBR in the disklabel partitions
e, f, g and h repectively.  If it finds a partition in the MBR marked as
type NetBSD, it also replicates that ones information in the partition c.

Again as an aside, NetBSD/ofppc (the port of NetBSD to the PowerPC machines
mentioned above) doesn't have the convention for partition d that the PC
has (as most (all?) of the non-PC platforms).
So the constructed disklabel gets the c partition for the complete disk,
and the MBR partitions are placed into the disklabel partitions d, e and
upwards (NetBSD/ofppc can have up to 16 partitions in the disklabel),
and yes, this does include any secondary partitions found (up to a
maximum of 13 partitions).  (This is where the secondary partition
comes in again, as I told you above :-)).

Now I know that this is by far more than you ever wanted to know about
partitions, but nevertheless it might be of interest to someone.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800