rEFInd

rEFInd is a UEFI boot manager capable of launching EFISTUB kernels. It is a fork of the no-longer-maintained rEFIt and fixes many issues with respect to non-Mac UEFI booting. It is designed to be platform-neutral and to simplify booting multiple operating systems.

Note: In the entire article esp denotes the mountpoint of the EFI system partition.

Installation

Install the refind package.

Installing the rEFInd Boot Manager

rEFInd ships with UEFI drivers that implement read-only support for ReiserFS, Ext2, Ext4, Btrfs, ISO-9660 and HFS+. Additionally rEFInd can access any file system that UEFI itself can, that includes FAT (as mandated by the UEFI specification), HFS+ on Macs and ISO-9660 on some systems.

To find additional drivers see The rEFInd Boot Manager: Using EFI Drivers: Finding Additional EFI Drivers.

To use the rEFInd, you must install it to the EFI system partition either using the refind-install script or by copying the files and setting up the boot entry manually.

Warning: Your kernel and initramfs must reside on a file system that rEFInd can read.

Installation with refind-install script

The rEFInd package includes the refind-install script to simplify the process of setting rEFInd as your default EFI boot entry. The script has several options for handling differing setups and UEFI implementations. See or read the comments in the install script for explanations of the various installation options.

For many systems it should be sufficient to simply run:

# refind-install

This will attempt to find and mount your ESP, copy rEFInd files to , and use efibootmgr to make rEFInd the default EFI boot application.

Alternatively you can install rEFInd to the default/fallback boot path esp/EFI/BOOT/bootx64.efi. This is helpful for bootable USB flash drives or on systems that have issues with the NVRAM changes made by efibootmgr:

# refind-install --usedefault /dev/sdXY

Where is your EFI system partition (the block device, not its mountpoint).

Tip: By default refind-install installs only the driver for the file system on which kernel resides. Additional file systems need to be installed manually by copying them from /usr/share/refind/drivers_x64/ to esp/EFI/refind/drivers_x64/, or you can install all drivers with the --alldrivers option. This is useful for bootable USB flash drives.

After installing rEFInd's files to the ESP, verify that rEFInd has created containing kernel parameters in the same directory as your kernel. This configuration file will not be created if you used the option, run as root to create it.

By default, rEFInd will scan all of your drives (that it has drivers for) and add a boot entry for each EFI bootloader it finds, which should include your kernel (since Arch enables EFISTUB by default). So you may have a bootable system at this point.

Secure Boot

See Managing Secure Boot for Secure Boot support in rEFInd.

Using PreLoader

See Secure Boot#Set up PreLoader to acquire signed and binaries.

Execute with the option --preloader /path/to/preloader

# refind-install --preloader /usr/share/preloader-signed/PreLoader.efi

Next time you boot with Secure Boot enabled, HashTool will launch and you will need to enroll the hash of rEFInd (), rEFInd's drivers (e.g. ext4_x64.efi) and kernel (e.g. ).

See for more information.

Using shim

Install . Read Secure Boot#shim, but skip all file copying.

Using hashes

To use only hashes with shim, execute with the option

# refind-install --shim /usr/share/shim-signed/shimx64.efi

Next time you boot with Secure Boot enabled, MokManager will launch and you will need to enroll the hash of rEFInd (), rEFInd's drivers (e.g. ext4_x64.efi) and kernel (e.g. ).

Using Machine Owner Key

To sign rEFInd with a Machine Owner Key (MOK), install .

Tip: If you already have created a MOK, place the files in the directory /etc/refind.d/keys with the names refind_local.key (PEM format private key), refind_local.crt (PEM format certificate) and refind_local.cer (DER format certificate).

Execute with the options and :

# refind-install --shim /usr/share/shim-signed/shimx64.efi --localkeys

refind-install will create the keys for you and sign itself and its drivers. You will need to sign the kernel with the same key, e.g.:

# sbsign --key /etc/refind.d/keys/refind_local.key --cert /etc/refind.d/keys/refind_local.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
Tip: The kernel signing can be automated with a pacman hook, see Secure Boot#Signing the kernel with a pacman hook.

Once in MokManager add to MoKList. can be found inside a directory called in the rEFInd's installation directory, e.g. .

See for more information.

Using your own keys

Follow Secure Boot#Using your own keys to create keys.

Create directory and place Signature Database (db) key and certificates in it. Name the files: (PEM format private key), (PEM format certificate) and (DER format certificate).

When running install script add option , e.g.:

# refind-install --localkeys

rEFInd EFI binaries will be signed with the supplied key and certificate.

Manual installation

If the script does not work for you, rEFInd can be set up manually.

First, copy the executable to the ESP:

# mkdir -p esp/EFI/refind
# cp /usr/share/refind/refind_x64.efi esp/EFI/refind/

If you want to install rEFInd to the default/fallback boot path replace with in the following instructions and copy rEFInd EFI executable to esp/EFI/BOOT/bootx64.efi:

# mkdir -p esp/EFI/BOOT
# cp /usr/share/refind/refind_x64.efi esp/EFI/BOOT/bootx64.efi

Then use efibootmgr to create a boot entry in the UEFI NVRAM, where /dev/sdX and are the device and partition number of your EFI system partition. If you are installing rEFInd to the default/fallback boot path esp/EFI/BOOT/bootx64.efi, you can skip this step.

# efibootmgr --create --disk /dev/sdX --part Y --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --unicode

At this point, you should be able to reboot into rEFInd, but it will not be able to boot your kernel. If your kernel does not reside on your ESP, rEFInd can mount your partitions to find it - provided it has the right drivers.

rEFInd automatically loads all drivers from the subdirectories and drivers_arch (e.g. ) in its install directory.

# mkdir esp/EFI/refind/drivers_x64
# cp /usr/share/refind/drivers_x64/drivername_x64.efi esp/EFI/refind/drivers_x64/

Now rEFInd should have a boot entry for your kernel, but it will not pass the correct kernel parameters. Set up #Passing kernel parameters. You should now be able to boot your kernel using rEFInd. If you are still unable to boot or if you want to tweak rEFInd's settings, many options can be changed with a configuration file:

# cp /usr/share/refind/refind.conf-sample esp/EFI/refind/refind.conf

The sample configuration file is well commented and self-explanatory.

Unless you have set in the configuration file, you should copy rEFInd's icons to get rid of the ugly placeholders:

# cp -r /usr/share/refind/icons esp/EFI/refind/

You can try out different fonts by copying them and changing the setting in :

# cp -r /usr/share/refind/fonts esp/EFI/refind/

Upgrading

Pacman updates the rEFInd files in and will not copy new files to the ESP for you. If worked for your original installation of rEFInd, you can rerun it to copy the updated files. The new configuration file will be copied as so that you can integrate changes into your existing configuration file using a diff tool. If your rEFInd required #Manual installation, you will need to figure out which files to copy yourself.

Pacman hook

You can automate the update process using a pacman hook:

/etc/pacman.d/hooks/refind.hook
[Trigger]
Operation=Upgrade
Type=Package
Target=refind

[Action]
Description = Updating rEFInd on ESP
When=PostTransaction
Exec=/usr/bin/refind-install

Where the may need to be changed to the correct update command for your setup. If you did #Manual installation, you could create your own update script to call with the hook.

Configuration

The rEFInd configuration is located in the same directory as the rEFInd EFI application (usually esp/EFI/refind or ). The default configuration file contains extensive comments explaining all its options, see Configuring the Boot Manager for more detailed explanations.

Passing kernel parameters

There are two methods for setting the kernel parameters that rEFInd will pass to the kernel.

For kernels automatically detected by rEFInd

For automatically detected kernels you can either specify the kernel parameters explicitly in or rely on rEFInd's ability to identify the root partition and kernel parameters. See Methods of Booting Linux: For Those With Foresight or Luck: The Easiest Method for more information.

For rEFInd to support the naming scheme of Arch Linux kernels and thus allow matching them with their respective initramfs images, you must uncomment and edit option in . E.g.:

Note:
  • rEFInd only supports detecting one initramfs image per kernel, meaning it will not detect fallback initramfs nor microcode images. They must be specified manually.
  • Without the above extra_kernel_version_strings line, the %v variable in refind_linux.conf will not work for Arch Linux kernels.
refind_linux.conf

If rEFInd automatically detects your kernel, you can place a file containing the kernel parameters in the same directory as your kernel. You can use as a starting point. The first uncommented line of will be the default parameters for the kernel. Subsequent lines will create entries in a submenu accessible using , , or .

Alternatively, try running as root. It will attempt to find your kernel in and automatically generate . The script will only set up the most basic kernel parameters, so be sure to check the file it created for correctness.

If you do not specify an parameter, rEFInd will automatically add it by searching for common RAM disk filenames in the same directory as the kernel. If you need multiple parameters, you must specify them manually in . For example, a microcode passed before the initramfs:

/boot/refind_linux.conf
"Boot using default options"     "root=PARTUUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' rw add_efi_memmap initrd=boot\intel-ucode.img initrd=boot\amd-ucode.img initrd=boot\initramfs-%v.img"
"Boot using fallback initramfs"  "root=PARTUUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' rw add_efi_memmap initrd=boot\intel-ucode.img initrd=boot\amd-ucode.img initrd=boot\initramfs-%v-fallback.img"
"Boot to terminal"               "root=PARTUUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' rw add_efi_memmap initrd=boot\intel-ucode.img initrd=boot\amd-ucode.img initrd=boot\initramfs-%v.img systemd.unit=multi-user.target"
Without configuration

If you merely install rEFInd onto the ESP and launch it without any further ado (say via UEFI shell or KeyTool, or directly from firmware) you still get a menu to boot from via autodetection, with no configuration required whatsoever.

This works because rEFInd has a fallback mechanism that can:

For manual boot stanzas

If your kernel is not autodetected, or if you simply want more control over the options for a menu entry, you can manually create boot entries using stanzas in . Ensure that includes or these entries will not appear in rEFInd's menu. Kernel parameters are set with the keyword. rEFInd will append the parameter using the file specified by the keyword in the stanza. If you need additional initrds (e.g. for Microcode), you can specify them in (and the one specified by the keyword will be added to the end).

Manual boot stanzas are explained in Creating Manual Boot Stanzas.

''esp''/EFI/refind/refind.conf
...

menuentry "Arch Linux" {
	icon     /EFI/refind/icons/os_arch.png
	volume   "Arch Linux"
	loader   /boot/vmlinuz-linux
	initrd   /boot/initramfs-linux.img
	options  "root=PARTUUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' rw add_efi_memmap initrd=boot\intel-ucode.img initrd=boot\amd-ucode.img"
	submenuentry "Boot using fallback initramfs" {
		initrd /boot/initramfs-linux-fallback.img
	}
	submenuentry "Boot to terminal" {
		add_options "systemd.unit=multi-user.target"
	}
}

It is likely that you will need to change to match either a filesystem's LABEL, a PARTLABEL, or a PARTUUID of the partition where the kernel image resides. The PARTUUID needs to be in uppercase. See Persistent block device naming#by-label for examples of assigning a volume label. If is not specified it defaults to volume from which rEFInd was launched (typically EFI system partition).

Warning:
  • loader and initrd paths are relative to the root of volume. If /boot is a separate partition (e.g. the ESP), the loader and initrd paths would be /vmlinuz-linux and /initramfs-linux.img, respectively.
  • Use backslashes (\) as path separators in all quoted initrd parameters, otherwise the kernel may fail to find the initramfs image(s): EFI stub: ERROR: Failed to open file: /boot/initramfs-linux.img.
  • If using Booster generated initramfs images, replace initramfs with booster in the initramfs files name. E.g. initrd /boot/booster-linux.img.

Installation alongside an existing UEFI Windows installation

rEFInd is compatible with the EFI system partition created by a UEFI Windows installation, so there is no need to create or format another FAT32 partition when installing Arch alongside Windows. Simply mount the existing ESP and install rEFInd as usual. By default, rEFInd's autodetection feature should recognize any existing Windows/recovery bootloaders.

Tools

rEFInd supports running various 3rd-party tools. Tools need to be installed separately. Edit in to choose which ones to show.

UEFI shell

See Unified Extensible Firmware Interface#UEFI Shell.

Copy to the root of the EFI system partition.

Memtest86+

Install and copy it to esp/EFI/tools/.

# cp /boot/memtest86+/memtest.efi esp/EFI/tools/memtest86.efi

Key management tools

rEFInd can detect Secure Boot key management tools if they are placed in rEFInd's directory on ESP, or esp/EFI/tools/.

HashTool

Follow #Using PreLoader and will be placed in rEFInd's directory.

MokManager

Follow #Using shim and MokManager will be placed in rEFInd's directory.

KeyTool

Install .

Place KeyTool EFI binary in or esp/EFI/tools/ with the name KeyTool.efi or .

See Secure Boot#Using KeyTool for instructions on signing KeyTool.efi.

GPT fdisk (gdisk)

Download the gdisk EFI application and copy to esp/EFI/tools/.

fwupd

Install and setup fwupd.

Copy the binary and firmware file to esp/EFI/tools/:

# cp /usr/lib/fwupd/efi/fwupdx64.efi esp/EFI/tools/

Poweroff or reboot

rEFInd reportedly have poweroff and reboot menu entries built in. Since this list of tools is the most extensive of its kind in this wiki, users of UEFI shell, or other UEFI boot managers, such as systemd-boot, might be interested in .

Tips and tricks

Using drivers in UEFI shell

To use rEFInd's drivers in UEFI shell load them using command and refresh mapped drives with .

Shell> load FS0:\EFI\refind\drivers\ext4_x64.efi
Shell> map -r

Now you can access your file system from UEFI shell.

Setting efifb resolution

If the resolution in is set to an incorrect value, on all systems except Apple Macs rEFInd will display a list of supported resolutions. For Apple Macs it will silently use the default resolution.

To determine framebuffer resolutions supported by efifb, copy from to the root of ESP. Enter the UEFI shell and run modelist.efi.

Set one in . Reboot and check if settings has been applied by running as root.

Btrfs subvolume support

Warning: btrfs_x64.efi does not support raid1c3/4.

Auto detection

To allow kernel auto detection on a Btrfs subvolume uncomment and edit in .

Next add to in and then prepend to the initrd path.

/boot/refind_linux.conf
"Boot using standard options"  "root=PARTUUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' rw '''rootflags=subvol=''subvolume''''' initrd='''''subvolume'''''\boot\initramfs-%v.img"

Manual boot stanza

If booting a btrfs subvolume as root, prepend the path to the subvolume to the loader and initrd paths, and amend the line with . In the example below, root has been mounted as a btrfs subvolume called 'ROOT' (e.g. ):

''esp''/EFI/refind/refind.conf
...
menuentry "Arch Linux" {
        icon     /EFI/refind/icons/os_arch.png
        volume   "[bootdevice]"
        loader   '''/ROOT'''/boot/vmlinuz-linux
        initrd   '''/ROOT'''/boot/initramfs-linux.img
        options  "root=PARTUUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' rw '''rootflags=subvol=ROOT'''"
...
}

A failure to do so will otherwise result in the following error message:

LoaderDevicePartUUID

Since version 0.13.1, rEFInd supports setting the UEFI variable LoaderDevicePartUUID. Enabling this allows to automount the EFI system partition without needing to specify it in /etc/fstab. See systemd#GPT partition automounting.

For rEFInd to set , edit and uncomment :

You can verify if it is set by checking its value with or by looking at the state of "Boot loader sets ESP information" in output.

Troubleshooting

Apple Macs

is an experimental bless utility for Linux. If that does not work, use bless from within OSX to set rEFInd as the default boot entry:
# bless --setBoot --folder esp/EFI/refind --file esp/EFI/refind/refind_x64.efi

Blank rEFInd menu screen

If your folder contains multiple file system drivers (see #Installing the rEFInd Boot Manager for clarification), this can lead to an improper functioning of rEFInd through a file system driver bug, whereby only a blank screen and with the rEFInd logo is shown (for custom themes, this would be the set background image). To fix this, simply remove all drivers except the one for the file system on which the kernel resides.

Another potential blank screen cause occurs when dual booting with Windows, where rEFInd is unsuccessful in auto-scanning the EFI system partitions on other disks. To remedy this, use blkid to identify Windows partitions, and add the PARTUUID of each Windows partition as a comma-separated entry to the variable dont_scan_volumes in . For example:

''esp''/EFI/refind/refind.conf
...
dont_scan_volumes 13aa9955-1234-5678-9098-006c334b5088,4eced110-0987-6543-2123-b0ab8576869b
...

If you see Tux instead of the Arch Logo, then you might be affected by this issue (your root partition is of type Linux x86-64 root (/) instead of Linux filesystem).

You can fix this using fdisk#Change partition type.

gollark: Yes, thus back up to multiple places.
gollark: I am aware of this, although I don't think this is particularly useful compared to just backing up to AWS Glacier and whatever.
gollark: Actually, I could do it once on the short video and concat it 2770 times, that might work.
gollark: Good* reasons. And I'm aware of better codecs, but actually reencoding it would burn my CPU.
gollark: Anyone know about video file meddling? I want to upload a 10 hour loop of a 13 second video to YouTube, but just concatenating it 2770 times with `ffmpeg` produced a 3GB file before I ran out of /tmp space, so can I just edit the headers somehow to make stuff *play* it as if it's 10 hours?

See also

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.