Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Nov 2014 07:06:49 +0000
From:      "Pokala, Ravi" <rpokala@panasas.com>
To:        "borjam@sarenet.es" <borjam@sarenet.es>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>
Subject:   Re: BIOS booting from disks > 2TB
Message-ID:  <D0916F70.124566%rpokala@panasas.com>

next in thread | raw e-mail | index | archive | help
Hi Borja,

I'd like to clarify something important - you don't need to boot using
UEFI to use GPT for partitioning. You *do* need to use GPT to have
partitions larger than 2^32 sectors (2TiB for drives w/ 512B sectors, or
16TiB for drives w/ 4KB sectors).

When you perform your installation, just make sure to select the GPT
option for partitioning. The installer (either `bsdinstall' (for stock
FreeBSD), or `pc-sysinstall' (for PC-BSD / FreeNAS)) should create both
primary (near start-of-disk) and backup (at end-of-disk) GPT tables, and
install the appropriate bootstrap code in the proper locations.

Hope that helps,

Ravi

--------

Details, for those who are interested:

The firmware reads LBA 0 to find the Master Boot Record (MBR). In both
cases:

    - the first 446 bytes are executable code

    - the next 64 bytes are the slice table

    - the last 2 bytes are the MBR signature

----

In the slice/label partitioning scheme (some of the details might be
slightly off, but the big picture is right):

    - the 446-byte executable code [mbr.s] reads the slice table, finds
the first-stage bootloader [boot0.S], and executes it

    - the first-stage bootloader finds the second-stage bootloader
[boot1.S], and executes it

    - the second-stage bootloader reads the disklabel, finds the
third-stage bootloader [boot2.c], and executes it

    - the third-stage bootloader reads the UFS filesystem, finds the
`loader' binary, and executes it

----

In the case of GPT, the slice-table portion of the MBR contains a single
slice entry which covers the whole disk. This protects a non-GPT-aware
slicer from trying to add slices. For this reason, it is referred to as
the Protective MBR (PMBR).

In the GPT scheme (I'm more confident about this):

    - the 446-byte executable code [pmbr.s] finds the GPT Header

    - based on the GPT Header, the PMBR finds the GPT Table

    - based on the GPT Table, the PMBR finds the GPT bootstrap [gptldr.S,
gptboot.c], and executes it

    - the GPT bootstrap reads the UFS filesystem, finds the `loader'
binary, and executes it

Note that, by not having to find and parse a separate disklabel in
addition to a partition table, the GPT bootstrap actually has fewer stages.

--------

Source, for those who are *really* interested:

[mbr.s] - sys/boot/i386/mbr
[boot0.S] - sys/boot/i386/boot0
[boot1.S] - sys/boot/i386/boot2 # Yes, boot1 is in the boot2 directory
[boot2.c] - sys/boot/i386/boot2
[pmbr.s] - sys/boot/i386/pmbr
[gptldr.S, gptboot.c] - sys/boot/i386/gptboot

--rpokala




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0916F70.124566%rpokala>