# disk partitioning : general FreeBSD requirements and constraints



## lbc (Oct 5, 2012)

For the past 15 years, I've been running DOS, Windows, and GNU/Linux OSen, using exclusively MBR partition tables, and setting up lots of multi-boot systems for experimenting with hardware. I've recently regained an interest in running FreeBSD (ZFS anyone?), which is quite paradigm-shifting in these areas, from my point of view. (What a surprise to discover that GPT tables don't actually require UEFI!)

I've cowardly avoided delving into these matters on my previous FreeBSD and OpenBSD installations (and created pretty messy setups as a consequence); I am now trying to get a solid understanding of what can, cannot, and shouldn't be done with disks to run FreeBSD, whether by itself or together with other operating systems on the same disk.

I've tinkered with a couple of virtual machines plus a bunch of virtual disks, and read the gpart(8), fdisk(8) and bsdlabel(8) manpages these past days, but I'm having trouble linking everything together; I am often finding myself unable to simply create the partition layouts I'd like to experiment with, and when I can, I encounter minimalistic errors returned by bsdinstall(8) that don't help me understand the rules.

Hence, I have a (generous, I realize) bunch of question, ranging from confirmation seeking of things I'm almost sure of, to ones I am truly clueless about. I hope this isn't asking too much at once. Please feel free to cherry-pick the ones you like, or to just point me to online documents that might help me help myself.


*Regarding what is needed to bootstrap FreeBSD*

 - The handbook calls _freebsd-boot_ a "Standard FreeBSD GPT Partition". Does it imply such a partition does not have a direct equivalent in an MBR scheme?
- is it meant as a cleaner way to hold bootstrap code that is otherwise stored in Volume Boot Records of MBR partitions?​- would that mean that there are no VBRs in GPT partitions?​
- Is it anything more than a container for machine code, not in any way able to be organized into a filesystem that can be mounted?​
- Can this _frebsd-boot_ partition be located anywhere on disk? 
- On an isolated, non-BSD-subpartitioned primary MBR partition?​- located before the root partition?​- located after the root partition? (I've taken the habit of creating boot partitions at the end of disks). (add. 2012.11.03: yes, this works, tested in VM.)​
- Inside a BSD-partitioned slice?​- before the root ? after the root?​- Within a different slice than the root filesystem?​- Can they be shared among multiple FreeBSD installations?
- gpart(8) describes 2 (early) boot mechanisms (/boot/mbr and /boot/boot0), both of which search for "*the* _freebsd-boot_ partition". This seems to imply two separate ones cannot in fact be used, is this correct?​

*Regarding what is needed for the root filesystem(s)*

- Is it possible to run FreeBSD in an MBR-partitioned disk, but without subpartitiong it using BSD partitions? 
- using only a root filesystem and no swap partition?​- using a root filesystem and a swap partition and/or a boot partition on different primary MBR partitions?​
- It is possible to have 2 separate installations of FreeBSD stored on two separate slices. Is it possible to have 2 separate installations of FreeBSD stored on the *same* slice? (perhaps because of shortage of available primary MBR partitions)


*Regarding BSD partitions*

- Are disklabels nothing more and nothing less than a piece of metadata that act as a BSD partition descriptor, written to the beginning of a slice?

- Can the term _disklabel_ or _bsdlabel_ be used as a more elegant and less ambiguous synonym than _BSD partition_?

- Are bsdlabel(8) and gpart(8) the two only (FreeBSD native) tools that exist to manipulate (as in: modify) BSD partition layout? (not counting dd  )

- I have a feeling that BSD partitions are becoming less relevant or necessary than they might have been in the past. Is this true? Is it mainly due to the increased flexibility and simplicity that GPT schemes provide? It surely seems that both the handbook and bsdinstall(8) are pushing this scheme, barely if not at all mentioning the existence of BSD partitions.

- Can a GPT partition be subdivided with a BSD label? (perhaps to mark a clean separation and hierarchy between distinct FreeBSD installations, or between sets of user data)


*Regarding logical MBR partitions (slices) :*

- My understanding is that they are pretty much unusable by FreeBSD, except for mounting foreign filesystem located on them. Is there absolutely no way to use boot code, kernels, root filesystems inside one? More usefully given my usual multiboot partitioning layout, is there a way to use one as a swap partition? (perhaps to share swap space with other OSen, to reap the performance benefits of being located at the beginning of a hard drive, or on media where space is costly (such as SLC SSDs)

- Will fdisk(8) never see, communicate or manipulate logical MBR partitions? Is there a FreeBSD native tool to create and manipulate them? (perhaps to provision them for later foreign OSen installations)

- Is it possible to BSD-partition a logical MBR partition? (perhaps to cleanly organize and hierachize data-only FreeBSD user data partitions)


Thank you for reading.


----------



## wblock@ (Oct 5, 2012)

lbc said:
			
		

> *Regarding what is needed to bootstrap FreeBSD*
> 
> - The handbook calls _freebsd-boot_ a "Standard FreeBSD GPT Partition". Does it imply such a partition does not have a direct equivalent in an MBR scheme?



Yes.  Partitions are expensive with MBR, cheap with GPT.



> - is it meant as a cleaner way to hold bootstrap code that is otherwise stored in Volume Boot Records of MBR partitions?​



Yes.



> - would that mean that there are no VBRs in GPT partitions?​



AFAIK, that's correct.



> - Is it anything more than a container for machine code, not in any way able to be organized into a filesystem that can be mounted?​



It's just a place to store binary bootcode, no filesystem.



> - Can this _frebsd-boot_ partition be located anywhere on disk?



On a GPT disk, I think that's correct.



> - On an isolated, non-BSD-subpartitioned primary MBR partition?​



freebsd-boot, AFAIK, is only useful for GPT.



> - Can they be shared among multiple FreeBSD installations?



I think it will boot the first UFS partition on the (GPT) disk.



> - gpart(8) describes 2 (early) boot mechanisms (/boot/mbr and /boot/boot0), both of which search for "*the* _freebsd-boot_ partition". This seems to imply two separate ones cannot in fact be used, is this correct?​



These are really part of the same program, only split into two pieces because the first has to be small enough to fit in the MBR.  See the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html.



> *Regarding what is needed for the root filesystem(s)*
> 
> - Is it possible to run FreeBSD in an MBR-partitioned disk, but without subpartitiong it using BSD partitions?



Yes.  bsdlabel(8) just gave the ability for more than four partitions before GPT (and before MBR/EBR, incidentally).



> - using only a root filesystem and no swap partition?​



Sure, but FreeBSD works better with at least some swap.



> - using a root filesystem and a swap partition and/or a boot partition on different primary MBR partitions?​



UFS filesystem on one partition, swap on the other.  No boot partition needed with MBR.  If you intend to multi-boot, whatever you use now should work, or you can use FreeBSD's tiny multi-boot loader, installed with boot0cfg(8).  Or you could just go with VMs to avoid all this.



> - It is possible to have 2 separate installations of FreeBSD stored on two separate slices.



Yes, possibly with a shared slice for swap.



> Is it possible to have 2 separate installations of FreeBSD stored on the *same* slice? (perhaps because of shortage of available primary MBR partitions)



Not without using bsdlabels or some ugly filesystem manipulation.



> *Regarding BSD partitions*
> 
> - Are disklabels nothing more and nothing less than a piece of metadata that act as a BSD partition descriptor, written to the beginning of a slice?



Not quite.  It's a partition table, one that actually predates MBR.  It can be put onto a bare disk, inside an MBR slice.  I'm pretty sure it could be used in a GPT partition if there were a practical reason.



> - Can the term _disklabel_ or _bsdlabel_ be used as a more elegant and less ambiguous synonym than _BSD partition_?



Yes, although there may be "disklabels" from other systems that are not compatible with bsdlabel(8).



> - Are bsdlabel(8) and gpart(8) the two only (FreeBSD native) tools that exist to manipulate (as in: modify) BSD partition layout? (not counting dd  )



Yes.  But bsdlabel(8) only does that, and gpart(8) does that, plus MBR, plus GPT, plus Sun, Apple, and other disk partitioning.



> - I have a feeling that BSD partitions are becoming less relevant or necessary than they might have been in the past. Is this true? Is it mainly due to the increased flexibility and simplicity that GPT schemes provide? It surely seems that both the handbook and bsdinstall are pushing this scheme, barely if not at all mentioning the existence of BSD partitions.



Yes.  There is little reason to use two utterly different partitioning schemes (MBR/bsdlabel) when only one simpler and more powerful one (GPT) is available.



> - Can a GPT partition be subdivided with a BSD label? (perhaps to mark a clean separation and hierarchy between distinct FreeBSD installations, or between sets of user data)



Untested by me, but I'd bet yes it can.  And no, don't do that.  What problem does it solve that just using separate GPT partitions does not?  The standard GPT implementation provides 128 partitions.



> *Regarding logical MBR partitions (slices) :*
> 
> - My understanding is that they are pretty much unusable by FreeBSD, except for mounting foreign filesystem located on them. Is there absolutely no way to use boot code, kernels, root filesystems inside one? More usefully given my usual multiboot partitioning layout, is there a way to use one as a swap partition? (perhaps to share swap space with other OSen, to reap the performance benefits of being located at the beginning of a hard drive, or on media where space is costly (such as SLC SSDs)



Actually, logical partitions are usable by FreeBSD.  AFAIR it was just a problem of the FreeBSD MBR code not being able to boot from them.  So if you use Grub or some other boot loader, no problem.  Once booted, FreeBSD has no problem using those partitions for FreeBSD or other filesystems.



> - Will fdisk(8) never see, communicate or manipulate logical MBR partitions? Is there a FreeBSD native tool to create and manipulate them? (perhaps to provision them for later foreign OSen installations)



fdisk(8), probably not.  gpart(8) can handle them already.



> - Is it possible to BSD-partition a logical MBR partition? (perhaps to cleanly organize and hierachize data-only FreeBSD user data partitions)



Probably.  But the sooner logical partitions die out, the better.

Most of these questions relate to multi-booting.  Please consider the alternative of VM software with virtual disks, which eliminates most of the problems.


----------

