Rocky Hotas
5 years ago
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),
<http://www.netbsd.org/docs/guide/en/chap-exinst.html>
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
(https://www.netbsd.org/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:
<http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst-installdoc>
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.
Figure 2.1 in
<http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst-installdoc>
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 rdw0a, 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 is 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:
<https://wiki.netbsd.org/Installation_on_UEFI_systems/>
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
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
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),
<http://www.netbsd.org/docs/guide/en/chap-exinst.html>
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
(https://www.netbsd.org/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:
<http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst-installdoc>
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.
Figure 2.1 in
<http://www.netbsd.org/docs/guide/en/chap-inst.html#chap-inst-installdoc>
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 rdw0a, 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 is 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:
<https://wiki.netbsd.org/Installation_on_UEFI_systems/>
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
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de