Two things to keep in mind:
- There there are three distinct partitioning systems in use on MBR/GPT architectures such as amd64. Either an MBR or a GPT are managed by fdisk(8), and then the OpenBSD disklabel is managed by disklabel(8).
- When a physical disk does not have an OpenBSD disklabel on it, the MBR/GPT partition table is scanned looking for recognized foreign filesystems, and OpenBSD assigns them virtually to disklabel partitions starting with partition "i". If that virtual table is written to disk, the disklabel will be used for partitioning information, without scanning the MBR or GPT table.
I'm going to focus on that second item. There are five possible states:
- No partition table of any kind on a disk.
- Only a disklabel on a disk.
- Only an MBR/GPT on a disk.
- Both MBR/GPT table and disklabel, where any foreign filesystem partition aligns with its disklabel partition.
- Both MBR/GPT table and a disklabel, where there is mismatch between the MBR/GPT table and the disklabel.
State 1: When the leading blocks of a drive have been overwritten, the drive is only addressable by OpenBSD through its synthetic "c" disklabel partition, the partition that maps to the entire physical drive. It's easy to create State 1. You can wipe all types of partitioning, just by writing over the first sectors. For example, a
# dd if=/dev/zero of=/dev/sd7c count=100 will put zeros on the first 100 sectors of a drive, overlaying partitioning schema and boot blocks.
State 2: If a drive only has disklabel partitions, but no MBR or GPT, it cannot be booted on an MBR/GPT architecture computer, and cannot be shared with a foreign OS. But it can readily be used for OpenBSD FFS/FFS2 filesystems and for swapping. A foreign filesystem can be added, but it cannot be shared with a foreign OS.
State 3: A disk drive with MBR or GPT partitioning can be used for foreign filesystems without ever having a disklabel physically written to it. Each time the drive is attached or the OS is booted, the MBR/GPT is read and recognized filesystems assigned starting with "i". The virtual disklabel remains in kernel memory, and is only written to disk if you write it with disklabel(8).
State 4: Transitioning from State 3 to State 4 requires only writing the virtual disklabel to disk. Once this is done, the MBR/GPT will not be read again to search for foreign filesystems. It
will be read by disklabel(8) to look for an OpenBSD MBR/GPT partition in order to establish a sector range to add OpenBSD FFS/FFS2 filesystems and swap space. Disk drives in State 4 should only be needed if the drive stores "native" OpenBSD filesystems (FFS/FFS2) or swap space, along with any foreign filesystems.
State 5: It is easy to make this error, by starting from State 4 and then changing foreign filesystems with disklabel only. These changes are stored only in the disklabel, and are not reflected back on the MBR or GPT partition table. Because the MBR/GPT table is not scanned again on OpenBSD, this means the changed partition will only function as intended while running OpenBSD. An OS that scans the MBR/GPT table for filesystems may fail to mount the underlying filesystem if the change has an operational impact. You can prevent this by staying in State 3, with only a virtual disklabel, or keeping the disklabel and MBR/GPT changes in sync.