User:Zulu Foxtrott/ARM64/Blocks/Disks

Partition tables
Although it is theoretically possible to use a raw, unpartitioned disk to house a Linux system (when creating a btrfs RAID for example), this is almost never done in practice. Instead, disk block devices are split up into smaller, more manageable block devices. On systems, these are called partitions. The current standard partitioning technology is GPT, whereas older systems might still use MBR (Master boot record, sometimes also called DOS disklabel).

GPT
The GPT (GUID Partition Table) setup uses 64-bit identifiers for the partitions, which means there is practically no limit on the amount of partitions for a GPT disk. Also the size of a partition is bounded only by a quite big limit (almost 8 ZiB - yes, zebibytes).

GPT also takes advantage of checksumming and redundancy. It carries CRC32 checksums to detect errors in the header and partition tables and has a backup GPT at the end of the disk. This backup table can be used to recover damage of the primary GPT near the beginning of the disk.

Default partitioning scheme
Throughout the remainder of the handbook, the following partitioning scheme will be used as a simple example layout:

What is the firmware partition?
Some target systems expect the firmware (the software that performs the first steps of hardware initialization upon powering on the system) to be present on the storage device of choice itself as they don't ship with this software preinstalled. In contrast to that, legacy and more traditional hardware usually comes with its firmware (also known as BIOS or UEFI) stored in read-only memory (ROM).

Depending on the target system the firmware is usually provided by the hardware vendor/manufacturer. However, for a growing - but still small - number of systems opensource U-Boot can provide the same functionality in form of the (Tertiary Program Loader) and the  (Secondary Program Loader).

Such partitions are not always necessary, but considering the low space consumption and how difficult it is to document the plethora of partitioning differences otherwise, it is recommended to create it in either case.

What is the bootloader partition?
On systems that are supported by mainline U-Boot, this is the partition where U-Boot Proper - the main U-Boot program - itself is installed.

Again, such partitions are not always necessary, but they also don't demand a lot of resources.

What is the EFI System Partition (ESP)?
When installing Gentoo on a system that uses UEFI to boot the operating system, then it is important that an EFI System Partition (ESP) is created. The instructions for below contain the necessary pointers to correctly handle this operation.

The ESP must be a FAT variant (sometimes shown as vfat on Linux systems). The official UEFI specification denotes FAT12, 16, or 32 filesystems will be recognized by the UEFI firmware, although FAT32 is recommended for the ESP. Proceed in formatting the ESP as FAT32:

The EFI system partition is not required when the target system is supported by mainline U-Boot.

Default Btrfs filesystem layout
Btrfs is a modern copy-on-write (CoW) filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair, and easy administration. With Btrfs it's possible to use subvolumes to replicate the functionality - organizing and managing data - of what on older systems used to be implemented by an advanced partitioning scheme. Btrfs subvolumes are not block level devices, they are POSIX file namespaces. They can be created at any location in the filesystem and will act like any other directory on the system with the exception that subvolumes can be mounted and unmounted.

TODO: does the link below work?

In case a filesystem other than Btrfs will be used, skip this section and directly go to the Alternative: Designing a partition scheme.

Throughout the remainder of the handbook, the following structure for the Btrfs filesystem on will be used as a simple example layout:

If this suffices, immediately jump to Using parted to partition the disk.

Before going to the creation instructions, the first set of sections will describe in more detail how to use Btrfs subvolumes to organize data and how, alternatively, partitioning schemes can be created and what some common pitfalls are.

{ {Handbook:Parts/Blocks/LayoutBtrfsSubvolumes}}

Partition the storage device
To partition the storage device of choice use, a partitioning utility and one of the first to support GPT partitions on Linux.

In this chapter, the example partition layout mentioned earlier in the instructions will be used:

Change the partition layout according to personal preference.

Viewing the current partition layout with parted
The application offers a simple interface for partitioning storage media like disks and supports very large partitions (more than 2 TB). Fire up against the storage device of choice (in the example, we use ). It is recommended to ask to use optimal partition alignment:

Alignment means that partitions are started on well-known boundaries within the storage device, ensuring that operations on the storage device from the operating system level (retrieve pages from the device) use the least amount of internal device operations. Misaligned partitions might require the device to fetch two pages instead of one even if the operating system asked for a single page.

To find out about all options supported by parted, type and press return.

Setting the GPT label
With, the command to put a GPT label on the storage device is :

Removing all partitions with parted
If this isn't done yet (for instance through the operation earlier, or because the storage device is a freshly formatted one), first remove all existing partitions from the device. Type to view the current partitions, and  where   is the number of the partition to remove.

Do the same for all other partitions that aren't needed. However, make sure to not make any mistakes here - parted executes the changes immediately (unlike the traditional which stages them, allowing a user to "undo" his changes before saving or exiting fdisk).

Creating the partitions
Now will be used to create the partitions with the following settings:


 * The name of a partition
 * The start location of a partition (which can be expressed in MiB, GiB, ...)
 * The end location of the partition (which can be expressed in MiB, GiB, ...)

First, tell parted that the size unit we work with is kibibytes (abbreviated as KiB in the "standard" notation):

Then create a 4096 KiB partition (called "firmware" according to the example partition layout) that can be used for software taking care of initializing the target system's hardware, and inform to start from 32 KiB and end at 4128 KiB (creating a partition of 4096 KiB in size).

TODO: instructions how to deal with alignment warning

Do the same for the bootloader partition (starting at 8192KiB, size 4096KiB).

After these two rather small partitions are created, it is time to create the bigger ones. To make things easier, change the size unit for to work with to mebibytes (abbreviated as MiB).

Now create a 128 MiB partition that will serve as the boot partition. Tell with the  command to start from 16 MiB and end at 144 MiB (creating a partition of 128 MiB in size). Then turn on the flag for the newly created third partition.

TODO: disk model? TODO: 16MiB or 16.0MiB?

Last, create the main partition that spans the remaining space on the storage device (for which the end location is marked as -1, meaning the end of the disk minus one MiB, which is the farthest a partition can go).

The end result looks like so:

TODO: 12/16MiB or 12.0/16.0?

Use the command to exit parted.

With the partitions created, it is now time to put filesystems on them.