{{Note|1=This menthod may not work due to [https://git.kernel.org/?p=linux/kernel/git/mfleming/efi.git;a=commitdiff;h=b003aaf799c991295b8b73e8f940d20bda2c1bbb;hp=ddffeb8c4d0331609ef2581d84de4d763607bd37 limitations in how the kernel handles uefi runtime variables].}}

+

{{Note|1=This menthod may not work due to [https://git.kernel.org/?p=linux/kernel/git/mfleming/efi.git;a=commitdiff;h=b003aaf799c991295b8b73e8f940d20bda2c1bbb;hp=ddffeb8c4d0331609ef2581d84de4d763607bd37 limitations in how the kernel handles uefi runtime variables]. For example in Lenovo Thinkpads the initrd path is truncated (verified using {{ic|efibootmgr -v}} command) and therefore the kernel fails to boot.}}

−

{{Note|Some UEFI firmwares may not support embedding command line parameters to uefi applications in the 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 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.

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.

Revision as of 06:28, 29 November 2012

zh-CN:UEFI Bootloaders
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 (listed in decreasing order of stability) are explained here:

Since the kernel is responsible for booting only itself, a single EFISTUB enabled kernel is not capable of launching other kernels. And each EFISTUB Kernel+Initramfs pair requires a separate boot menu entry. Thus when multiple kernels and/or initramfs files are involved, a UEFI Boot Manager is recommended to manage them.

Setting up EFISTUB

Copy /boot/vmlinuz-linux to /boot/efi/EFI/arch/vmlinuz-arch.efi . The .efi file extension is very important as some UEFI firmwares refuse to launch a file without the .efi file extension. Important: Remember that the file is called vmlinuz, but not vmlinux.

Note: A new feature to be introduced in kernel is the ability to store the kernel boot parameters in a file. To do so, create /boot/efi/EFI/arch/linux.conf with the kernel parameters to be passed to the kernel (example file shown below). This file should consist of only one line and simply contains all the kernel parameters to be used by the EFISTUB loader to the kernel.

Please notice the difference between the standard UUID and the PARTUUID shown by ls -l /dev/disk/by-partuuid/. This feature is not included in kernel version upto 3.7 and may or may not appear in kernel 3.8 and above.

Finally, jump to #Booting_EFISTUB choose a way to get your machine to make use of the new EFISTUB you've just created.

Note: The kernel and initramfs files at /boot/efi/EFI/arch/ should be updated everytime those files in /boot are updated.

Warning: In Linux Kernel EFISTUB booting, initrd= path should use UEFI-style backslashes (\) and should be relative to the UEFI System Partition's root, not relative to the current directory in the UEFI Shell. An improper initrd= option leads to a system hang without any error message from the firmware or the kernel.

Sync EFISTUB Kernel in UEFISYS partition using Systemd

Systemd init system supports defining tasks that should be performed when certain files/paths are changed. This feature of systemd is used to copy updated EFISTUB kernel and initramfs files when they are updated in /boot, like during package updates or during manual run of mkinitcpio etc.

Specify which file to watch for changes in /etc/incron.d/efistub-update.conf. The first parameter is the file to watch: /boot/initramfs-linux-fallback.img. 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.

Then simply add efistub-update to the list of hooks in /etc/mkinitcpio.conf

Booting EFISTUB

There are various ways of booting EFISTUB kernels. Those described here are:

Using rEFInd UEFI Boot Manager <-- Nice boot GUI.

Using Gummiboot Boot Manager

Using UEFI Shell

Using efibootmgr entry <-- will load Arch Linux directly. No GUI.

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. More info about rEFInd support for EFISTUB is at http://www.rodsbooks.com/refind/linux.html .

where /dev/sdX is the drive and Y is the partition number of UEFISYS in /dev/sdXY.

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

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 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.

Do (as root):

Install efibootmgr if you haven't already.

# pacman -S --needed efibootmgr

Determine the UUID or PARTUUID of your boot device (ie. the partition for /, not the EFI boot partition)

# blkid

Load the EFI module.

# modprobe efivars

Finally, add the efistub.
WARNING: Make sure you replace the following before running this command:

3518bb68-d01e-45c9-b973-0b5d918aae96 -- with the UUID of your / partition. (This is not PARTUUID!)

Note: Some firmwares may have trouble with the "initrd path" when piping in ucs-2 as shown above. In this case, one may put vmlinuz-linux.efi and the initramfs in the root of the ESP and adjust the efibootmgr entry accordingly.

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 /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-efi-x86_64-bzrAUR.

SYSLINUX

Note: syslinux-efi support is currently available only in upstream git repo and is of alpha-quality. The below information is provided mainly to enable bug-testing. Please report all issues upstream.

Install syslinux-efi-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 i386 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-efi-x86_64AUR (only for x86_64 UEFI).

Package Naming Guidelines

UEFI bootloader package(s) should be suffixed with -efi-x86_64 or -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 -efi suffix should be used in the pkgname.