Difference between revisions of "UEFI Bootloaders"

From ArchWiki
Jump to: navigation, search
(EFILINUX)
(Linux Kernel EFISTUB: cleanup)
(30 intermediate revisions by 14 users not shown)
Line 6: Line 6:
 
{{Warning|1=A bug has been noticed where booting EFISTUB can fail depending on kernel version and motherboard model. See [https://bbs.archlinux.org/viewtopic.php?id=156670&p=1] for more information.}}
 
{{Warning|1=A bug has been noticed where booting EFISTUB can fail depending on kernel version and motherboard model. See [https://bbs.archlinux.org/viewtopic.php?id=156670&p=1] for more information.}}
  
Linux (Kernel >= 3.3) supports {{ic|EFISTUB (EFI BOOT STUB)}} booting. It is enabled by default on Arch Linux kernels or can be activated by setting {{ic|CONFIG_EFI_STUB=y}} in the Kernel configuration (see [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/efi-stub.txt;hb=HEAD The EFI Boot Stub] for more information).
+
The Linux Kernel ({{Pkg|linux}}>=3.3) supports {{ic|EFISTUB (EFI BOOT STUB)}} booting. It is enabled by default on Arch Linux kernels or can be activated by setting {{ic|CONFIG_EFI_STUB=y}} in the Kernel configuration (see [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/efi-stub.txt;hb=HEAD The EFI Boot Stub] for more information).
  
A single EFISTUB kernel is not capable of launching other kernels, hence each EFISTUB Kernel + Initramfs pair requires a separate boot menu entry. It is recommended to use a UEFI Boot Manager to manage multiple kernels.
+
A single EFISTUB kernel is not capable of launching other kernels, hence each EFISTUB Kernel + Initramfs pair requires a separate boot menu entry. Because of this, when working with multiple kernels, it is recommended to use a UEFI Boot Manager.
  
 
=== Setting up EFISTUB ===
 
=== Setting up EFISTUB ===
  
#[https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#EFI_System_Partition Create a FAT32 UEFI System Partition]
+
# Create a [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].
# Mount the UEFI System Partition at {{ic|/boot/efi}} with {{ic|# mount <UEFI Partition> /boot/efi}} if you're going to be using GRUB2, or at {{ic|/boot}} with {{ic|# mount <UEFI Partition> /boot}} if you're going to be using Gummiboot or rEFInd. Gummiboot cannot boot across partitions, and will never have such capability due to its nature, so it's paramount that you mount the UEFI System Partition at /boot for use with Gummiboot so that the kernel and initramfs lie on the same partition as the bootmanager. {{note| On some machines, when using rEFInd, it works fine when mounting the UEFI partition in {{ic|/boot/efi}}}}
+
# Mount the EFI System Partition either at {{ic|/boot}} (recommended if you are planning to use Gummiboot or no boot manager) or some other location of your choice (most other distro's and tools use {{ic|/boot/efi}}). The mountpoint will be mentioned as {{ic|$esp}} hereafter.
# Create {{ic|/boot/efi/EFI/arch/}} directory with {{ic|# mkdir /boot/efi/EFI/arch/}}
+
 
 +
==== Moving everything to the right place ====
 +
{{Warning|The below steps are required only if you DID NOT use {{ic|/boot}} as the EFISYS mountpoint. If you did choose {{ic|/boot}} as mountpoint, you can continue to [[#Booting EFISTUB]].}}
 +
 
 +
# Create {{ic|$esp/EFI/arch/}}
 
# Copy the following files from source to destination
 
# Copy the following files from source to destination
 
{| border="1"
 
{| border="1"
 
!Boot File Source!!UEFI Destination
 
!Boot File Source!!UEFI Destination
 
|-
 
|-
| /boot/vmlinuz-linux  || /boot/efi/EFI/arch/vmlinuz-arch.efi
+
| /boot/vmlinuz-linux  || $esp/EFI/arch/vmlinuz-arch.efi
 
|-
 
|-
| /boot/initramfs-linux.img || /boot/efi/EFI/arch/initramfs-arch.img
+
| /boot/initramfs-linux.img || $esp/EFI/arch/initramfs-arch.img
 
|-
 
|-
| /boot/initramfs-linux-fallback.img  || /boot/efi/EFI/arch/initramfs-arch-fallback.img
+
| /boot/initramfs-linux-fallback.img  || $esp/EFI/arch/initramfs-arch-fallback.img
 
|}
 
|}
{{note| As of {{Pkg|refind-efi}} 0.2.7, you don't need to copy these files, since refind will automatically detect them}}
 
  
=== Sync EFISTUB Kernel ===
+
{{Warning|The EFISTUB Kernel must be updated each time the kernel is updated (follow step 4 in [[#Setting up EFISTUB]]. Failure to do so will result in failure to boot. Alternatively one can automatically update the EFISTUB kernel using one of the following methods:}}
{{Warning|The EFISTUB Kernel must be updated each time the kernel is updated (follow step 4 in [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Setting_up_EFISTUB Setting up EFISTUB]. Failure to do so will result in failure to boot. Alternatively one can automatically update the EFISTUB kernel using one of the following methods:}}
+
  
{{Note| As of [https://www.archlinux.org/packages/extra/any/refind-efi/ refind-efi 0.2.7], refind automatically detects kernels in {{ic|/boot}}. They do not have to be renamed to have a {{ic|.efi}} extension either. Hence, the following sync scripts aren't needed if using [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd refind]. You do need to isntall an EFI driver to read the Linux filesystem on which the kernel is stored, though.}}
+
===== Systemd =====
  
==== 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 {{ic|boot}}.
 
[[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 {{ic|boot}}.
 
  
 
{{Warning|Since mkinitcpio takes time to build the kernel stub and the initramfs. It is possible for the following systemd services to copy older kernel stubs and initramfs instead of the new ones. To reduce the chance of this error, it is better to bind the efistub copying service to check if the initramfs-linux-fallback.img was changed (since it is the last thing built by mkinitcpio).}}
 
{{Warning|Since mkinitcpio takes time to build the kernel stub and the initramfs. It is possible for the following systemd services to copy older kernel stubs and initramfs instead of the new ones. To reduce the chance of this error, it is better to bind the efistub copying service to check if the initramfs-linux-fallback.img was changed (since it is the last thing built by mkinitcpio).}}
{{Tip|Save the following script as {{ic|/usr/lib/systemd/system/efistub-update.path}}}}
+
{{Tip|Save the following script as {{ic|/etc/systemd/system/efistub-update.path}}}}
 
{{bc|<nowiki>
 
{{bc|<nowiki>
 
[Unit]
 
[Unit]
Line 49: Line 49:
 
</nowiki>}}
 
</nowiki>}}
  
{{Tip|Save the following script as {{ic|/usr/lib/systemd/system/efistub-update.service}}}}
+
{{Tip|Save the following script as {{ic|/etc/systemd/system/efistub-update.service}}}}
 
{{bc|<nowiki>
 
{{bc|<nowiki>
 
[Unit]
 
[Unit]
Line 56: Line 56:
 
[Service]
 
[Service]
 
Type=oneshot
 
Type=oneshot
ExecStart=/usr/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi
+
ExecStart=/usr/bin/cp -f /boot/vmlinuz-linux $esp/EFI/arch/vmlinuz-arch.efi
ExecStart=/usr/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img
+
ExecStart=/usr/bin/cp -f /boot/initramfs-linux.img $esp/EFI/arch/initramfs-arch.img
ExecStart=/usr/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img
+
ExecStart=/usr/bin/cp -f /boot/initramfs-linux-fallback.img $esp/EFI/arch/initramfs-arch-fallback.img
 
</nowiki>}}
 
</nowiki>}}
  
Line 66: Line 66:
 
</nowiki>}}}}
 
</nowiki>}}}}
  
==== Incron ====
+
===== Incron =====
 +
 
 
{{Pkg|incron}} can run a script to sync the EFISTUB Kernel after updates
 
{{Pkg|incron}} can run a script to sync the EFISTUB Kernel after updates
  
Line 72: Line 73:
 
{{bc|<nowiki>
 
{{bc|<nowiki>
 
#!/usr/bin/env bash
 
#!/usr/bin/env bash
/usr/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi
+
/usr/bin/cp -f /boot/vmlinuz-linux $esp/EFI/arch/vmlinuz-arch.efi
/usr/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img
+
/usr/bin/cp -f /boot/initramfs-linux.img $esp/EFI/arch/initramfs-arch.img
/usr/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img
+
/usr/bin/cp -f /boot/initramfs-linux-fallback.img $esp/EFI/arch/initramfs-arch-fallback.img
 
</nowiki>}}
 
</nowiki>}}
  
Line 88: Line 89:
 
</nowiki>}}}}
 
</nowiki>}}}}
  
==== Mkinitcpio hook ====
+
===== 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 {{ic|vm-linuz}}, {{ic|initramfs-linux.img}}, and {{ic|initramfs-linux-fallback.img}}; then follows step 4 in [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Setting_up_EFISTUB Setting up EFISTUB]
 
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 {{ic|vm-linuz}}, {{ic|initramfs-linux.img}}, and {{ic|initramfs-linux-fallback.img}}; then follows step 4 in [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Setting_up_EFISTUB Setting up EFISTUB]
  
Line 114: Line 116:
 
done
 
done
  
/usr/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi
+
/usr/bin/cp -f /boot/vmlinuz-linux $esp/EFI/arch/vmlinuz-arch.efi
/usr/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img
+
/usr/bin/cp -f /boot/initramfs-linux.img $esp/EFI/arch/initramfs-arch.img
/usr/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img
+
/usr/bin/cp -f /boot/initramfs-linux-fallback.img $esp/EFI/arch/initramfs-arch-fallback.img
  
 
echo "Synced kernel with ESP"
 
echo "Synced kernel with ESP"
Line 123: Line 125:
 
{{Tip|Add {{ic|efistub-update}} to the list of hooks in {{ic|/etc/mkinitcpio.conf}}}}
 
{{Tip|Add {{ic|efistub-update}} to the list of hooks in {{ic|/etc/mkinitcpio.conf}}}}
  
 +
===== /etc/fstab bind mount =====
 +
{{Note|
 +
* The following method should work similarly with any distribution that does not symlink in {{ic|/boot}}. ''See Warnings for caveats.''
 +
* This involves no special scripts, services, or bootloader filesystem drivers.
 +
* This centralizes and organizes kernels and initrds across installations on one partition.
 +
* This avoids possible limitations imposed by firmware and/or the bootloader on boot device configuration as can often occur with RAID and/or LVM (excepting the standard FAT32 EFI system partition, of course).
 +
* Beyond initial configuration this should persist without special consideration or maintenance.
 +
* This should be transparent to any action normally affecting {{ic|/boot}} and the files therein.}}
 +
{{Warning|
 +
* This requires both a kernel and a bootloader compatible with the FAT32 filesystem.
 +
* Because the FAT32 filesystem cannot handle symlinks, this will not behave as intended with an installation that requires them in {{ic|/boot}}.
 +
* Initial configuration requires {{ic|root}} level access.
 +
* This may require a large EFI system partition in order to accomodate multiple installations.
 +
* All kernels will require at least a {{ic|1=root=''system root''}} parameter passed at boot.
 +
* per rEFInd's author: ''OpenSUSE definitely uses symbolic links in {{ic|/boot}}... Fedora, Ubuntu, and ... OpenSUSE all refuse a FAT partition as {{ic|/boot}} in ... setup [which] can be worked around [in] {{ic|/etc/fstab}}.'' Forum post [[https://bbs.archlinux.org/viewtopic.php?pid=1331867#p1331867 here]].}}
 +
; Method: Whereas the general convention is to mount the EFI system partition to a {{ic|/boot/efi}} subfolder, the following will achieve the opposite.
 +
* Create a {{ic|ef00}} type EFI system partition of FAT32 format as described elsewhere.
 +
:{{Tip|
 +
:* It may be beneficial to make it several gigabytes in size to accomodate multiple installations.
 +
:* Use the GPT partition name feature for added convenience. For example name the partition {{ic|esp}}.}}
 +
* Create a mount-point and mount the EFI system partition somewhere on the filesystem. For example:
 +
: {{ic|$ mkdir /esp<br />$ mount -L esp /esp}}
 +
* Create a folder in {{ic|/EFI/boot}} on the EFI system partition to contain your system's {{ic|/boot}} files. For example:
 +
: {{ic|$ mkdir /esp/EFI/boot/arch64-laptop}}
 +
: {{Tip|
 +
:* The refind bootloader automatically detects and adds EFI loadable kernel files installed to the EFI system partition in {{ic|/EFI/boot/*/}} by default.
 +
:* Keying {{ic|F2}} on a highlighted refind boot menu entry enables adding the required {{ic|1=root=}} kernel parameter to an auto-added or otherwise unconfigured menu entry.}}
 +
* Move all files in {{ic|/boot}} to the newly created folder on your EFI system partition. For example:
 +
: {{ic|$ mv /boot/* /esp/EFI/boot/arch64-laptop/}}
 +
* Bind mount the newly populated folder on your EFI system partition to {{ic|/boot}}. For example:
 +
: {{ic|$ mount --bind /esp/EFI/boot/arch64-laptop /boot}}
 +
* Verify your files are available as expected with {{ic|$ ls /boot/}} then persist the configuration by editing {{ic|/etc/fstab}}. For example:
 +
: {{ic|##/etc/fstab<br />LABEL&#61;arch64-laptop_rootfs / ext4 defaults 0 0<br />LABEL&#61;esp /esp vfat defaults 0 0<br />/esp/EFI/boot/arch64-laptop /boot none defaults,bind 0 0}}
 +
* Update your bootloader to apply the {{ic|1=root=}} kernel boot parameter as necessary. For example:
 +
: {{ic|##/boot/refind_linux.conf<br />... root&#61;LABEL&#61;arch64-laptop_rootfs ...}}
 
{{Note| As of [https://www.archlinux.org/packages/extra/any/refind-efi/ refind-efi 0.2.7], refind automatically detects kernels in {{ic|/boot}}. They do not have to be renamed to have a {{ic|.efi}} extension either. Hence, the following sync scripts aren't needed if using [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd refind]. You do need to isntall an EFI driver to read the Linux filesystem on which the kernel is stored, though.}}
 
{{Note| As of [https://www.archlinux.org/packages/extra/any/refind-efi/ refind-efi 0.2.7], refind automatically detects kernels in {{ic|/boot}}. They do not have to be renamed to have a {{ic|.efi}} extension either. Hence, the following sync scripts aren't needed if using [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd refind]. You do need to isntall an EFI driver to read the Linux filesystem on which the kernel is stored, though.}}
  
 
=== Booting EFISTUB ===
 
=== Booting EFISTUB ===
  
{{Warning|Linux Kernel EFISTUB booting uses {{ic|\}} instead of {{ic|/}} and should be relative to the UEFI System Partition's root. For example, if the initramfs is located in {{ic|/boot/efi/EFI/arch/initramfs-linux.img}}, the corresponding UEFI formatted line would be {{ic|\EFI\arch\initramfs-linux.img}}. Failure to convert the options will lead to a system hang without any error message from the firmware or kernel.
+
{{Warning|Linux Kernel EFISTUB initramfs path should be relative to the EFI System Partition's root. For example, if the initramfs is located in {{ic|$esp/EFI/arch/initramfs-linux.img}}, the corresponding UEFI formatted line should be {{ic|1=initrd=/EFI/arch/initramfs-linux.img}} or {{ic|1=initrd=\EFI\arch\initramfs-linux.img}}.}}
{{Note| Support of initrd path name with {{ic|/}} in EFISTUB booting has been added in [https://patchwork.kernel.org/patch/1899361/ mainline 3.9-rc1] and [http://lwn.net/Articles/541002/ stable 3.8.2]. Leading {{ic|/}} can be ignored but the path still has to be full path. Example: {{ic|initrd&#61;EFI/arch/initramfs-linux.img}} }}
+
}}
+
  
 +
One can boot the EFISTUB kernel using one of the following ways :
  
 +
==== Directly, using efibootmgr entry ====
  
One can boot the EFISTUB kernel using one of the following ways :
+
{{Warning|1=Some kernel and efibootmgr combinations might not work without manual intervention [https://bugs.archlinux.org/task/34641]. You will be able to delete but not create boot entries.}}
 +
 
 +
{{Note|Some UEFI firmwares may not support embedding command line parameters to uefi applications in the boot entries.}}
 +
 
 +
It is possible to directly embed the kernel parameters within the boot entry created by efibootmgr. This means that you can use your UEFI boot order/GUI to directly boot Arch Linux without a separate bootloader like GRUB (below, the EFI System Partition is on {{ic|/dev/sdX}}, partition {{ic|Y}}).
 +
 
 +
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/arch/vmlinuz-arch.efi -L "Arch Linux (EFISTUB)" -u "$(cat /proc/cmdline)"
 +
 
 +
It is a good idea to run
 +
 
 +
# efibootmgr -v
 +
 
 +
to verify that the resulting entry is correct. You should also consider reordering the boot options ({{ic|efibootmgr -o}}) to place the Arch entry last, which could make the system easier to recover if it fails.
 +
 
 +
{{Tip|Save the command for creating your boot entry in a shell script somewhere, which makes it easier to modify (when changing kernel parameters, for example).}}
 +
 
 +
More info about efibootmgr at [[UEFI#efibootmgr]]. Forum post https://bbs.archlinux.org/viewtopic.php?pid=1090040#p1090040 .
 +
 
 +
==== Using gummiboot ====
 +
 
 +
[[Gummiboot]] is a UEFI Boot Manager which provides a nice menu for EFISTUB Kernels. It is available in [core] as {{Pkg|gummiboot}} is the recommended boot manager for EFISTUB booting. See [[gummiboot]] for more info.
  
 
==== Using rEFInd ====
 
==== Using rEFInd ====
  
 
rEFInd is a fork of rEFIt Boot Manager (used in Intel Macs) by Rod Smith (author of GPT-fdisk). rEFInd fixes many issues in rEFIt with respect to non-Mac UEFI booting and also has support for booting EFISTUB kernels and contains some features specific to them.
 
rEFInd is a fork of rEFIt Boot Manager (used in Intel Macs) by Rod Smith (author of GPT-fdisk). rEFInd fixes many issues in rEFIt with respect to non-Mac UEFI booting and also has support for booting EFISTUB kernels and contains some features specific to them.
 +
 
{{Tip|If you're new to EFISTUB and/or rEFInd, you need to read [http://www.rodsbooks.com/refind/linux.html The rEFInd Boot Manager: Methods of Booting Linux] before going any further. This section illustrates only one possible use-case which is not suitable for all configurations.}}
 
{{Tip|If you're new to EFISTUB and/or rEFInd, you need to read [http://www.rodsbooks.com/refind/linux.html The rEFInd Boot Manager: Methods of Booting Linux] before going any further. This section illustrates only one possible use-case which is not suitable for all configurations.}}
 +
 
# Install {{Pkg|refind-efi}} package with {{ic|# pacman -S refind-efi}}
 
# Install {{Pkg|refind-efi}} package with {{ic|# pacman -S refind-efi}}
 
# Copy the following files from their source directory to their destination
 
# Copy the following files from their source directory to their destination
Line 145: Line 204:
 
!rEFInd File Source!!UEFI Destination
 
!rEFInd File Source!!UEFI Destination
 
|-
 
|-
| /usr/lib/refind/refind_<arch>.efi || /boot/efi/EFI/refind/refind_<arch>.efi
+
| /usr/share/refind/refind_<arch>.efi || $esp/EFI/refind/refind_<arch>.efi
 
|-
 
|-
| /usr/lib/refind/config/refind.conf  || /boot/efi/EFI/refind/refind.conf
+
| /usr/share/refind/refind.conf-sample || $esp/EFI/refind/refind.conf
 
|-
 
|-
| /usr/share/refind/icons || /boot/efi/EFI/refind/icons
+
| /usr/share/refind/icons || $esp/EFI/refind/icons
 
|-
 
|-
| /usr/lib/refind/drivers_<arch> || /boot/efi/EFI/refind/drivers
+
| /usr/share/refind/drivers_<arch> || $esp/EFI/refind/drivers
 
|}
 
|}
  
{{Tip|Refind's configuration file is located in {{ic|/boot/efi/EFI/refind/refind.conf}}. The file is well commented.}}
+
{{Tip|rEFInd's configuration file is located in {{ic|$esp/EFI/refind/refind.conf}}. The file is well commented.}}
  
As of {{Pkg|refind-efi}} 0.2.7, refind can auto-detect kernels in {{ic|/boot}}, if there are UEFI drivers for the filesystem used by /boot partition (or / partition if no separate /boot is used) in the ESP, and are loaded by rEFInd. This is enabled in the default configuration in {{ic|refind.conf}} (you may need to include the PATH to the drivers folders in the ESP). Copy your {{ic|/usr/lib/refind/config/refind_linux.conf}} to {{ic|/boot/refind_linux.conf}}. You may pass kernel specific commands in this file.
+
{{Note|As of {{Pkg|refind-efi}} 0.2.7, refind can auto-detect kernels in {{ic|/boot}}, if there are UEFI drivers for the filesystem used by /boot partition (or / partition if no separate /boot is used) in the ESP, and are loaded by rEFInd. This is enabled in the default configuration in {{ic|refind.conf}} (you may need to include the PATH to the drivers folders in the ESP). See [http://www.rodsbooks.com/refind/drivers.html] for more info.}}
  
 
Edit the {{ic|refind_linux.conf}} configuration file to be similar to the template below. Replace the string after PARTUUID with your root's PARTUUID
 
Edit the {{ic|refind_linux.conf}} configuration file to be similar to the template below. Replace the string after PARTUUID with your root's PARTUUID
Line 162: Line 221:
 
{{Note|1=Please notice the [https://bbs.archlinux.org/viewtopic.php?pid=1286972 difference] between the standard UUID and the PARTUUID shown by {{ic|$ ls -l /dev/disk/by-partuuid/}}}}
 
{{Note|1=Please notice the [https://bbs.archlinux.org/viewtopic.php?pid=1286972 difference] between the standard UUID and the PARTUUID shown by {{ic|$ ls -l /dev/disk/by-partuuid/}}}}
 
{{hc|refind_linux.conf|<nowiki>
 
{{hc|refind_linux.conf|<nowiki>
"Boot with defaults" "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"
+
"Boot with defaults" "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"
"Boot to Terminal"  "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap systemd.unit=multi-user.target"</nowiki>}}
+
"Boot to Terminal"  "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw rootfstype=ext4 add_efi_memmap systemd.unit=multi-user.target"</nowiki>}}
  
 
{{Tip|Each line of {{ic|refind_linux.conf}} is displayed as a submenu by rEFInd. Access the submenu with "+" or "insert" keys.}}
 
{{Tip|Each line of {{ic|refind_linux.conf}} is displayed as a submenu by rEFInd. Access the submenu with "+" or "insert" keys.}}
Line 169: Line 228:
 
{{Tip|In non-Mac systems, create an entry for rEFInd using [[UEFI#efibootmgr|efibootmgr]] where sdX is the UEFI disk, and Y is the UEFI partition number. Run :
 
{{Tip|In non-Mac systems, create an entry for rEFInd using [[UEFI#efibootmgr|efibootmgr]] where sdX is the UEFI disk, and Y is the UEFI partition number. Run :
 
{{bc|<nowiki>
 
{{bc|<nowiki>
# modprobe efivars
+
  # efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_<arch>.efi -L "rEFInd"  
  # efibootmgr -c -w -d /dev/sdX -p Y -l '\EFI\refind\refind_<arch>.efi' -L "rEFInd"  
+
 
</nowiki>}}}}
 
</nowiki>}}}}
  
Line 188: Line 246:
 
##          : Updates nvram when needed
 
##          : Updates nvram when needed
 
##          : 10% speed boost
 
##          : 10% speed boost
 +
## 7/15/2013 : Changed arch to match 32-bit (ia32) and 64-bit (x64) naming scheme
 +
##          : Changed directory copying in update-efi-dir to copy tools and drivers directories explicitly
 +
##          : Changed efibootmgr writing code to be more concise and added (-w) to write the entry as per dusktreader's excellent guide : https://docs.google.com/document/d/1pvgm3BprpXoadsQi38FxqMOCUZhcSqFhZ26FZBkmn9I/edit
 +
##          : Function to check if NVRAM boot entry was already listed was fixed to use awk and an if then clause
 +
##          : ref_bin_escape was modified from : ref_bin_escape=${ref_bin//\//\\\\} to remove extra backslashes (error does not show up when using cmdline)
 +
## 7/29/2013 : Changed location of tools,drivers, and binary directory to match capricious upstream move to /usr/share/refind
  
 
function main () {  ## main insertion function
 
function main () {  ## main insertion function
 
   declare -r refind_dir="/boot/efi/EFI/refind"; ## set the refind directory
 
   declare -r refind_dir="/boot/efi/EFI/refind"; ## set the refind directory
   declare -r arch=$(uname -m | awk -F'_' '{if ($1 == "x86"){print $2}}') &&  ## get bit architecture
+
   arch=$(uname -m | awk -F'_' '{if ($1 == "x86") {print "x"$2} else if ($1 == "i686") {print "ia32"}}') &&  ## get bit architecture
 
   update-efi-dir;  ## updates or creates the refind directory
 
   update-efi-dir;  ## updates or creates the refind directory
 
   update-efi-nvram;  ## updates nvram if needed
 
   update-efi-nvram;  ## updates nvram if needed
Line 203: Line 267:
 
   fi;
 
   fi;
 
   if [ "$arch" ]; then  ## check if anything was stored in $arch
 
   if [ "$arch" ]; then  ## check if anything was stored in $arch
     cp -r /usr/{share/refind/*,lib/refind/refind_x*$arch*.efi} $refind_dir/ && ## update bin and dirs
+
     cp -r /usr/share/refind/{refind_$arch.efi,keys,images,icons,fonts,docs,{tools,drivers}_$arch} $refind_dir/ && ## update the bins and dirs
 
     echo "Updated binaries and directory files for refind at $refind_dir";
 
     echo "Updated binaries and directory files for refind at $refind_dir";
 
   else
 
   else
Line 212: Line 276:
  
 
function update-efi-nvram () { ## update the nvram with efibootmgr
 
function update-efi-nvram () { ## update the nvram with efibootmgr
   declare -r ref_bin=${refind_dir/\/boot\/efi}/$(ls /usr/lib | grep $arch*.efi);  ## get path of refind binary (without /boot/efi)
+
   declare -r ref_bin=${refind_dir/\/boot\/efi}/refind_$arch.efi;  ## get path of refind binary (without /boot/efi)
   declare -r ref_bin_escape=${ref_bin//\//\\\\};  ## insert escape characters into $ref_bin
+
   declare -r ref_bin_escape=${ref_bin//\//\\};  ## insert escape characters into $ref_bin
   modprobe efivars && ## grab the efi variables for efibootmgr
+
   [ "$(efibootmgr -v | awk "/${ref_bin_escape//\\/\\\\}/")" ] && ( ## check if boot entry is in nvram \
  efibootmgr -v | grep $ref_bin_escape && ( ## check if boot entry is in nvram
+
 
     echo "Found boot entry, no need to update nvram";
 
     echo "Found boot entry, no need to update nvram";
 
     ) || ( ## if boot entry is not in nvram; add it
 
     ) || ( ## if boot entry is not in nvram; add it
 
     declare -r esp=$(mount -l | awk '/ESP/ {print $1}') &&  ## get ESP partition
 
     declare -r esp=$(mount -l | awk '/ESP/ {print $1}') &&  ## get ESP partition
     efibootmgr -c -w -d ${esp:0:8} -p ${esp:8} -L "rEFInd" -l $ref_bin_escape && ## update nvram
+
     efibootmgr -cgw -d ${esp:0:8} -p ${esp:8} -L "rEFInd" -l $ref_bin_escape && ## update nvram
 
     echo "
 
     echo "
 
     Updated nvram with entry rEFInd to boot $ref_bin
 
     Updated nvram with entry rEFInd to boot $ref_bin
Line 225: Line 288:
 
     )
 
     )
 
}
 
}
 
 
main;  ## run the main insertion function
 
main;  ## run the main insertion function
 
</nowiki>}}
 
</nowiki>}}
Line 237: Line 299:
  
 
[Path]
 
[Path]
PathChanged=/usr/lib/refind/refind_<arch>.efi
+
PathChanged=/usr/share/refind/refind_<arch>.efi
 
Unit=refind_update.service
 
Unit=refind_update.service
  
Line 269: Line 331:
  
 
In case of VirtualBox, see [[VirtualBox#Using_Arch_under_Virtualbox_EFI_mode]].
 
In case of VirtualBox, see [[VirtualBox#Using_Arch_under_Virtualbox_EFI_mode]].
 
==== Using gummiboot ====
 
 
[[Gummiboot]] is a UEFI Boot Manager which provides a nice menu for EFISTUB Kernels. It is available in [extra] as {{Pkg|gummiboot}}. See https://wiki.archlinux.org/index.php/Gummiboot for more info.
 
  
 
==== Using UEFI Shell ====
 
==== Using UEFI Shell ====
Line 294: Line 352:
 
This way you can specify UUID's without needing to remember the name or type out 20-30 characters.
 
This way you can specify UUID's without needing to remember the name or type out 20-30 characters.
  
==== Using efibootmgr entry ====
+
== GRUB 2.xx ==
  
{{Warning|1=Some kernel and efibootmgr combinations do not work [https://bugs.archlinux.org/task/34641]. You will be able to delete but not create boot entries.}}
+
GRUB 2.x contains its own filesystem drivers and does not rely on the firmware to access the files. It can directly read files from {{ic|/boot}} and does not require the kernel and initramfs files to be in the UEFISYS partition. Detailed information at [[GRUB#UEFI_systems_2]]. For bzr development version try AUR package - {{AUR|grub-bzr}}.
  
{{Note|Some UEFI firmwares may not support embedding command line parameters to uefi applications in the boot entries.}}
+
== SYSLINUX 6.xx ==
  
It is possible to directly embed the kernel parameters within the boot entry created by efibootmgr. This means that in your BIOS/UEFI you will be able to select Arch Linux directly in the default boot order, and on startup it will boot into Arch directly without any kind of boot selection GUI.
+
Install {{Pkg|syslinux}} (from [testing]) or {{AUR|syslinux-firmware-git}} AUR package and copy {{ic|/usr/lib/syslinux/efi64/*}} to {{ic|$esp/EFI/syslinux/}} ({{ic|$esp}} is the mountpoint of UEFISYS partition) ({{ic|efi64}} is for x86_64 UEFI firmwares, replace with {{ic|efi32}} for ia32 UEFI firmwares), and then create a boot entry using efibootmgr in the firmware boot manager.
  
# modprobe efivarfs
+
== ELILO ==
# modprobe efivars
+
# efibootmgr -c -w -d /dev/sdX -p Y -l '\EFI\arch\vmlinuz-arch.efi' -L "Arch Linux (EFISTUB)" -u $(cat /proc/cmdline)
+
  
It is a good idea to run
+
ELILO is the UEFI version of LILO Boot Loader. It was originally created for Intel Itanium systems which supported only EFI (precursor to UEFI). It is the oldest UEFI bootloader for Linux. It is still in development but happens at a very slow pace. Upstream provided compiled binaries are available at http://sourceforge.net/projects/elilo/ . Elilo config file {{ic|elilo.conf}} is similar to [[LILO]]'s config file. AUR package - {{AUR|elilo-efi}}.
  
# efibootmgr -v
+
== Troubleshooting ==
 +
{{Poor writing|This troubleshooting note has been transferred from [[Beginners' Guide]] as discussed on the talk page. It is not yet well integrated here and is rather selective in terms of the help provided.}}
  
to verify that the resulting entry is correct. You should also consider reordering the boot options ({{ic|efibootmgr -o}}) to place the Arch entry last, which could make the system easier to recover if it fails.
+
* On some UEFI motherboards like the Intel Z77 boards, adding entries with efibootmgr or bcfg from efi shell will not work because they don't show up on the boot menu list after being added to NVRAM.
 
+
More info about efibootmgr at [[UEFI#efibootmgr]]. Forum post https://bbs.archlinux.org/viewtopic.php?pid=1090040#p1090040 .
+
 
+
== GRUB 2.x ==
+
 
+
GRUB 2.x contains its own filesystem drivers and does not rely on the firmware to access the files. It can directly read files from {{ic|/boot}} and does not require the kernel and initramfs files to be in the UEFISYS partition. Detailed information at [[GRUB#UEFI_systems_2]]. For bzr development version try AUR package - {{AUR|grub-efi-x86_64-bzr}}.
+
 
+
== SYSLINUX ==
+
 
+
{{Note|Syslinux UEFI support is currently part of version 6.00 (in firmware branch of upstream git repo).}}
+
 
+
Install {{AUR|syslinux-efi-git}} AUR package and copy {{ic|/usr/lib/syslinux/efi64/*}} to {{ic|$esp/EFI/syslinux/}} ({{ic|$esp}} is the mountpoint of UEFISYS partition) ({{ic|efi64}} is for x86_64 UEFI firmwares, replace with {{ic|efi32}} for ia32 UEFI firmwares), and then create a boot entry using efibootmgr in the firmware boot manager.
+
 
+
== ELILO ==
+
 
+
ELILO is the UEFI version of LILO Boot Loader. It was originally created for Intel Itanium systems which supported only EFI (precursor to UEFI). It is the oldest UEFI bootloader for Linux. It is still in development but happens at a very slow pace. Upstream provided compiled binaries are available at http://sourceforge.net/projects/elilo/ . Elilo config file {{ic|elilo.conf}} is similar to [[LILO]]'s config file. AUR package - {{AUR|elilo-efi}}.
+
  
== EFILINUX ==
+
:To solve this you have to trick the UEFI firmware that Windows boot manager is present on the ESP partition.
  
EFILINUX is the precursor to Kernel EFISTUB support. It can be used to boot kernel that do not support EFISTUB (mainly LTS kernels). Upstream sources are at https://git.kernel.org/cgit/boot/efilinux/efilinux.git/ and the usage instructions are at http://thread.gmane.org/gmane.linux.kernel/1172645 and http://article.gmane.org/gmane.linux.kernel/1175060 . It is available in the [extra] as {{Pkg|efilinux-efi}}.
+
:Copy the bootx64.efi file from USB drive as bootmgfw.efi efi file to your ESP partition by booting into EFI shell and typing:
  
== Package Naming Guidelines ==
+
FS1:
 +
cd EFI
 +
mkdir Microsoft
 +
cd Microsoft
 +
mkdir Boot
 +
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi
  
UEFI bootloader package(s) should be suffixed with {{ic|-efi-x86_64}} or {{ic|-efi-i386}} to denote package built for 64-bit and 32-bit UEFI respectively. If a single package contains both 64-bit and 32-bit UEFI applications, then {{ic|-efi}} suffix should be used in the '''pkgname'''.
+
:After reboot, any entries added to NVRAM should show up in the boot menu.
  
 
== See also ==
 
== See also ==

Revision as of 17:12, 1 October 2013

This page contains info about various UEFI Bootloaders capable of booting Linux kernel. It is recommended to read the UEFI and GPT pages before reading this page. The following bootloaders are explained here:

Linux Kernel EFISTUB

Warning: A bug has been noticed where booting EFISTUB can fail depending on kernel version and motherboard model. See [1] for more information.

The Linux Kernel (linux>=3.3) supports EFISTUB (EFI BOOT STUB) booting. It is enabled by default on Arch Linux kernels or can be activated by setting CONFIG_EFI_STUB=y in the Kernel configuration (see The EFI Boot Stub for more information).

A single EFISTUB kernel is not capable of launching other kernels, hence each EFISTUB Kernel + Initramfs pair requires a separate boot menu entry. Because of this, when working with multiple kernels, it is recommended to use a UEFI Boot Manager.

Setting up EFISTUB

  1. Create a EFI System Partition.
  2. Mount the EFI System Partition either at /boot (recommended if you are planning to use Gummiboot or no boot manager) or some other location of your choice (most other distro's and tools use /boot/efi). The mountpoint will be mentioned as $esp hereafter.

Moving everything to the right place

Warning: The below steps are required only if you DID NOT use /boot as the EFISYS mountpoint. If you did choose /boot as mountpoint, you can continue to #Booting EFISTUB.
  1. Create $esp/EFI/arch/
  2. Copy the following files from source to destination
Boot File Source UEFI Destination
/boot/vmlinuz-linux $esp/EFI/arch/vmlinuz-arch.efi
/boot/initramfs-linux.img $esp/EFI/arch/initramfs-arch.img
/boot/initramfs-linux-fallback.img $esp/EFI/arch/initramfs-arch-fallback.img
Warning: The EFISTUB Kernel must be updated each time the kernel is updated (follow step 4 in #Setting up EFISTUB. Failure to do so will result in failure to boot. Alternatively one can automatically update the EFISTUB kernel using one of the following methods:
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.

Warning: Since mkinitcpio takes time to build the kernel stub and the initramfs. It is possible for the following systemd services to copy older kernel stubs and initramfs instead of the new ones. To reduce the chance of this error, it is better to bind the efistub copying service to check if the initramfs-linux-fallback.img was changed (since it is the last thing built by mkinitcpio).
Tip: Save the following script as /etc/systemd/system/efistub-update.path
[Unit]
Description=Copy EFISTUB Kernel to UEFISYS Partition

[Path]
PathChanged=/boot/initramfs-linux-fallback.img

[Install]
WantedBy=multi-user.target
Tip: Save the following script as /etc/systemd/system/efistub-update.service
[Unit]
Description=Copy EFISTUB Kernel to UEFISYS Partition

[Service]
Type=oneshot
ExecStart=/usr/bin/cp -f /boot/vmlinuz-linux $esp/EFI/arch/vmlinuz-arch.efi
ExecStart=/usr/bin/cp -f /boot/initramfs-linux.img $esp/EFI/arch/initramfs-arch.img
ExecStart=/usr/bin/cp -f /boot/initramfs-linux-fallback.img $esp/EFI/arch/initramfs-arch-fallback.img
Tip: Enable these services with
# systemctl enable efistub-update.path
Incron

incron can run a script to sync the EFISTUB Kernel after updates

Tip: Save the following script as /usr/local/bin/efistub-update.sh
#!/usr/bin/env bash
/usr/bin/cp -f /boot/vmlinuz-linux $esp/EFI/arch/vmlinuz-arch.efi
/usr/bin/cp -f /boot/initramfs-linux.img $esp/EFI/arch/initramfs-arch.img
/usr/bin/cp -f /boot/initramfs-linux-fallback.img $esp/EFI/arch/initramfs-arch-fallback.img
Tip: Save the following script as /etc/incron.d/efistub-update.conf
Note: The first parameter /boot/initramfs-linux-fallback.img is the file to watch. The second parameter IN_CLOSE_WRITE is the action to watch for. The third parameter /usr/local/bin/efistub-update.sh is the script to execute.
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update.sh
Tip: In order to use this method, incron must be activated, if it is not run
# systemctl enable incrond.service
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 vm-linuz, initramfs-linux.img, and initramfs-linux-fallback.img; then follows step 4 in Setting up EFISTUB

Tip: Save the following script as /usr/lib/initcpio/install/efistub-update
#!/usr/bin/env bash

build() {
	/root/watch.sh &
}

help() {
	cat <<HELPEOF
This hook waits for mkinitcpio to finish and copies the finished ramdisk and kernel to the ESP
HELPEOF
}
Tip: Save the following script as /root/watch.sh and make it executable
#!/usr/bin/env bash

while [[ -d "/proc/$PPID" ]]; do
	sleep 1
done

/usr/bin/cp -f /boot/vmlinuz-linux $esp/EFI/arch/vmlinuz-arch.efi
/usr/bin/cp -f /boot/initramfs-linux.img $esp/EFI/arch/initramfs-arch.img
/usr/bin/cp -f /boot/initramfs-linux-fallback.img $esp/EFI/arch/initramfs-arch-fallback.img

echo "Synced kernel with ESP"
Tip: Add efistub-update to the list of hooks in /etc/mkinitcpio.conf
/etc/fstab bind mount
Note:
  • The following method should work similarly with any distribution that does not symlink in /boot. See Warnings for caveats.
  • This involves no special scripts, services, or bootloader filesystem drivers.
  • This centralizes and organizes kernels and initrds across installations on one partition.
  • This avoids possible limitations imposed by firmware and/or the bootloader on boot device configuration as can often occur with RAID and/or LVM (excepting the standard FAT32 EFI system partition, of course).
  • Beyond initial configuration this should persist without special consideration or maintenance.
  • This should be transparent to any action normally affecting /boot and the files therein.
Warning:
  • This requires both a kernel and a bootloader compatible with the FAT32 filesystem.
  • Because the FAT32 filesystem cannot handle symlinks, this will not behave as intended with an installation that requires them in /boot.
  • Initial configuration requires root level access.
  • This may require a large EFI system partition in order to accomodate multiple installations.
  • All kernels will require at least a root=system root parameter passed at boot.
  • per rEFInd's author: OpenSUSE definitely uses symbolic links in /boot... Fedora, Ubuntu, and ... OpenSUSE all refuse a FAT partition as /boot in ... setup [which] can be worked around [in] /etc/fstab. Forum post [here].
Method
Whereas the general convention is to mount the EFI system partition to a /boot/efi subfolder, the following will achieve the opposite.
  • Create a ef00 type EFI system partition of FAT32 format as described elsewhere.
Tip:
  • It may be beneficial to make it several gigabytes in size to accomodate multiple installations.
  • Use the GPT partition name feature for added convenience. For example name the partition esp.
  • Create a mount-point and mount the EFI system partition somewhere on the filesystem. For example:
$ mkdir /esp
$ mount -L esp /esp
  • Create a folder in /EFI/boot on the EFI system partition to contain your system's /boot files. For example:
$ mkdir /esp/EFI/boot/arch64-laptop
Tip:
  • The refind bootloader automatically detects and adds EFI loadable kernel files installed to the EFI system partition in /EFI/boot/*/ by default.
  • Keying F2 on a highlighted refind boot menu entry enables adding the required root= kernel parameter to an auto-added or otherwise unconfigured menu entry.
  • Move all files in /boot to the newly created folder on your EFI system partition. For example:
$ mv /boot/* /esp/EFI/boot/arch64-laptop/
  • Bind mount the newly populated folder on your EFI system partition to /boot. For example:
$ mount --bind /esp/EFI/boot/arch64-laptop /boot
  • Verify your files are available as expected with $ ls /boot/ then persist the configuration by editing /etc/fstab. For example:
##/etc/fstab
LABEL=arch64-laptop_rootfs / ext4 defaults 0 0
LABEL=esp /esp vfat defaults 0 0
/esp/EFI/boot/arch64-laptop /boot none defaults,bind 0 0
  • Update your bootloader to apply the root= kernel boot parameter as necessary. For example:
##/boot/refind_linux.conf
... root=LABEL=arch64-laptop_rootfs ...
Note: As of refind-efi 0.2.7, refind automatically detects kernels in /boot. They do not have to be renamed to have a .efi extension either. Hence, the following sync scripts aren't needed if using refind. You do need to isntall an EFI driver to read the Linux filesystem on which the kernel is stored, though.

Booting EFISTUB

Warning: Linux Kernel EFISTUB initramfs path should be relative to the EFI System Partition's root. For example, if the initramfs is located in $esp/EFI/arch/initramfs-linux.img, the corresponding UEFI formatted line should be initrd=/EFI/arch/initramfs-linux.img or initrd=\EFI\arch\initramfs-linux.img.

One can boot the EFISTUB kernel using one of the following ways :

Directly, using efibootmgr entry

Warning: Some kernel and efibootmgr combinations might not work without manual intervention [2]. You will be able to delete but not create boot entries.
Note: Some UEFI firmwares may not support embedding command line parameters to uefi applications in the boot entries.

It is possible to directly embed the kernel parameters within the boot entry created by efibootmgr. This means that you can use your UEFI boot order/GUI to directly boot Arch Linux without a separate bootloader like GRUB (below, the EFI System Partition is on /dev/sdX, partition Y).

# efibootmgr -c -d /dev/sdX -p Y -l /EFI/arch/vmlinuz-arch.efi -L "Arch Linux (EFISTUB)" -u "$(cat /proc/cmdline)"

It is a good idea to run

# efibootmgr -v

to verify that the resulting entry is correct. You should also consider reordering the boot options (efibootmgr -o) to place the Arch entry last, which could make the system easier to recover if it fails.

Tip: Save the command for creating your boot entry in a shell script somewhere, which makes it easier to modify (when changing kernel parameters, for example).

More info about efibootmgr at UEFI#efibootmgr. Forum post https://bbs.archlinux.org/viewtopic.php?pid=1090040#p1090040 .

Using gummiboot

Gummiboot is a UEFI Boot Manager which provides a nice menu for EFISTUB Kernels. It is available in [core] as gummiboot is the recommended boot manager for EFISTUB booting. See gummiboot for more info.

Using rEFInd

rEFInd is a fork of rEFIt Boot Manager (used in Intel Macs) by Rod Smith (author of GPT-fdisk). rEFInd fixes many issues in rEFIt with respect to non-Mac UEFI booting and also has support for booting EFISTUB kernels and contains some features specific to them.

Tip: If you're new to EFISTUB and/or rEFInd, you need to read The rEFInd Boot Manager: Methods of Booting Linux before going any further. This section illustrates only one possible use-case which is not suitable for all configurations.
  1. Install refind-efi package with # pacman -S refind-efi
  2. Copy the following files from their source directory to their destination
Note: <arch> is the bit architecture of the system. Run $ uname -m to get the architecture. Replace <arch> with "ia32" for 32 bit systems, and <arch> with "x64" for 64 bit systems.
rEFInd File Source UEFI Destination
/usr/share/refind/refind_<arch>.efi $esp/EFI/refind/refind_<arch>.efi
/usr/share/refind/refind.conf-sample $esp/EFI/refind/refind.conf
/usr/share/refind/icons $esp/EFI/refind/icons
/usr/share/refind/drivers_<arch> $esp/EFI/refind/drivers
Tip: rEFInd's configuration file is located in $esp/EFI/refind/refind.conf. The file is well commented.
Note: As of refind-efi 0.2.7, refind can auto-detect kernels in /boot, if there are UEFI drivers for the filesystem used by /boot partition (or / partition if no separate /boot is used) in the ESP, and are loaded by rEFInd. This is enabled in the default configuration in refind.conf (you may need to include the PATH to the drivers folders in the ESP). See [3] for more info.

Edit the refind_linux.conf configuration file to be similar to the template below. Replace the string after PARTUUID with your root's PARTUUID

Note: Please notice the difference between the standard UUID and the PARTUUID shown by $ ls -l /dev/disk/by-partuuid/
refind_linux.conf
"Boot with defaults" "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"
"Boot to Terminal"   "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw rootfstype=ext4 add_efi_memmap systemd.unit=multi-user.target"
Tip: Each line of refind_linux.conf is displayed as a submenu by rEFInd. Access the submenu with "+" or "insert" keys.
Tip: In non-Mac systems, create an entry for rEFInd using efibootmgr where sdX is the UEFI disk, and Y is the UEFI partition number. Run :
 # efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_<arch>.efi -L "rEFInd" 
Systemd Automation
Tip: To automate the process of copying refind files and updating the nvram (if needed) use the following script
Note: Save this script as /usr/lib/systemd/scripts/refind_name_patchv2
Tip: If you want to change the directory that refind is installed in the UEFISYS partition, just change the value of $refind_dir in the script
#!/usr/bin/env bash
## COPYRIGHT 2013 : MARK E. LEE (BLUERIDER) : mlee24@binghamton.edu; mark@markelee.com

## LOG
## 1/17/2013 : Version 2 of refind_name_patch is released
##           : Supports long subdirectory location for refind
##           : Updates nvram when needed
##           : 10% speed boost
## 7/15/2013 : Changed arch to match 32-bit (ia32) and 64-bit (x64) naming scheme
##           : Changed directory copying in update-efi-dir to copy tools and drivers directories explicitly
##           : Changed efibootmgr writing code to be more concise and added (-w) to write the entry as per dusktreader's excellent guide : https://docs.google.com/document/d/1pvgm3BprpXoadsQi38FxqMOCUZhcSqFhZ26FZBkmn9I/edit
##           : Function to check if NVRAM boot entry was already listed was fixed to use awk and an if then clause
##           : ref_bin_escape was modified from : ref_bin_escape=${ref_bin//\//\\\\} to remove extra backslashes (error does not show up when using cmdline)
## 7/29/2013 : Changed location of tools,drivers, and binary directory to match capricious upstream move to /usr/share/refind

function main () {  ## main insertion function
  declare -r refind_dir="/boot/efi/EFI/refind"; ## set the refind directory
  arch=$(uname -m | awk -F'_' '{if ($1 == "x86") {print "x"$2} else if ($1 == "i686") {print "ia32"}}') &&  ## get bit architecture
  update-efi-dir;  ## updates or creates the refind directory
  update-efi-nvram;  ## updates nvram if needed
}

function update-efi-dir () {  ## setup the refind directory
  if [ ! -d $refind_dir ]; then  ## check if refind directory exists
    echo "Couldn't find $refind_dir";
    mkdir $refind_dir &&  ## make the refind directory if needed
    echo "Made $refind_dir";
  fi;
  if [ "$arch" ]; then  ## check if anything was stored in $arch
    cp -r /usr/share/refind/{refind_$arch.efi,keys,images,icons,fonts,docs,{tools,drivers}_$arch} $refind_dir/  && ## update the bins and dirs
    echo "Updated binaries and directory files for refind at $refind_dir";
   else
    echo "Failed to detect an x86 architecture";
    exit;
  fi;
}

function update-efi-nvram () { ## update the nvram with efibootmgr
  declare -r ref_bin=${refind_dir/\/boot\/efi}/refind_$arch.efi;  ## get path of refind binary (without /boot/efi)
  declare -r ref_bin_escape=${ref_bin//\//\\};  ## insert escape characters into $ref_bin
  [ "$(efibootmgr -v | awk "/${ref_bin_escape//\\/\\\\}/")" ] && ( ## check if boot entry is in nvram \
    echo "Found boot entry, no need to update nvram";
    ) || ( ## if boot entry is not in nvram; add it
    declare -r esp=$(mount -l | awk '/ESP/ {print $1}') &&  ## get ESP partition
    efibootmgr -cgw -d ${esp:0:8} -p ${esp:8} -L "rEFInd" -l $ref_bin_escape && ## update nvram
    echo "
    Updated nvram with entry rEFInd to boot $ref_bin
    Did not copy configuration files, please move refind.conf to $refind_dir/";
    )
}
main;  ## run the main insertion function
Note: As of refind-efi 0.2.7, refind automatically detects kernels in /boot. They do not have to be renamed to have a .efi extension either. Hence, the following sync scripts aren't needed if using refind. You do need to isntall an EFI driver to read the Linux filesystem on which the kernel is stored, though.
Note: Save the following service file as /usr/lib/systemd/system/refind_update.path
[Unit]
Description=Update rEFInd bootloader files

[Path]
PathChanged=/usr/share/refind/refind_<arch>.efi
Unit=refind_update.service

[Install]
WantedBy=multi-user.target
Note: Save the following service file as /usr/lib/systemd/system/refind_update.service
[Unit]
Description=Update rEFInd directories, binaries, and nvram

[Service]
Type=oneshot
ExecStart=/usr/bin/bash /usr/lib/systemd/scripts/refind_name_patchv2
RemainAfterExit=no
Tip: Enable the systemd path unit by running :
# systemctl enable refind_update.path
Apple Macs

In case of Apple Macs, try mactel-bootAUR for an experimental "bless" utility for Linux. If that does not work, use "bless" form within OSX to set rEFInd as default bootloader. Assuming UEFISYS partition is mounted at /mnt/efi within OSX, do

$ sudo bless --setBoot --folder /mnt/efi/EFI/refind --file /mnt/efi/EFI/refind/refind_x64.efi
VirtualBox

In case of VirtualBox, see VirtualBox#Using_Arch_under_Virtualbox_EFI_mode.

Using UEFI Shell

It is possible to launch EFISTUB kernel form UEFI Shell as if it is a normal UEFI application. In this case the kernel parameters are passed as normal parameters to the launched EFISTUB kernel file.

> fs0:
> cd \EFI\arch
> vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=EFI/arch/initramfs-arch.img

You can also write a simple archlinux.nsh file with your boot parameters and put it in your UEFI System Partition, then run it with:

fs0:
archlinux

Example Script:

echo -on
\EFI\arch\vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rootfstype=ext4 add_efi_memmap initrd=EFI/arch/initramfs-arch.img

This way you can specify UUID's without needing to remember the name or type out 20-30 characters.

GRUB 2.xx

GRUB 2.x contains its own filesystem drivers and does not rely on the firmware to access the files. It can directly read files from /boot and does not require the kernel and initramfs files to be in the UEFISYS partition. Detailed information at GRUB#UEFI_systems_2. For bzr development version try AUR package - grub-bzrAUR.

SYSLINUX 6.xx

Install syslinux (from [testing]) or syslinux-firmware-gitAUR AUR package and copy /usr/lib/syslinux/efi64/* to $esp/EFI/syslinux/ ($esp is the mountpoint of UEFISYS partition) (efi64 is for x86_64 UEFI firmwares, replace with efi32 for ia32 UEFI firmwares), and then create a boot entry using efibootmgr in the firmware boot manager.

ELILO

ELILO is the UEFI version of LILO Boot Loader. It was originally created for Intel Itanium systems which supported only EFI (precursor to UEFI). It is the oldest UEFI bootloader for Linux. It is still in development but happens at a very slow pace. Upstream provided compiled binaries are available at http://sourceforge.net/projects/elilo/ . Elilo config file elilo.conf is similar to LILO's config file. AUR package - elilo-efiAUR.

Troubleshooting

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements.Tango-edit-clear.png

Reason: This troubleshooting note has been transferred from Beginners' Guide as discussed on the talk page. It is not yet well integrated here and is rather selective in terms of the help provided. (Discuss in Talk:UEFI Bootloaders#)
  • On some UEFI motherboards like the Intel Z77 boards, adding entries with efibootmgr or bcfg from efi shell will not work because they don't show up on the boot menu list after being added to NVRAM.
To solve this you have to trick the UEFI firmware that Windows boot manager is present on the ESP partition.
Copy the bootx64.efi file from USB drive as bootmgfw.efi efi file to your ESP partition by booting into EFI shell and typing:
FS1:
cd EFI
mkdir Microsoft
cd Microsoft
mkdir Boot
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi
After reboot, any entries added to NVRAM should show up in the boot menu.

See also