Hello!
After partitioning a new disk with MBR, creating two primary partitions, I was trying to define a disklabel in each of them. Quite soon I realized it was not possible. After an IRC conversation, which was very instructive yesterday, here are some considerations.

An important premise is that disklabel, MBR and GPT are data structures intended to describe a whole disk, not a single partition: internally, they then divide the disk into partitions. These single partitions can not host themselves a disklabel, an MBR or a GPT to further subdivide them, because they are not an entire disk.

Maybe this is trivial, but during the installation of NetBSD a disklabel is actually nested inside a primary MBR partition. So, I would like to share some further clarification.

Assume that you have this example MBR:

1. NTFS, Windows system partition
2. NTFS, Windows data
3. (empty)
4. (empty)

(for simplicity, I will not consider the case of extended partitions, but it would be similar).

Assume that, when installing NetBSD with sysinst(8), partition 3. is chosen for NetBSD. sysinst(8) does not change MBR in this case (thus preserving primary partitions 1. and 2.).

There are several other options:

sysinst(8) may create a brand new MBR (warning: this will destroy all the existing data on the disk), with primary partitions defined by the user, who can then choose which of them will be used for NetBSD;
through sysinst(8) the user may also modify an existing MBR, and in this case it's his responsibility to preserve the partitions dedicated to other OSs and to manage only the free space in the disk for NetBSD;
sysinst(8) also offers the chance to Use the entire disk: in this case, it creates anyway a MBR, with a primary partition which extends to the whole disk, used for NetBSD.

As you may note, the use of MBR is never abandoned. This is done for two reasons:

to grant the compatibility with PC/DOS (and other OSs like Windows this way can still use the same disk);
to grant a regular boot on PC/IBM hardware (where, without a valid MBR, the BIOS could not even try to search a bootloader on the disk).

Note that the above behaviour is about amd64; for other ports it may change.

Whatever choices the user makes, in the end there will be an MBR primary partition dedicated exclusively to NetBSD. Inside it, sysinst(8) installs disklabel. disklabel(8) allows to further divide this NetBSD-dedicated MBR partition, originating disklabel partitions a (which is generally used for the NetBSD root directory /), b (generally used for swap), e (it may be /home, for example), f (for example, /usr), g (for example, /var), etc.; in amd64, partitions c and d are reserved, to represent respectively the NetBSD MBR primary partition and the whole disk, as shown here.

It may seem that this disklabel, nested into an MBR primary partition, is used to further divide internally this partition: so, for another MBR primary partition on the same disk, there may be another disklabel which can be used the same way. This is wrong.

Disklabel is an alternative, and not an integration, to MBR.

In the case of an amd64 NetBSD installation inside a PC/DOS disk, the disklabel is placed inside the MBR primary partition dedicated to NetBSD, in the second block (and the first block is used for the NetBSD bootloader). This is done to make sure that the disklabel data structure is preserved and not altered or deleted by the action of other OSs: in fact, the MBR primary partition dedicated to NetBSD is not used by DOS or similar OSs, but it is recognized by them. Without this issue, disklabel (whose location is flexible) could be placed in the second sector of the disk (while MBR is in the first), not the second sector of a specific partition.

When the machine is booted with NetBSD, disklabel is the only way NetBSD looks at the disk, the entire disk; MBR in this case is not considered at all. (Obviously, during the installation, a reference to the NetBSD bootloader is placed in the boot sector of MBR, so that NetBSD can be booted). Disklabel provides exactly all the information MBR provides, but in a way NetBSD can understand. It provides the full size of the disk (disklabel partition d for amd64), the size and location of the usable portion of the disk (disklabel partition c, for example, which represents in amd64 the NetBSD primary partition), and the structure of this portion of the disk (disklabel custom partitions a, b, e, f, g, etc.). Thinking about MBR, it actually provides the same information, but in a way the other OSs can understand: the full size of the disk, the size and location of the usable portion(s) of the disk and their structure (all the primary partitions whose type is DOS-compatible).

Disklabel and MBR are then just two alternative ways to represent the same reality, the whole disk. The former is used by NetBSD and the latter is used by DOS-compatible OSs like Windows, for the same disk. The location of disklabel (nested inside an MBR primary partition) is just a consequence of possible compatibility issues with other OSs. But both MBR and disklabel are meant to be unique inside a disk (and in systems where PC/IBM compatibility issues are absent, they should not even coexist: disklabel only is used; on the other hand, in a Windows PC, only MBR is used). A disk can not host more than one MBR, or more than one disklabel. My initial intention of creating multiple disklabels, one for each MBR primary partition, was wrong.

Here, Figure 2.1 well describes the way disklabel (and so, NetBSD) looks at the whole disk. Refer to the blue labels, on the right of the image. The same Figure also well describes the way MBR (and so, a DOS-compatible OS) looks at the whole disk: refer to the red labels, in the center of the image.

The fact that NetBSD only uses disklabel for his awareness of the disk is also proved by the /dev directory: for each disk, for example wd0, only the disklabel partitions are available: wd0a, wd0b, etc. (along with the corresponding raw partitions rwd0a, rwd0b, etc.). There is no way to reference the other MBR primary partitions (so, installing a disklabel on them would be impossible, other than uncorrect), because from the NetBSD (and disklabel) perspective, they simply do not exist: it only exists a portion of the disk which is not used by any disklabel partition (and where actually are placed the eventual other MBR primary partitions).

All the above considerations are assuming that a single NetBSD OS is installed in a disk. They may change if two or multiple NetBSD systems are installed in the same disk, but this is a possible conflicting and confusing scenario, which I would discourage.

This is different on FreeBSD, where the MBR primary partitions are accessible for each disk: for example, /dev/ada0s1 refers to the first MBR primary partition of disk ada0 (s means slice, another way MBR primary partitions are called). In FreeBSD, /dev also has ada0s1a, ada0s1b, etc., if ada0s1 has a UFS filesystem). I don't know if FreeBSD also manages in a different way the coexistence of MBR and disklabel.

GPT is used for the same purpose as MBR and disklabel: it describes the structure of an entire disk. There's however a difference in the way NetBSD integrates with it: while MBR is an alien system for NetBSD, GPT is supported. So, for example, if a new disk is added to an existing NetBSD system, and this disk is partitioned with GPT, there's no need of a disklabel. For each new partition, GPT in NetBSD automatically creates a wedge (dk0, dk1, etc.). Wedges are the equivalent of a partition, not a disk, so a disklabel can not be placed on them (also, /dev has no dk0a, dk0b, etc., but only dk0, dk1, etc.). A new filesystem (FFSv2, for example) can be directly created on a wedge. I don't know if a disklabel is installed when GPT is used to partition a NetBSD system disk (the one hosting the root / directory), but I don't think so.

GPT is available to partition a system disk when performing a UEFI installation, but IIRC a traditional BIOS installation does not offer GPT.

As well, if a new disk is added to an existing NetBSD system (so, it is not a boot disk), it may be partitioned using only disklabel, not MBR or GPT. Avoiding in amd64 the reserved partitions c and d, the other letters may be arbitrary related to any data contents (with any mountpoint).

These observations would not have been possible without the help of the users in the #netbsd channel on Freenode IRC. I would like to thank them so much. If any of them wants to integrate these notes and/or correct something, is welcome.

Thank you again!

Rocky

The original message is from the @netbsd-users mailing list: I thought it could also be useful here.