Booting to linux partition

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:

Источник

Ubuntu Documentation

This tutorial covers how to move the boot partition for an Ubuntu 10.04 install after installing the system without a separate boot partition.

» height=»16″ src=»/moin_static198/light/img/icon_cool.png» title=»Info » width=»16″/> Commands executed improperly can lead to an unbootable condition. If this happens, the user can use the Ubuntu installation CD to repair the installation to a working condition.

» height=»16″ src=»/moin_static198/light/img/icon_cool.png» title=»Info » width=»16″/> All device names (like /dev/sda1 and hd0,1) used in the tutorial must be adjusted to match the partitions on the user’s specific system. Do not copy commands in this tutorial without adjusting the drive/partition designations when appropriate!

Why may you want to do this?

Grub 2 error: no such partition.

BIOS limitations prevent the system from seeing the /boot partition files before an Operating System is loaded.

The user is using an OS filesystem format not compatible with the boot loader and must create a compatible ext2/3/4 partition for booting purposes.

What other options are there?

• If an older BIOS doesn’t recognise the full hard drive size, enable the ‘large file’ option (such as enabling LBA) in the BIOS settings; obtain a BIOS update from the manufacturer; or move the entire Ubuntu installation to the first part of the hard drive.

Needed for this tutorial are

An Ubuntu live CD

Basic knowledge of partitioning using GParted

Some understanding of how to use the terminal and command line

Preparations

Booting the Ubuntu Live CD

Boot from the Ubuntu Live CD as you would normally, select your language and choose the ‘Try Ubuntu’ option

Creating a partition for /boot

Once your system has booted from the live CD open GParted via the ‘System -> Administration -> Gparted Partition Editor’ menu.

Unmount the swap partition: Highlight it, then Partition -> Swapoff

Create a partition of at least 200 MB of free space. This partition can be created from existing unallocated space, or by shrinking another partition and using the newly-created free space.

• On older systems or very large drives, ensure the boot partition is within the area recognised by the BIOS. Check the BIOS settings for the reported disk size. It may be necessary to place the new boot partition before the Linux/Ubuntu partition in order for the BIOS to see it.

For guidance on creating partitions read this: HowtoPartition

For this guide, actions will be taken on a main Ubuntu installation partition and a new boot partition. These partitions will be designated as:

• /dev/sda2 — 200 MB (minimum) new boot partition
• /dev/sda1 — 10 GB linux installation partition

» height=»16″ src=»/moin_static198/light/img/icon_cool.png» title=»Info » width=»16″/> Remember to change the designations to match those on your system. The current partitioning setup can be viewed with the sudo fdisk -l (lowercase L) command.

If the boot flag is currently on your Ubuntu partition, move it to the new boot partition. This can be done with Gparted or the Disk Utility application.

Q: Is this really necessary? GRUB and LILO are supposed to ignore the bootable flag

A: In rare cases, the motherboard BIOS requires a partition with a bootable flag in order to boot from the hard drive. In these cases, GRUB or LILO are not given control even if installed in the MBR.

The partition order can be changed so that /dev/sda1 comes before /dev/sda2 when using the fdisk command using the advanced options.

» height=»16″ src=»/moin_static198/light/img/icon_cool.png» title=»Info » width=»16″/> Changing these designations may affect system files which still identify partitions by device name rather than UUID.

Moving files from existing /boot to new location

Open a terminal via Applications -> Accessories -> Terminal To run commands as ‘root’ for the commands in this guide without using ‘sudo’: sudo su

Mount drives

Make the mount points. In this guide, we will mount the main Ubuntu partition on /mnt/main, and the new boot partition on /mnt/boot

Mount the two partitions:

Copy /boot files

Remount the boot partition

Unmount the boot partition from /mnt and remount to /boot:

Editing the files from your Ubuntu install

Add /boot to your /etc/fstab

If you want to find out the UUID and confirm the format of the /boot partition type:

The output should look similar to:

Open /etc/fstab for editing:

» height=»16″ src=»/moin_static198/light/img/icon_cool.png» title=»Info » width=»16″/> Note the format in fstab should match the format reported by the blkid command (ext2, ext3, ext4, etc). Add this line.

or to use the preferred UUID designation:

Setting up GRUB 2

Using the same mounting procedures as previously executed, from the LiveCD:

Continue at the Reboot section.

Setting up GRUB Legacy

Edit /boot/grub/menu.lst

in the console write

gedit opens with the menu.lst file,

and change the line

Next, update the boot entries at the end of the file. Since you now have a /boot partition, all kernel and initrd paths are relative to /boot/ instead, eg.

Update root to match that of groot above and remove /boot from the kernel and initrd paths in all the entries.

Reinstall grub

remember in the setup command do not use hd0,1 as you need to install grub in the master boot record not in this specific partition boot record.

Reboot

Reboot your system by typing: reboot You will be asked to remove the CD and press «ENTER» before the system will reboot.

Final Cleanup

You are now booted using your new /boot partition but in the old /boot folder and files still exist on the / (root) filesystem.

To clean this up, open up a terminal and type the following commands to unmount the /boot partition, make a backup copy and then delete the old /boot folder*, recreate the /boot folder, and remount the new boot partition:

» height=»16″ src=»/moin_static198/light/img/icon_cool.png» title=»Info » width=»16″/> The ‘rm -rf’ command, if executed improperly, can delete your entire installation. Ensure you have unmounted the new /boot partition with the ‘umount’ command and confirm you have typed or copied the «rm» command exactly before executing it! A backup copy of the old boot folder will be placed in /root/Desktop

Maintenance

If using Grub legacy (not Grub 2), when you install a new linux kernel you may need to reinstall grub after mounting your boot partition over /boot in the live-CD root as shown above.

CreateBootPartitionAfterInstall (последним исправлял пользователь yannubuntu 2012-09-03 14:19:01)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник