Boot filesystem in 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:

Источник

Arch Linux

You are not logged in.

#1 2013-09-14 17:20:43

[SOLVED] Boot partition filesystem?

I’m trying to install arch on a new PC. I followed the instructions on https://wiki.archlinux.org/index.php/Installation_Guide, but when I reboot, I get

I’ve read the other threads from people with this problem, but the solutions don’t work for me.

The system is a BIOS system. I’ve therefore followed the instructions here (https://wiki.archlinux.org/index.php/Pa … ng#.2Fboot) for partitioning, which gave me this lay-out:

Now the instructions get somewhat confusing. It says I should format my partitions, but when I format the boot partition it says its to small for a journal. Do I need a different filesystem from ext4? If I don’t format the partition, I can’t mount it, and if I don’t mount it, I get the feeling grub installs in the /boot directory on /dev/sda2.

Thanks for any help!

Last edited by diederick76 (2013-09-14 19:03:02)

#2 2013-09-14 17:30:56

Re: [SOLVED] Boot partition filesystem?

See https://wiki.archlinux.org/index.php/Pa … ions_be.3F for size guidelines. Boot partition *should* be formatted as ext2.

#3 2013-09-14 17:42:29

Re: [SOLVED] Boot partition filesystem?

See https://wiki.archlinux.org/index.php/Pa … ions_be.3F for size guidelines. Boot partition *should* be formatted as ext2.

Really? There are lots of other options.

@OP,
You only need a BIOS boot partition with a GPT partition table and you intend to use grub. I’m not clear if that is what you are using or not.

The BIOS boot partition doesn’t get mounted and doesn’t need formatting or a file system. It is just somewhere grub uses when it installs to disk and it finds it automatically.

If you want a regular boot partition, you need to create a separate partition for that with a regular file system type and of a reasonable size. ext4 is a perfectly good choice for /boot (I use it for my /boot) but you will need something bigger than 1MB!

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Corporation Wireless 8265 / 8275 | US keyboard with Euro | 512G NVMe INTEL SSDPEKKF512G7L

#4 2013-09-14 18:43:55

Re: [SOLVED] Boot partition filesystem?

It is a BIOS system and I want to use GPT, so that is why I use a boot partition. It says at https://wiki.archlinux.org/index.php/GR … structions that

so I assume 1007 KiB is sufficient.

@cfr Thanks for clearing up that the boot partition doesn’t need to be mounted. But can you tell me how to tell grub-install where the kernel is?

#5 2013-09-14 19:02:21

Re: [SOLVED] Boot partition filesystem?

I cannot believe I didn’t read

Everything works now. Thank you all for your time. I will now go and put on a cone of shame.

Last edited by diederick76 (2013-09-15 08:01:47)

#6 2013-09-14 20:05:04

Re: [SOLVED] Boot partition filesystem?

I cannot believe I didn’t read

Everything works now. Thank you all for your time. I will no go and put on a cone of shame.

Really, no need for that . There are so many details it is easy to miss something — and of course it seems obvious once you figure out what it is. Hindsight is always 20-20! (Why a cone in particular, anyway?)

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Corporation Wireless 8265 / 8275 | US keyboard with Euro | 512G NVMe INTEL SSDPEKKF512G7L

#7 2013-09-15 08:02:31

Re: [SOLVED] Boot partition filesystem?

I cannot believe I didn’t read

Everything works now. Thank you all for your time. I will no go and put on a cone of shame.

Really, no need for that . There are so many details it is easy to miss something — and of course it seems obvious once you figure out what it is. Hindsight is always 20-20! (Why a cone in particular, anyway?)

#8 2013-09-15 14:41:57

Re: [SOLVED] Boot partition filesystem?

FWIW, the term «boot partition» is a bit ambiguous, and its use led to some confusion early in this thread. Depending on the context, the term could mean:

The BIOS boot partition — This partition is present in diederick76’s original setup, and it seems to be what he means by «boot partition.» It does not normally hold a filesystem; it’s used without a filesystem by GRUB to hold boot code.

The /boot partition — This partition is mounted at /boot in the Linux directory tree. It holds kernel files, initial RAM disk files, and often GRUB or other boot loader files. Many people recommend using ext2fs on it, but it can use just about any Linux filesystem (or even some non-Linux filesystems, like FAT or HFS+). It’s also optional, and diederick76’s setup doesn’t include such a partition. BUR, however, seems to have misinterpreted diederick76’s reference to mean this partition. For clarity, I recommend always using the leading slash («/boot partition») when referring to this partition. The use of a slash before a directory name and the use of the word «partition» makes it clear that you’re talking about a partition mounted at that location. (For the same reason, there’s no such thing as a «/swap partition,» since swap space is not mounted.)

The EFI System Partition (ESP) — This partition is used on EFI-based systems to hold boot loaders. It uses a FAT filesystem and is shared across OSes. Some OSes call it the «EFI boot partition,» but the EFI specification doesn’t use this term. In Linux, it’s most commonly mounted at /boot/efi, but Arch users sometimes mount it at /boot. Diederick76 doesn’t report having such a partition, and if the system is booting in BIOS mode, it doesn’t need one.

The partition that holds the kernel — The phrase «boot partition» can sometimes mean whatever partition holds the kernel. This can be a separate /boot partition; but if such a partition is absent, the kernel will reside in the /boot directory on the root (/) partition.

The root (/) partition — Sometimes somebody means the root (/) partition when they refer to the «boot partition,» but this is imprecise unless the root partition actually holds the kernel, which is not always the case.

The distinctions among these partitions, and the fact that one partition can sometimes fill multiple roles, can be confusing for new users. The last couple uses are particularly ambiguous. I hope I’ve helped clarify things a bit.

Источник