Tag Archives: gpt

Booting Linux on a 3TB disk with grub2

I recently purchased a 3TB disk for my home server.
All disks of size 2TB and above cannot be partitioned using the standard fdisk tool. They require a GPT partition table.
First of all install parted and gnu-fdisk (an fdisk replacement based on libparted):

apt-get install parted gnu-fdisk

Assuming the 3TB disk is sda, run:

parted /dev/sda
mklabel gpt

Skip over to tl;dr if you are not interested in the details:

When using a GPT partition table, grub2 requires a small dedicated partition at the beginning of the disk. It will use the first 2 MB of this partition to store core.img.
This is explained with a cryptic statement in the manual of grub2:

GRUB2 in BIOS-GPT configuration requires a BIOS Boot Partition to embed its core.img in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table).
For a BIOS-GPT configuration, create a 2 MiB partition using cgdisk or GNU Parted with no filesystem. The location of the partition in the partition table does not matter but it should be within the first 2 TiB region of the disk. It is advisable to put it somewhere in the beginning of the disk before the /boot partition. Set the partition type to “EF02” in cgdisk or set bios_grub on in GNU Parted.

Create a small partition (a BIOS Boot Partition) at the beginning of the disk and don’t format it. You can use:

unit s
mkpart biosboot 8192 16383
set 1 bios_grub on

There is a very important reason for choosing 16383 as the end of the BIOS Boot Partition.
The next partition will start at sector 16384 and 16384 is a multiple of 4096.

Why is it important to choose a multiple of 8 as the beginning sector of the partition?
Newer hard drives utilize a 4KB sector internally, but they announce a sector size of 512 bytes to the operating system.
It’s very important therefore to make every partition start at a multiple of 4096. This way the 512 bytes block used by the operating system will always be aligned to the 4KB block actually used by disk.
If you fail to do so, whenever the operating disk will need to read 4x 512 byte blocks, it’ll actually read 3x 4KB blocks, thus transferring 3 times more data than it actually needed.
If the 512 byte blocks are aligned to the 4KB blocks, it’d have transferred just those 4KB.