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:
| Partition | Filesystem | Size | Description |
|---|---|---|---|
| /dev/mmcblk0p1 | (firmware) | 4M | Firmware partition |
| /dev/mmcblk0p2 | (bootloader) | 4M | Bootloader partition |
| btrfs (or fat32 if UEFI is being used) | 128M | Boot/EFI system partition | |
| /dev/mmcblk0p4 | btrfs (or crypto_LUKS if disk encryption is being used) | Rest of the disk | Main partition (or encrypted main partition) |
It is advised not to create more than 7 partitions on MMC block devices, as properly supporting this would require setting additional kernel cmdline parameters or kernel configuration options.
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 TPL (Tertiary Program Loader) and the SPL (Secondary Program Loader).
The CPU first loads the TPL and only afterwards the SPL.
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.
U-Boot can provide the UEFI services necessary to comply with EBBR (Embedded Base Boot Requirements).
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 parted 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:
root #mkfs.fat -F 32 If a FAT variant is not used for the ESP, the system's UEFI firmware is not guaranteed to find the bootloader (or Linux kernel) and most likely be unable to boot the system!
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 /dev/mmcblk0p4 will be used as a simple example layout:
| Subvolume name | Parent volume | Future mountpoint | Description |
|---|---|---|---|
| not to be mounted by default | Toplevel volume | ||
| rootvol | Toplevel volume | / | Subvolume to accomodate the root filesystem (rootfs) |
| homevol | Toplevel volume | /home | Subvolume for the Users' home directories |
| swapvol | Toplevel volume | /var/swap | Subvolume to host the swapfile |
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}}
Designing a partition scheme
How many partitions and how big?
The design of disk partition layout is highly dependent on the demands of the system and the file system(s) applied to the device. If there are lots of users, then it is advised to have /home on a separate partition which will increase security and make backups and other types of maintenance easier. If Gentoo is being installed to perform as a mail server, then /var should be a separate partition as all mails are stored inside the /var directory. Game servers may have a separate /opt partition since most gaming server software is installed therein. The reason for these recommendations is similar to the /home directory: security, backups, and maintenance.
In most situations on Gentoo, /usr and /var should be kept relatively large in size. /usr hosts the majority of applications available on the system and the Linux kernel sources (under /usr/src). By default, /var hosts the Gentoo ebuild repository (located at ) which, depending on the file system, generally consumes around 650 MiB of disk space. This space estimate excludes the and directories, which will gradually fill with source files and (optionally) binary packages respectively as they are added to the system.
How many partitions and how big very much depends on considering the trade-offs and choosing the best option for the circumstance. Separate partitions or volumes have the following advantages:
- Choose the best performing filesystem for each partition or volume.
- The entire system cannot run out of free space if one defunct tool is continuously writing files to a partition or volume.
- If necessary, file system checks are reduced in time, as multiple checks can be done in parallel (although this advantage is realized more with multiple disks than it is with multiple partitions).
- Security can be enhanced by mounting some partitions or volumes read-only,
nosuid(setuid bits are ignored),noexec(executable bits are ignored), etc.
However, multiple partitions have certain disadvantages as well:
- If not configured properly, the system might have lots of free space on one partition and little free space on another.
- A separate partition for /usr/ may require the administrator to boot with an initramfs to mount the partition before other boot scripts start. Since the generation and maintenance of an initramfs is beyond the scope of this handbook, we recommend that newcomers do not use a separate partition for /usr/.
- There is also a 15-partition limit for SCSI and SATA unless the disk uses GPT labels.
Installations that intend to use systemd as the service and init system must have the /usr directory available at boot, either as part of the root filesystem or mounted via an initramfs.
What about swap space?
| RAM size | Suspend support? | Hibernation support? |
|---|---|---|
| 2 GB or less | 2 * RAM | 3 * RAM |
| 2 to 8 GB | RAM amount | 2 * RAM |
| 8 to 64 GB | 8 GB minimum, 16 maximum | 1.5 * RAM |
| 64 GB or greater | 8 GB minimum | Hibernation not recommended! Hibernation is not recommended for systems with very large amounts of memory. While possible, the entire contents of memory must be written to disk in order to successfully hibernate. Writing tens of gigabytes (or worse!) out to disk can can take a considerable amount of time, especially when rotational disks are used. It is best to suspend in this scenario. |
There is no perfect value for swap space size. The purpose of the space is to provide disk storage to the kernel when internal dynamic memory (RAM) is under pressure. A swap space allows for the kernel to move memory pages that are not likely to be accessed soon to disk (swap or page-out), which will free memory in RAM for the current task. Of course, if the pages swapped to disk are suddenly needed, they will need to be put back in memory (page-in) which will take considerably longer than reading from RAM (as disks are very slow compared to internal memory).
When a system is not going to run memory intensive applications or has lots of RAM available, then it probably does not need much swap space. However do note in case of hibernation that swap space is used to store the entire contents of memory (likely on desktop and laptop systems rather than on server systems). If the system requires support for hibernation, then swap space larger than or equal to the amount of memory is necessary.
As a general rule for RAM amounts less than 4 GB, the swap space size is recommended to be twice the internal memory (RAM). For systems with multiple hard disks, it is wise to create one swap partition on each disk so that they can be utilized for parallel read/write operations. The faster a disk can swap, the faster the system will run when data in swap space must be accessed. When choosing between rotational and solid state disks, it is better for performance to put swap on the solid state hardware.
It is worth noting that swap files can be used as an alternative to swap partitions; this is mostly helpful for systems with very limited disk space.
Partition the storage device
To partition the storage device of choice use Parted, 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:
| Partition | Description |
|---|---|
| /dev/mmcblk0p1 | Firmware partition |
| /dev/mmcblk0p2 | Bootloader partition |
| Boot/EFI system partition | |
| /dev/mmcblk0p4 | Main partition |
Change the partition layout according to personal preference.
Viewing the current partition layout with parted
The parted application offers a simple interface for partitioning storage media like disks and supports very large partitions (more than 2 TB). Fire up parted against the storage device of choice (in the example, we use /dev/mmcblk0). It is recommended to ask parted to use optimal partition alignment:
root #parted -a optimal /dev/mmcblk0GNU Parted 2.3 Using /dev/mmcblk0 Welcome to GNU Parted! Type 'help' to view a list of commands.
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 help and press return.
Setting the GPT label
With parted, the command to put a GPT label on the storage device is mklabel gpt:
Changing the partition type will remove all partitions from the storage device. All data on the device will be lost.
(parted)mklabel gptRemoving all partitions with parted
If this isn't done yet (for instance through the mklabel operation earlier, or because the storage device is a freshly formatted one), first remove all existing partitions from the device. Type print to view the current partitions, and rm <N> where <N> is the number of the partition to remove.
(parted)rm 2Do 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 fdisk which stages them, allowing a user to "undo" his changes before saving or exiting fdisk).
Creating the partitions
Now parted 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):
(parted)unit kibThen 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 parted to start from 32 KiB and end at 4128 KiB (creating a partition of 4096 KiB in size).
(parted)mkpart firmware 32 4128
(parted)printModel: Virtio Block Device (virtblk) Disk /dev/mmcblk0: 20480MiB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 32KiB 4128KiB 4096KiB firmware
TODO: instructions how to deal with alignment warning
Do the same for the bootloader partition (starting at 8192KiB, size 4096KiB).
(parted)mkpart bootloader 8192 12288After these two rather small partitions are created, it is time to create the bigger ones. To make things easier, change the size unit for parted to work with to mebibytes (abbreviated as MiB).
(parted)unit mibNow create a 128 MiB partition that will serve as the boot partition. Tell parted with the mkpart command to start from 16 MiB and end at 144 MiB (creating a partition of 128 MiB in size). Then turn on the boot flag for the newly created third partition.
TODO: disk model? TODO: 16MiB or 16.0MiB?
(parted)mkpart boot 16 144
(parted)set 3 boot onLast, 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).
(parted)mkpart main 136 -1The end result looks like so:
TODO: 12/16MiB or 12.0/16.0?
(parted)printModel: Virtio Block Device (virtblk) Disk /dev/sda: 20480MiB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 0.03MiB 4.03MiB 4.00MiB firmware 2 8.00MiB 12MiB 4.00MiB bootloader 3 16MiB 144MiB 128MiB boot boot 4 144MiB 20479MiB 20335MiB main
On an UEFI installation, the boot and esp flags will show up on the boot partition.
Use the quit command to exit parted.
With the partitions created, it is now time to put filesystems on them.