# Partitioning schemes



## hruodr (Jan 10, 2022)

[_Mod: Split off from an 8 year old thread, https://forums.freebsd.org/threads/dd-command.45206/_]

Is there a concise answer to this?

I also expect that it deletes the MBR?

I have the pata disk attached with a IDE to USB converter. Perhaps that is the reason?

EDIT: or perhaps /dev/da0 is not the way to address the whole disk, not as /dev/rsd0c in OpenBSD. But how then the way?


----------



## ralphbsz (Jan 11, 2022)

Yes, /dev/da0 is the correct way to address the whole disk.

No, writing zeroes with dd to the beginning of the disk is not a good way to remove partition tables / slide headers / GPT labels. For several reasons, some of which are explained above: The kernel caches partition tables in memory, and overwriting the disk with dd does not always flush those caches. On an unformatted disk, slices may exist by default. And disks store two copies of the GPT label, the second one at the very end. And sometimes BIOSes have the nasty (good?) habit of updating "lost" copies of GPT labels from the second copy.

Concise answer: Use gpart not dd.


----------



## hruodr (Jan 11, 2022)

Thanks. In any case, I wanted to see that dd does what it is expected. I just
discovered that it does it and that fdisk do not show what is expected: after
filling with zeroes it shows a BSD first slice instead of an unused one.

The problem seems to be what fdisk shows. Not dd.


----------



## ralphbsz (Jan 11, 2022)

To begin with, fdisk is obsolete. I don't understand enough about BIOS booting to know any scenario where it would still be used, but perhaps there are legacy systems where it is still needed. As far as I know, on hardware that is less than 10-15 years old, you can (and shall) always use gpart.

And fdisk is intended to be used interactively, by a person who understands the difference between slice and partition. Not surprising that on a disk that has all zeroes on sector zero, fdisk tries to do something "reasonable", since the assumption is that the user will check the results before saving. I think of tools like fdisk a lot like a surgical knife: The user knows that you don't just stick it in and expect something good to happen. They are powerful, but can have very nasty side effects.


----------



## _martin (Jan 11, 2022)

fdisk is very confusing in this regard. Look at this output: 

```
# hd /dev/md1
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
40000000
# fdisk /dev/md1
******* Working on device /dev/md1 *******
parameters extracted from in-core disklabel are:
cylinders=130 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=130 heads=255 sectors/track=63 (16065 blks/cyl)

fdisk: invalid fdisk partition table found   ;  <--- but pay attention to this
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 2088387 (1019 Meg), flag 80 (active)
    beg: cyl 0/ head 1/ sector 1;
    end: cyl 129/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
#
```
`md1` is a dummy device, all empty and yet fdisk shows you output as if there was a partition. It shows you how the partition could be.

MBR bootcode, i.e. code on LBA 0 in MBR disk scheme, does contain definition of 4 partitions. If you wipe this out (in my example `dd if=/dev/zero of=/dev/md1 count=1`) you'd lose definitions of the partitions. But that's it. This command would not erase slice metadata as those are stored deeper in the disk. With MBR scheme if you don't use enough of count to get to the slice metadata it will be still there.

It does make sense to use tools that are designed to work with the given task (such as gpart nowadays) but dd is for sure handy tool for this too. But you need to know what you're aiming for with dd.


----------



## hruodr (Jan 11, 2022)

ralphbsz said:


> And fdisk is intended to be used interactively, by a person who understands the difference between slice and partition.


And what about installing the filesystem directly, without slice partition or BSD label?
No need to use fdisk and/or disklabel!

And are these efi, uefi, gpt, etc. easier to understand?


----------



## _martin (Jan 12, 2022)

You can create FS directly on raw device but you won't be able to boot off it. 
I'd stay away from MBR layout in FreeBSD when you can use GPT scheme. It's easier, less messy and it has backup of its metadata. But even with MBR you don't need to use fdisk. You have gpart and bsdlabel for that.


----------



## ralphbsz (Jan 12, 2022)

hruodr said:


> And what about installing the filesystem directly, without slice partition or BSD label?
> No need to use fdisk and/or disklabel!


Absolutely possible. Used to do it all the time. Stopped, because it confuses people and things. Today, both humans (sys admins) and firmware (like BIOSes) expect to see a GPT table on every disk. Examples include a human sys admin seeing a disk without a clear purpose (they just looked for the partition table), thinking that it must be unused, and therefore formatting a ReiserFS onto it. That happened so often, it turned into a running joke (about Hans Reiser killing both wives and disks). Also saw a BIOS that if it found the beginning of the disk to be corrupted (not a valid GPT partition table) would kindly overwrite it with whatever it found at the end of the disk ... even if the beginning of the disk was actually in use. So these days I put valid GPTs on every disk (except small USB sticks).



> And are these efi, uefi, gpt, etc. easier to understand?


You are right, the whole area of how to boot and how to store partition information on disks is too complex. People need to be careful around it.


----------



## hruodr (Jan 12, 2022)

_martin said:


> I'd stay away from MBR layout in FreeBSD when you can use GPT scheme. It's easier, less messy and it has backup of its metadata.


Do you mean the GPT scheme is easier, or gpart is easier to use than fdisk?
I wonder, because GPT includes a "protective MBR".


----------



## _martin (Jan 12, 2022)

GPT is easier to use. You're just creating partitions, there are no slices that are being partitioned (MBR case under FreeBSD). gpart command is to be used instead of fdisk nowadays. You still have an option to legacy boot (I prefer this way) or you do the UEFI boot.

"protective MBR" feature of GPT scheme is just to protect itself from tools that don't understand the GPT scheme (i.e. old tools created before GPT existed). It's a dummy MBR with one partition defined. The only thing checked there is the boot signature, nothing else.

Side note: MBR is used both for describing MBR disk layout and bootcode on LBA0 of MBR scheme.


----------



## hruodr (Jan 12, 2022)

_martin said:


> GPT is easier to use. You're just creating partitions, there are no slices that are being partitioned (MBR case under FreeBSD).


An what about putting a BSD disklabel without MBR in the raw disk?

But yes, I would put a trivial MBR and a trivial BSD disklabel to protect the disk from careless firmware, software and humans, as ralfphsz wrote. To put a GPT is too much for that purpose.


----------



## SirDice (Jan 12, 2022)

Note that the maximum size of a MBR partition (in BSD parlance a 'slice') is 2TB. Really, just stop using that antique partitioning scheme. GPT is so much easier.


----------



## hruodr (Jan 12, 2022)

ralphbsz said:


> Also saw a BIOS that if it found the beginning of the disk to be corrupted (not a valid GPT partition table) would kindly overwrite it with whatever it found at the end of the disk ... even if the beginning of the disk was actually in use. So these days I put valid GPTs on every disk (except small USB sticks).


I hope that stupid BIOS would respect a classical MBR.


----------



## SirDice (Jan 12, 2022)

hruodr said:


> I hope that stupid BIOS would respect a classical MBR.


BIOS isn't going to care. BIOS loads the first sector of the disk in memory and passes execution to it. That's it. That's all the BIOS has to do. Some UEFI implementation on the other hand will insist on EFI booting and cannot be configured to CSM boot.


----------



## hruodr (Jan 12, 2022)

SirDice said:


> Note that the maximum size of a MBR partition (in BSD parlance a 'slice') is 2TB. Really, just stop using that antique partitioning scheme. GPT is so much easier.


Is that also the case with BSD disklabels?
In any case, my biggest disks have "only" 500GB.


----------



## SirDice (Jan 12, 2022)

hruodr said:


> Is that also the case with BSD disklabels?




```
COMPATIBILITY
     Due to the use of an uint32_t to store the number of sectors, BSD labels
     are restricted to a maximum of 2^32-1 sectors.  This usually means 2TB of
     disk space.  Larger disks should be partitioned using another method such
     as gpart(8).
```
bsdlabel(8)


----------



## _martin (Jan 12, 2022)

I was about to write what SirDice wrote -- BIOS really doesn't care.

Note though OP in 2014 asked about dd here. What he did was OK - it wiped about the MBR as expected. fdisk is showing confusing data, layout that is really not there (but shows numbers how that partition can be created).


----------



## hruodr (Jan 12, 2022)

SirDice said:


> BIOS isn't going to care. BIOS loads the first sector of the disk in memory and passes execution to it. That's it.


I was refering to the ocasional smart BIOS mentioned by ralphbsz that kindly overwrites the first sector with what it finds at the end of the disk.


----------



## hruodr (Jan 12, 2022)

SirDice said:


> Really, just stop using that antique partitioning scheme.


I still use antique hardware and antique OS. And move disks from one computer to other.

I hope, this EFI, UEFI or what the BIOS substitute is called be backward compatible and able to read MBR.


----------



## SirDice (Jan 12, 2022)

hruodr said:


> I hope, this new partitioning schemes are "backward compatible" and are able to read MBR.


A BIOS isn't going to care if it's GPT or MBR. As I said, the BIOS just reads sector 0 in memory and passes control to the code there. What happens next is going to depend on that code. Even really old hardware is able to read sector 0 and execute the code, BIOS only has to detect the drive and be able to read that first sector.

The PMBR of GPT has, besides a 'fake' MBR partition, code to find and execute the code that's in the freebsd-boot partition. But that's the PMBR code's job, not the BIOS. I have a whole bunch of old equipment and have been using GPT since it was added to FreeBSD, never had an issue with it.


----------



## hruodr (Jan 12, 2022)

SirDice said:


> A BIOS isn't going to care if it's GPT or MBR.


I mean the other way: if a UEFI machine will be able to deal with antique MBR.


----------



## SirDice (Jan 12, 2022)

hruodr said:


> I mean the other way: if a UEFI machine will be able to deal with antique MBR.


Not all UEFI implementations support CSM. You can only EFI boot those systems using an ESP (EFI System Partition).


----------



## hruodr (Jan 12, 2022)

SirDice said:


> The PMBR of GPT has, besides a 'fake' MBR partition, code to find and execute the code that's in the freebsd-boot partition.


Does UEFI also load and run this code, like BIOS?


----------



## SirDice (Jan 12, 2022)

hruodr said:


> Does UEFI also load and run this code, like BIOS?


In CSM mode, yes. EFI boot works a little different, that specifically searches for an efi partition (the ESP). Both MBR and GPT partitioning schemes are supported but I would highly recommend using GPT for EFI boot.


----------



## _martin (Jan 12, 2022)

Systems without UEFI support are booting the (now) "legacy" way, i.e. find the lba0 on a bootable device and let the bootcode deal with the rest.
Newer BIOSes have new way of booting - UEFI boot, some of them provide legacy boot (or CSM as SirDice said). Now talking about FreeBSD you have these options:

1) Old BIOS - only legacy boot - support for both MBR and GPT scheme
2) New BIOS - EFI and/or legacy boot
  MBR scheme - legacy boot possible
  GPT scheme - both legacy and UEFI boot possible

In case of 2) and GPT you can set the disk so FreeBSD is capable of booting both legacy and UEFI. If you want to boot UEFI only pmbr doesn't need to have any bootcode, it can be all 0s (with one big partition defined in the partition definition). Only boot signature at the end of the sector is required (per UEFI standard). UEFI is looking for ESP and does all the booting from there.


----------



## hruodr (Jan 12, 2022)

_martin said:


> 1) Old BIOS - only legacy boot - support for both MBR and GPT scheme


You mean the code in the MBR will deal with GPT partitions?

Many times I felt not understood. And I really have problems understanding you.

When you wrote for example that GPT is easier, it was not clear if you were speaking about gpart easier than fdisk or about GPT scheme easier than MBR scheme. And this kind of confuse writing everywhere. Perhaps you can reflect a little more when you write?

Thanks in any case for your answers!


----------



## hruodr (Jan 12, 2022)

Or in other words, modern FreeBSD on an antique BIOS computers can deal with GPT partitions as antique FreeBSD dealt with BSD disklabels?

Are here GPT partitions a substitute for the BSD disklabels?


----------



## _martin (Jan 12, 2022)

Sorry to hear that. Let me rephrase then. We are talking about this:

a) General way of system booting: legacy (BIOS finds lba0 on a disk and doesn't care any more) or UEFI boot (search for ESP partition)
b) what does FreeBSD support: both MBR and GPT schemes are supported, both legacy and UEFI boot is supported
c) what a) requires per standard (you can't boot UEFI with MBR scheme, you can use both legacy and UEFI with GPT scheme)
d) FreeBSD tools to create the slices/partitions (fdisk(8), bsdlabel(8) and gpart(8)).

Yes, that's correct. FreeBSD with old BIOS can deal with the GPT partitions. On top of it you have an option to create ESP partition and put FreeBSD efi loader there even if your BIOS doesn't support it (you said you're moving disks around, maybe some board does support it).

In Windows/DOS terminology when you use MBR layout you're talking about partitions. You can have maximum of 4 primary partitions (defined in lba0 mbr). You need to subdivide primary partitions into extended partitions. In BSD world partition is called slice and you further partition a slice. It's similar concept.

GPT scheme and partition creation with gpart simplifies things. You only create partitions (max is 128 partitions). As mentioned above FreeBSD is able to do legacy boot on GPT scheme so you can use this on older computer too.


----------



## Erichans (Jan 12, 2022)

SirDice said:


> Both MBR and GPT partitioning schemes are supported but I would highly recommend using GPT for EFI boot.





			
				A Tale of Two Standards (see below) said:
			
		

> To provide arbritarily large partitions, the UEFI Specification defines a *Guided Partion Table (GPT)*[2]


(My emphasis)

EFI and UEFI are not the same but, casually speaking these terms are often used interchangeably.

As to the various combinations, in general, you have (see: UEFI classes):

    Class 0: Legacy BIOS
    Class 1: UEFI in CSM-only mode (i.e. no UEFI booting)
    Class 2: UEFI with CSM
    Class 3: UEFI without CSM
    Class 3+: UEFI with Secure Boot Enabled
For a general medium sized introduction to UEFI (as well as its relation to its predecessors), you might find these helpfull*:

A Tale of Two Standards
UEFI boot: how does that actually work, then?
Reference #1 is mentioned at Home >> Education of the Unified Extensible Firmware Interface Forum. For further reference, there you also find this trio of books:

Beyond BIOS: Developing with the Unified Extensible Firmware Interface, Third Edition 3rd Edition
Harnessing the Uefi Shell: Moving The Platform Beyond Dos, Second Edition
Quick Boot: A Guide for Embedded Firmware Developers, Second Edition
The first title details UEFI as a successor of BIOS.

___
* I mention these and the other three titles also because there are several dead links (or links that refer to partially available sources) on the wikipedia UEFI page, and the other references I mention here may not be easy to find.


----------



## SirDice (Jan 12, 2022)

UEFI - Wikipedia
					






					en.wikipedia.org
				





> Supported partition table schemes include MBR and GPT, as well as El Torito volumes on optical discs.[31]: section 2.6.2


But I do believe EFI-MBR support is rather shoddy. It may not have been implemented in the UEFI you're using. I wouldn't count on it. But I rarely use MBR for anything nowadays. I switched to GPT a really long time ago.


----------



## _martin (Jan 12, 2022)

While I can't say there isn't a firmware out there that is capable of such thing UEFI specification says to use GPT. It tries to parse the GPT header on LBA1 so I'm not sure how would that work (without hacks and effectively faking the GPT header there).


----------



## hruodr (Jan 12, 2022)

One of the reason that I never touched gpart is that I associated it with geom and vinum. I thought it has to do with software raid, not with disk partition. I quote from the handbook:



> In FreeBSD, the GEOM framework permits access and control to classes, such as Master Boot Records and BSD labels, through the use of providers, or the disk devices in /dev.  By supporting various software RAID configurations, GEOM transparently provides access  to the   operating system and operating system utilities.



Till now is not clear to me what the following words above mean mean: framework, classes, providers.

I moved from OpenBSD on i386, with MBR and bsd label, back to FreeBSD with ZFS. I installed it pressing keys like an ape, without thinking too much. Before that I was used to fdisk and disklabel, also to eventually editing the labels manually even on an installed system. Of course it was now with gpart much easier (to press keys when installing, not to understand).

ZFS makes things more obscure. If I had installed FreeBSD with UFS, would I have GPT partitions mounted on /, /usr, /home, etc?

In the whole discussion here, gpart was presented as a substitute of fdisk, perhaps it is a substitute of disklabel or both, but the result is of course something different.

Also we should not confuse a disk for booting an OS with a disk with a filesystem with data. When I put a filesystem in a GPT partition, I will perhaps not be able to mount it in an antique system (i.e. one that does not support GPT).


----------



## ralphbsz (Jan 12, 2022)

hruodr said:


> I hope that stupid BIOS would respect a classical MBR.


Not clear it would; that BIOS was looking for a valid GPT, and considered everything else to be in need of overwriting. We did complain to the manufacturer, and they fixed the "automatic overwrite", but we also started writing valid GPTs on everything.


----------



## _martin (Jan 12, 2022)

hruodr said:


> If I had installed FreeBSD with UFS, would I have GPT partitions mounted on /, /usr, /home, etc?


Correct, given you'd like to split them the same way you had s1a, s1d, s1e in MBR slice. 

I suggest to go through the GEOM(4) and geom(8) to get the idea. Framework is the whole set of classes and tools around it, class can be part (or mirror, raid, multipath, label, ..) and provider can be a physical disk (or memory device, ..).

You have more ways to skin the cat - use fdisk/bsdlabel or use gpart. Or you can actually combine them together (use gpart and bsdlabel). 

I'll repeat myself as you hruodr mentioned I'm maybe not saying it clear enough  -- fdisk is giving you misleading information, it will provide you an output of the partition even if there's none.

While we are talking about the providers -- there's an easy way for you to test this without destroying anything. Example to test the GPT/ufs setup:

```
# truncate -s 1024M testdisk
# mdconfig -a -t vnode -f testdisk
md0
# gpart create -s gpt md0
md0 created
# gpart add -t freebsd-boot -s 512k md0
md0p1 added
# gpart add -t freebsd-ufs -s 128M md0
md0p2 added
# gpart add -t freebsd-ufs -s 512M md0
md0p3 added
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 md0
partcode written to md0p1
bootcode written to md0
#
# gpart show md0
=>     40  2097072  md0  GPT  (1.0G)
       40     1024    1  freebsd-boot  (512K)
     1064   262144    2  freebsd-ufs  (128M)
   263208  1048576    3  freebsd-ufs  (512M)
  1311784   785328       - free -  (383M)
```
I've created an empty file I attached to a memory device. I created GPT scheme, boot partition (legacy boot) and two partitions. md0p2 and md0p3 would be used for FS (/ and /usr for example).
You can use this to create MBR layout too. gpart is capable of doing it allthough I do remember that back then I used bsdlabel (fdisk was used to install mbr (lba 0) and bsdlabel to install bootstrap code on slice). Luckily I don't need to deal with MBR disks under FreeBSD anymore.


----------



## Erichans (Jan 12, 2022)

hruodr said:


> I still use antique hardware and antique OS. And move disks from one computer to other.
> 
> I hope, this EFI, UEFI or what the BIOS substitute is called be backward compatible and able to read MBR.





hruodr said:


> [...] Also we should not confuse a disk for booting an OS with a disk with a filesystem with data. When I put a filesystem in a GPT partition, I will perhaps not be able to mount it in an antique system (i.e. one that does not support GPT).


I do not know what "antique OS" you use; also I maybe overlooking somethings or perhaps stating the obvious but, if you "move disks from one computer to other" things get less complicated if those are just data disks: disks that you don't have to boot from.


----------



## hruodr (Jan 12, 2022)

_martin said:


> I suggest to go through the GEOM(4) and geom(8) to get the idea.


Yes, thanks. But first I must understand ZFS better. All this may take time. I moved back to FreeBSD only due to ZFS, and my knowledge of it is still very superficial. It is not a filesystem like any other.

As I understand you, with GPT we have not anymore the two level partitions: one with MBR for the BIOS, and on a MBR partition a BSD label partition for the OS.

This may have the advantage of bringing a partition standard across many OS. Since for example disklabels in OpenBSD and FreeBSD are almost compatible, but not 100%, I had to edit labels a little in order to mount filesystems from one OS on the other.



Erichans said:


> if you "move disks from one computer to other" things get less complicated if those are just data disks: disks that you don't have to boot from.



Of course. This is what I am saying. But there are still problems mounting filesystems in partitions as I just wrote above.


----------



## grahamperrin@ (Jan 14, 2022)

Erichans said:


> … (My emphasis) …



The document's phrasing – Guided Partition Table (GPT) 𡀲– may be a source of confusion to someone who is learning. 

Instead: GUID Partition Table – <https://en.wikipedia.org/wiki/GUID_Partition_Table> – and in this context, GUID is _globally unique identifier_.


----------

