Partitioning in arch linux

EFI system partition

The EFI system partition (also called ESP) is an OS independent partition that acts as the storage place for the EFI bootloaders, applications and drivers to be launched by the UEFI firmware. It is mandatory for UEFI boot.

This article or section is a candidate for moving to Unified Extensible Firmware Interface#UEFI drivers.

The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.8, section 13.3.1.1), but any conformant vendor can optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system.

Contents

Check for an existing partition

If you are installing Arch Linux on an UEFI-capable computer with an installed operating system, like Windows 10 for example, it is very likely that you already have an EFI system partition.

To find out the disk partition scheme and the system partition, use fdisk as root on the disk you want to boot from:

The command returns:

• The disk’s partition table: it indicates Disklabel type: gpt if the partition table is GPT or Disklabel type: dos if it is MBR.
• The list of partitions on the disk: Look for the EFI system partition in the list, it is usually at least 100 MiB in size and has the type EFI System or EFI (FAT-12/16/32) . To confirm this is the ESP, mount it and check whether it contains a directory named EFI , if it does this is definitely the ESP.

If you found an existing EFI system partition, simply proceed to #Mount the partition. If you did not find one, you will need to create it, proceed to #Create the partition.

Create the partition

The following two sections show how to create an EFI system partition (ESP).

To provide adequate space for storing boot loaders and other files required for booting, and to prevent interoperability issues with other operating systems[1][2] the partition should be at least 260 MiB. For early and/or buggy UEFI implementations the size of at least 512 MiB might be needed.[3]

GPT partitioned disks

EFI system partition on a GUID Partition Table is identified by the partition type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B .

Choose one of the following methods to create an ESP for a GPT partitioned disk:

• fdisk: Create a partition with partition type EFI System .
• gdisk: Create a partition with partition type EF00 .
• GNU Parted: Create a partition with fat32 as the file system type and set the esp flag on it.

Proceed to #Format the partition section below.

MBR partitioned disks

EFI system partition on a Master Boot Record partition table is identified by the partition type ID EF .

Choose one of the following methods to create an ESP for a MBR partitioned disk:

• fdisk: Create a primary partition with partition type EFI (FAT-12/16/32) .
• GNU Parted: Create a primary partition with fat32 as the file system type and set the esp flag on it.

Proceed to #Format the partition section below.

Format the partition

The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems[4]. To prevent potential issues with other operating systems and also since the UEFI specification only mandates supporting FAT16 and FAT12 on removable media[5], it is recommended to use FAT32.

After creating the partition, format it as FAT32. To use the mkfs.fat utility, install dosfstools .

If you get the message WARNING: Not enough clusters for a 32 bit FAT! , reduce cluster size with mkfs.fat -s2 -F32 . or -s1 ; otherwise the partition may be unreadable by UEFI. See mkfs.fat(8) for supported cluster sizes.

Mount the partition

The kernels, initramfs files, and, in most cases, the processor’s microcode, need to be accessible by the boot loader or UEFI itself to successfully boot the system. Thus if you want to keep the setup simple, your boot loader choice limits the available mount points for EFI system partition.

Typical mount points

The simplest scenarios for mounting EFI system partition are:

• mount ESP to /efi and use a boot loader which is capable of accessing the kernel(s) and initramfs image(s) that are stored elsewhere (typically /boot). See Arch boot process#Boot loader for more information on boot loader requirements and capabilities.
• mount ESP to /boot . This is the preferred method when directly booting an EFISTUB kernel from UEFI or booting it via a boot manager like systemd-boot.
• mount ESP to /efi and additionally mount an «Extended Boot Loader Partition» (XBOOTLDR) to /boot . This can be useful when a previously created ESP is too small to hold multiple boot loaders and/or kernels but the ESP cannot be easily resized (such as when installing Linux after Windows to dual boot). This method is supported by at least systemd-boot.

Alternative mount points

If you do not use one of the simple methods from #Typical mount points, you will need to copy your boot files to ESP (referred to hereafter as esp ).

Furthermore, you will need to keep the files on the ESP up-to-date with later kernel updates. Failure to do so could result in an unbootable system. The following sections discuss several mechanisms for automating it.

Using bind mount

Instead of mounting the ESP itself to /boot , you can mount a directory of the ESP to /boot using a bind mount (see mount(8) ). This allows pacman to update the kernel directly while keeping the ESP organized to your liking.

Just like in #Alternative mount points, copy all boot files to a directory on your ESP, but mount the ESP outside /boot . Then bind mount the directory:

After verifying success, edit your Fstab to make the changes persistent:

Using systemd

Systemd features event triggered tasks. In this particular case, the ability to detect a change in path is used to sync the EFISTUB kernel and initramfs files when they are updated in /boot/ . The file watched for changes is initramfs-linux-fallback.img since this is the last file built by mkinitcpio, to make sure all files have been built before starting the copy. The systemd path and service files to be created are:

Then enable and start efistub-update.path .

Using filesystem events

Filesystem events can be used to run a script syncing the EFISTUB Kernel after kernel updates. An example with incron follows.

In order to use this method, enable the incrond.service .

Using mkinitcpio hook

Mkinitcpio can generate a hook that does not need a system level daemon to function. It spawns a background process which waits for the generation of vmlinuz , initramfs-linux.img , and initramfs-linux-fallback.img before copying the files.

Add efistub-update to the list of hooks in /etc/mkinitcpio.conf .

Using mkinitcpio preset

As the presets in /etc/mkinitcpio.d/ support shell scripting, the kernel and initramfs can be copied by just editing the presets.

Replacing the above mkinitcpio hook

Edit the file /etc/mkinitcpio.d/linux.preset :

To test that, just run:

Another example

Using pacman hook

A last option relies on the pacman hooks that are run at the end of the transaction.

The first file is a hook that monitors the relevant files, and it is run if they were modified in the former transaction.

The second file is the script itself. Create the file and make it executable:

Troubleshooting

ESP on software RAID1

It is possible to make the ESP part of a RAID1 array, but doing so brings the risk of data corruption, and further considerations need to be taken when creating the ESP. See [8] and [9] for details and UEFI booting and RAID1 for an in-depth guide with a solution.

The key part is to use —metadata 1.0 in order to keep the RAID metadata at the end of the partition, otherwise the firmware will not be able to access it:

Источник

Talk:Partitioning

Contents

Partition Alignment Verification

On my system ‘blockdev —getalignoff /dev/sda5’ returns zero, even though the partition seems not to be aligned optimally:

The command ‘parted /dev/sda align-check optimal’ gives the right message in my opinion: ‘not aligned’. Should we replace blockdev command?

Plk (talk) 18:31, 31 May 2014 (UTC)

It seems you’re right. After reading the warning about cfdisk alignment («Warning: The first partition created by cfdisk starts at sector 63, instead of the usual 2048. This can lead to reduced performance on SSD and advanced format (4k sector) drives. It will cause problems with GRUB2, but GRUB legacy and Syslinux should work fine.»), I created the first partition of the SSD I was working on with cfdisk — thus creating a bad alignment (I checked with fdisk -l /dev/sda, the first partition effectively starts at sector 63 and not 2048). The blockdev —getalignoff /dev/sda1 command returned zero (it shouldn’t have) while your command parted /dev/sda align-check optimal returned ‘not aligned’, as expected. It seems to be a bug of blockdev in ArchLinux, as of util-linux v.2.24. I upgraded to util-linux v.2.25-3, and the problem is still present in blockdev. However, cfdisk has been entirely rewritten for util-linux 2.25 as described in this blog post and now correctly starts the first partition at sector 2048 when creating it.

So should we edit the wiki page for recommanding upgrade to util-linux 2.25 in order to use cfdisk with correct partition alignment ? As util-linux integrates multiple essential softwares, I don’t know if upgrading it will or not break something with the other utilities it includes. In any case, I think we should disrecommend using blockdev to check partition alignment, and recommend using parted instead for the time being. Can anyone else confirm this bug, especially on other distributions ? We need to know if the problem is inherent to Arch’s implementation of blockdev or to blockdev itself. —Irrodeus (talk) 01:56, 6 September 2014 (UTC)

Restructuring

Example tables

[1] moved tables from the Beginners’ guide to Partitioning#Partition_scheme, however it didn’t fit in too well so I’ve removed it for now.

However, I think the basic idea is a sound one, but perhaps more expansive. We could include suggested File systems, as well as more complex examples such as /var and GRUB Boot partitions.

See the updated tables from the BG below for reference. — Alad (talk) 00:20, 10 July 2016 (UTC)

Table draft

UEFI/GPT example layout
Mount point	Partition	Partition type (GUID)	Bootable flag	Suggested size
/boot	/dev/sdx1	EFI System Partition	Yes	260–512 MiB
[SWAP]	/dev/sdx2	Linux swap	No	More than 512 MiB
/	/dev/sdx3	Linux	No	Remainder of the device
MBR/BIOS example layout
Mount point	Partition	Partition type	Bootable flag	Suggested size
[SWAP]	/dev/sdx1	Linux swap	No	More than 512 MiB
/	/dev/sdx2	Linux	Yes	Remainder of the device

I added these tables to the page. I also added one using a separate /home since I imagine that is the most common scenario. I think 3 examples could be enough, but I am open to more. — Rdeckard (talk) 18:53, 11 October 2016 (UTC) Nice work. One thing I was considering is to have multiple small tables under the various partition sections (like /home), instead of a single large one. Thoughts? — Alad (talk) 18:56, 13 October 2016 (UTC) edit: I noticed you already split the tables; that leaves whether it makes sense to have them under sections like Partitioning#.2Fhome rather than Partitioning#Example layouts. — Alad (talk) 19:01, 13 October 2016 (UTC) All examples include the / partition and swap. Avoiding duplication and forward references is probably one of the reasons why people invented appendix. — Lahwaacz (talk) 19:15, 13 October 2016 (UTC)

Table draft 2

BIOS/MBR

Mount point on the installed system	Partition	Partition type ID	Boot flag	Suggested size
[SWAP]	/dev/sda1	82 : Linux swap	No	More than 512 MiB or the size of RAM to use hibernation
/	/dev/sda2	83 : Linux	Yes	Remainder of the device
N/A	None	Unallocated space	N/A	At least 16.5 KiB

BIOS/GPT with GRUB

Mount point on the installed system	Partition	Partition type GUID	Partition attributes	Suggested size
None	/dev/sda1	21686148-6449-6E6F-744E-656564454649 : BIOS boot partition	1 MiB
[SWAP]	/dev/sda2	0657FD6D-A4AB-43C4-84E5-0933C84B4F4F : Linux swap	More than 512 MiB or the size of RAM to use hibernation
/	/dev/sda3	4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 : Linux x86-64 root (/)	Remainder of the device

BIOS/GPT with Syslinux

Mount point on the installed system	Partition	Partition type GUID	Partition attributes	Suggested size
[SWAP]	/dev/sda1	0657FD6D-A4AB-43C4-84E5-0933C84B4F4F : Linux swap	More than 512 MiB or the size of RAM to use hibernation
/	/dev/sda2	4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 : Linux x86-64 root (/)	2 : Legacy BIOS bootable	Remainder of the device

UEFI/GPT with a boot loader which has a driver for your root file system (eg. GRUB, rEFInd)

Mount point on the installed system	Partition	Partition type GUID	Partition attributes	Suggested size
/efi	/dev/sda1	C12A7328-F81F-11D2-BA4B-00A0C93EC93B : EFI system partition	260 MiB
[SWAP]	/dev/sda2	0657FD6D-A4AB-43C4-84E5-0933C84B4F4F : Linux swap	More than 512 MiB or the size of RAM to use hibernation
/	/dev/sda3	4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 : Linux x86-64 root (/)	Remainder of the device

UEFI/GPT with a boot loader without file system drivers or without a boot loader at all

Mount point on the installed system	Partition	Partition type GUID	Partition attributes	Suggested size
/boot	/dev/sda1	C12A7328-F81F-11D2-BA4B-00A0C93EC93B : EFI system partition	260 MiB
[SWAP]	/dev/sda2	0657FD6D-A4AB-43C4-84E5-0933C84B4F4F : Linux swap	More than 512 MiB or the size of RAM to use hibernation
/	/dev/sda3	4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 : Linux x86-64 root (/)	Remainder of the device

BIOS&UEFI/GPT with GRUB

Mount point on the installed system	Partition	Partition type GUID	Partition attributes	Suggested size
None	/dev/sda1	21686148-6449-6E6F-744E-656564454649 : BIOS boot partition	1 MiB
/efi	/dev/sda2	C12A7328-F81F-11D2-BA4B-00A0C93EC93B : EFI system partition	260 MiB
[SWAP]	/dev/sda3	0657FD6D-A4AB-43C4-84E5-0933C84B4F4F : Linux swap	More than 512 MiB or the size of RAM to use hibernation
/	/dev/sda4	4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 : Linux x86-64 root (/)	Remainder of the device

BIOS&UEFI/GPT with Syslinux

Mount point on the installed system	Partition	Partition type GUID	Partition attributes	Suggested size
/boot	/dev/sda1	C12A7328-F81F-11D2-BA4B-00A0C93EC93B : EFI system partition	2 : Legacy BIOS bootable	260 MiB
[SWAP]	/dev/sda2	0657FD6D-A4AB-43C4-84E5-0933C84B4F4F : Linux swap	More than 512 MiB or the size of RAM to use hibernation
/	/dev/sda3	4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 : Linux x86-64 root (/)	Remainder of the device

I didn’t like the current Partitioning#Example layouts so I tried to make better ones, but I think I made too many of them. I’m not entirely certain if «GPT + BIOS & UEFI with Syslinux» is a good idea due to all of Syslinux’s limitations, but GRUB doesn’t use the «Legacy BIOS bootable» attribute and without the Syslinux example the whole column would become useless. Thoughts? — nl6720 (talk) 10:19, 1 January 2018 (UTC)

If syslinux needs special mention in a manner that is exclusive to it, then I’d argue that the column is useless anyway except to draw attention to syslinux. It seems like a Note would be better for that, assuming we want to recommend syslinux at all. — Eschwartz (talk) 05:30, 9 December 2018 (UTC) It’s not really Syslinux specific, theoretically the «Legacy BIOS bootable» attribute should be needed by any boot loader that puts stuff in the VBR (I wonder if that’s also true for GRUB in VBR). — nl6720 (talk) 09:06, 9 December 2018 (UTC) I think that’s out of scope, if the user uses some bootloader which turns out to require a bootable flag, it’s simple to go back into the ISO and set the flag accordingly. This is different from say, a BIOS Boot Partition (for GRUB) which would require actual changes in partitioning if not considered beforehand. As such I suggest to go with the following: BIOS (MBR and GPT)

• BIOS Boot Partition
• /
• swap (as Btrfs does not support swap files, and the examples should be as generic as possible)

UEFI

• EFI System Partition
• /
• swap

— Alad (talk) 20:35, 20 December 2018 (UTC) The same reasoning applies to the «Boot flag» column in the BIOS/MBR example, so if we remove «Partition attributes» then we should also remove «Boot flag». — nl6720 (talk) 06:51, 21 December 2018 (UTC)

mmcblk0p<1,2,3,4>, mmcblk0boot<0,1>, mmcblk0rpmb

And my install usb showed up as sda instead.. Don’t know how to best deal with that. «Boot» ones don’t seem to provide disklabel type and identifier information, and are only 4MiB. My guess is to ignore them. /dev/mmcblk0p3 seems to be the one with windows on it.(ASUS Vivobook E200HA)Jasper1984 (talk) 00:58, 25 December 2016 (UTC)

Ended up just ignoring the mmcblk0boot <0,1>entries, treating mmcblk0p <1,2,3,4>as if were just sda, basically, it worked. (dont see the rpmb volumes now) More specifically, didnt reformat the first partition, instead just putting different files there. Tried the bind-mount approach in EFI System Partition, but ended up the more regular approach. (not sure why it didnt co-operate) Would suspect that mmcblk0boot <0,1>dont matter much, but would suggest just reusing the first partition nevertheless..(really, little reason to reformat that?)Jasper1984 (talk) 00:34, 14 January 2017 (UTC)

Leaving unpartitioned space on a disk

From the following observations:

• in the future, you might want to use different partitions (test new OS, different FS, different boot partitions, creating a custom image, prototyping, . )
• on big drives, most space usually remain unused (expect when storing games, a lot of videos/, other exotic usage)
• it is easier to expand a filesystem than to shrink it (some filesystem can’t be shrinked)

My conclusion is that with big drives, the advice to leave unused space is correct for people with little to no experience with partitioning, Apollo22 (talk) 16:32, 15 June 2019 (UTC)

This is so specific to user behaviour that you can’t make a general recommendation like this. Most of the time, people have a reason to buy a large disk instead of a small disk, so telling them not to use the full capacity is rather silly. Also, a common paraphrase of the Moore’s law says that no matter how large your hard drive is, in 2 years you will fill most of its capacity. — Lahwaacz (talk) 18:11, 15 June 2019 (UTC) I disagree that that most people have a reason to buy a large disk because of the current price of disks. Also most people reading this part of the article have little experience, leaving some space free would give they the opportunity to move their data around to correct past mistakes without needing an external disk. Overall I think it’s an important idea to include in the page, maybe more something to know about. For example: You might consider not partitioning your whole disk ? And give the reasons why ? — Apollo22 (talk) 20:52, 15 June 2019 (UTC)

Wikipedia definition

I noticed that Device_file and File_systems both use Wikipedia to define their articles, but Partitioning did not. I took a look at the Wikipedia article for it, and it does seem suitable enough for this article, so I went ahead and wrote that in. I’m not sure what the consensus is on using Wikipedia as an «upstream» reference, but in this case, it fits well, I think.

My only concern is that the summary now neglects to differentiate block devices from hard disks, which a reader will only discover later in the article.

Wheatgold (talk) 15:54, 8 September 2020 (UTC)

Remove tool-MBR/GPT compatibility warning?

In the table above the warning, MBR tools is already a _subset_ of GPT tools. Is it ok to remove the warning? —This unsigned comment is by PXf (talk) 15:21, 3 August 2021‎ (UTC). Please sign your posts with

The only use I see for that warning is that if you open a device with a MBR partition table in gdisk, it will try to convert it to GPT. — nl6720 (talk) 13:04, 4 August 2021 (UTC)

Источник