Partitioning schemes

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!
 
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?
 
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.
 
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*:
  1. A Tale of Two Standards
  2. 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:
  1. Beyond BIOS: Developing with the Unified Extensible Firmware Interface, Third Edition 3rd Edition
  2. Harnessing the Uefi Shell: Moving The Platform Beyond Dos, Second Edition
  3. 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.
 
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.
 
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).
 
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).
 
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.
 
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:
Code:
# 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.
 
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.
[...] 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.
 
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.

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.
 
Back
Top