Difference between revisions of "Unified Extensible Firmware Interface"
Alex Yursha (talk | contribs) |
(→Create UEFI bootable USB from ISO: (reverses edit 257343 by Earnest)) |
||
Line 443: | Line 443: | ||
* Then create a FAT32 filesystem in the partition on the USB (unmount before if necessary) with LABEL as used in the Archiso configuration. Obtain the label from {{ic|/mnt/iso/loader/entries/archiso-x86_64.conf}}; this is used by the {{ic|archiso}} hook in initramfs to identify the udev path to the installation media. {{ic|mkfs.vfat}} is part of package {{Pkg|dosfstools}}. {{Note|The filesystem should be either FAT32 (recommended), FAT16, or FAT12.}} | * Then create a FAT32 filesystem in the partition on the USB (unmount before if necessary) with LABEL as used in the Archiso configuration. Obtain the label from {{ic|/mnt/iso/loader/entries/archiso-x86_64.conf}}; this is used by the {{ic|archiso}} hook in initramfs to identify the udev path to the installation media. {{ic|mkfs.vfat}} is part of package {{Pkg|dosfstools}}. {{Note|The filesystem should be either FAT32 (recommended), FAT16, or FAT12.}} | ||
− | + | # awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n | |
* Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media. | * Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media. |
Revision as of 14:10, 29 July 2013
zh-CN:Unified Extensible Firmware Interface Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end
Unified Extensible Firmware Interface (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.
Contents
- 1 Booting an OS using BIOS
- 2 Booting an OS using UEFI
- 3 Boot Process under UEFI
- 4 Detecting UEFI Firmware Arch
- 5 UEFI Support in Linux Kernel
- 6 UEFI Variables Support
- 7 Linux Bootloaders for UEFI
- 8 EFI System Partition
- 9 UEFI Shell
- 10 Hardware Compatibility
- 11 Create UEFI bootable USB from ISO
- 12 Remove UEFI boot support from ISO
- 13 QEMU with OVMF
- 14 Troubleshooting
- 15 See also
Booting an OS using BIOS
A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware has been initialized and the POST operation has completed, the BIOS executes the first boot code in the first device in the device booting list.
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.
Multiboot on BIOS
Since very little can be achieved by a program that fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like GRUB or Syslinux or LILO would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.
Booting an OS using UEFI
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems.
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called EFI SYSTEM PARTITION in which files required to be launched by the firmware are stored. Each vendor can store its files under <EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/
folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.
<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi
(for 64-bit x86 system)Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a UEFI Application corresponding to the EFI firmware architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use i386 EFI are older (pre 2008) Apple Macs.
An x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike x86_64 Linux and Windows versions which include such support. Therefore the bootloader must be compiled for that specific architecture.
Multibooting on UEFI
Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.
Multibooting Windows and Linux
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using UEFI firmware. These Windows versions support either UEFI-GPT booting or BIOS-MBR booting. 32-bit Windows versions only support BIOS-MBR booting. See http://support.microsoft.com/kb/2581408 for more info.
This limitation does not exist in Linux Kernel but rather depends on the bootloader used. For the sake of Windows UEFI booting, the Linux bootloader used should also be installed in UEFI-GPT mode if booting from the same disk.
Unified_Extensible_Firmware_Interface#Windows_7_won.27t_boot_in_UEFI_Mode
Boot Process under UEFI
- System switched on - Power On Self Test, or POST process.
- UEFI firmware is loaded.
- Firmware reads its Boot Manager to determine which UEFI application to be launched and from where (ie. from which disk and partition).
- Firmware launches the UEFI application from the FAT32 formatted UEFISYS partition as defined in the boot entry in the firmware's boot manager.
- UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a bootloader like GRUB) depending on how the UEFI application was configured.
Detecting UEFI Firmware Arch
If you have a non-Mac UEFI system, then you most likely have a x86_64 (aka 64-bit) UEFI 2.x firmware. A few known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio and Insyde H2O.
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.
To find out the arch of the efi firmware in a Mac, type the following into the terminal:
ioreg -l -p IODeviceTree | grep firmware-abi
If the command returns EFI32 then it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI Specification.
UEFI Support in Linux Kernel
Linux Kernel config options for UEFI
The required Linux Kernel configuration options for UEFI systems are :
CONFIG_RELOCATABLE=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_FB_EFI=y CONFIG_FRAMEBUFFER_CONSOLE=y
UEFI Runtime Variables Support (efivarfs filesystem - /sys/firmware/efi/efivars
). This option is important as this is required to manipulate UEFI Runtime Variables using tools like /usr/bin/gummiboot
. Efivarfs is recommended over efivars sysfs interface (described below). The below config option has been added in kernel 3.10 and above.
CONFIG_EFIVAR_FS=y
UEFI Runtime Variables Support (efivars sysfs interface - /sys/firmware/efi/vars
). This option is important as this is required to manipulate UEFI Runtime Variables using tools like efibootmgr
.
CONFIG_EFI_VARS=m CONFIG_EFI_VARS_PSTORE=m CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y
GUID Partition Table GPT config option - mandatory for UEFI support
CONFIG_EFI_PARTITION=y
Retrieved from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD .
UEFI Variables Support
UEFI defines variables through which an operating system can interact with the firmware. UEFI Boot Variables are used by the boot-loader and used by the OS only for early system start-up. UEFI Runtime Variables allow an OS to manage certain settings of the firmware like the UEFI Boot Manager or managing the keys for UEFI Secure Boot Protocol etc.
Access to UEFI Runtime services is provided by "efivars" kernel module which is enabled through the CONFIG_EFI_VARS=y
kernel config option. This module exposes the variables under the directory /sys/firmware/efi/vars
(for kernels >=3.8 through /sys/firmware/efi/efivars
). One way to check whether the system has booted in UEFI boot mode is to check for the existence of /sys/firmware/efi/vars
(and in kernels >=3.8 for /sys/firmware/efi/efivars
)directory with contents similar to :
Sample output (Lenovo Thinkpad E430, UEFI 2.3.1, x86_64 firmware, efivarfs dump):
# ls -1 /sys/firmware/efi/efivars AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e BGRTLogoIndex-9da5909e-ef5e-4851-8715-bf9e22b7a600 BmEssentialVariableNames-0b7646a4-6b44-4332-8588-c8998117f2ef Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0006-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0007-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0008-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0009-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot000A-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot000B-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot000C-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot000D-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot000E-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot000F-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0010-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0011-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0012-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0013-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0014-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0015-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0016-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0017-8be4df61-93ca-11d2-aa0d-00e098032b8c Boot0018-8be4df61-93ca-11d2-aa0d-00e098032b8c BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c BootOrderDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c BuildDate-e5bbf7be-2417-499b-97db-39f4896391bc BuildTime-e5bbf7be-2417-499b-97db-39f4896391bc ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c CpuProtocolSetupVar-7d4adce1-930d-40c7-9cd2-6d2148413dc7 db-d719b2cb-3d3a-4596-a3bc-dad00e67656f dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f DIAGSPLSHSCRN-8be4df61-93ca-11d2-aa0d-00e098032b8c DptfProtocolSetupVar-1054354b-b543-4dfe-558b-a7ad6351c9d8 ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c FirmwarePerformanceDataTable-9dab39a4-3f8a-47ac-80c3-400729332c81 HDDPWD-8be4df61-93ca-11d2-aa0d-00e098032b8c iFfsData-f9f0b131-f346-4f16-80dd-f941072b3a7d KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0000-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0001-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0002-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0003-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0004-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0005-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0006-8be4df61-93ca-11d2-aa0d-00e098032b8c LastBootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c LBC-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBL-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOL-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0001-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0002-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0003-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0004-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0005-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0006-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0007-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0008-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0009-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP000A-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP000B-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP000C-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP000D-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP000E-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP000F-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0010-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0011-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0012-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0013-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0014-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0015-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0016-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0017-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LBOP0018-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LenovoConfig-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LenovoFlashScratch1-67c3208e-4fcb-498f-9729-0760bb4109a7 LenovoHiddenSetting-1827cfc7-4e61-4273-b796-d35f4b0c88fc LenovoScratchData-67c3208e-4fcb-498f-9729-0760bb4109a7 LenovoSecurityConfig-a2c1808f-0d4f-4cc9-a619-d1e641d39d49 LenovoSystemConfig-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LKOP0000-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LKOP0001-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LKOP0002-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LKOP0003-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LKOP0004-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LKOP0005-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LKOP0006-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 LoaderDeviceIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderEntriesAuto-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderEntrySelected-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderFirmwareInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderFirmwareType-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderImageIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderTimeExecUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderTimeInitUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LoaderTimeMenuUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f LocalSecurityVars-47355e9f-0857-45e1-8a6f-a4f5eda89a77 LWO-2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65 MailBoxQ-67c3208e-4fcb-498f-9729-0760bb4109a7 MeBiosExtensionSetup-1bad711c-d451-4241-b1f3-8537812e0c70 MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa MemoryTypeInformationBackup-4c19049f-4137-4dd3-9c10-8b97a83ffdfa MemRestoreVariable-608dc793-15de-4a7f-a0c5-6c29beaf5d23 MTC-eb704011-1402-11d3-8e77-00a0c969723b OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c PbaStatusVar-0ec1a7f5-4904-40a0-8eab-4bcc4666da45 PchInit-e6c2f70a-b604-4877-85ba-deec89e117eb PchS3Peim-e6c2f70a-b604-4877-85ba-deec89e117eb PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c PlatformOpRomSetup-65827a61-99e2-4f07-a7aa-0b1f98edad39 ProtectedBootOptions-8be4df61-93ca-11d2-aa0d-00e098032b8c PwdStatusVar-3e72b3ad-2b91-424a-ad73-c3270e91ed88 SaPegData-c4975200-64f1-4fb6-9773-f6a9f89d985e SaPpiSetupVar-7da81437-866b-4143-8e08-a25c6ef0fa5b SaProtocolSetupVar-34f73d4d-963e-4c65-b3b3-515e720175d6 SctHotkey-4650c401-93f1-4aeb-b87d-c8204c047dec SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c SecureBootOption-955b9041-133a-4bcf-90d1-97e1693c0e30 Setup-4dfbbaab-1392-4fde-abb8-c41cc5ad7d5d SetupHotKey-8be4df61-93ca-11d2-aa0d-00e098032b8c SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c SimpleBootFlag-8be4df61-93ca-11d2-aa0d-00e098032b8c SMBIOSELOG000-c3eeae98-23bf-412b-ab60-efcbb48e1534 SMBIOSELOGNUMBER-c3eeae98-23bf-412b-ab60-efcbb48e1534 SMBIOSMEMSIZE-c3eeae98-23bf-412b-ab60-efcbb48e1534 TcgSetup-753ab903-444c-41f8-a235-569e8341147e Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c TpmAcpiData-6403753b-abde-4da2-aa11-6983ef2a7a69 TpmSaveState-5e724c0c-5c03-4543-bcb6-c1e23de24136
The UEFI Runtime Variables will not be exposed to the OS if you have used "noefi" kernel parameter in the boot-loader menu. This parameter instructs the kernel to completely ignore UEFI Runtime Services.
Userspace Tools
There are few tools that can access/modify the UEFI variables, namely
- efibootmgr - Tool to manipulate UEFI Firmware Boot Manager Settings (supports only sysfs-efivars currently) - efibootmgr or efibootmgr-gitAUR
- efivar - Library and Tool to manipulate UEFI Variables (supports both efivarfs and sysfs-efivars) - efivar or efivar-gitAUR
- efitools - Tools to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - efitools-gitAUR
- uefivars - simply dumps list of EFI variables with some additional info - uses efibootmgr code internally - uefivars-gitAUR
- Ubuntu's Firmware Test Suite - to run some firmware related tests, includes efi variables test code - fwtsAUR or fwts-gitAUR
Non-Mac UEFI systems
efibootmgr
efibootmgr
in Apple Macs will brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - mactel-bootAUR.efibootmgr
command will work only if you have booted the system in UEFI mode itself, since it requires access to UEFI Runtime Variables which are available only in UEFI boot mode (with "noefi" kernel parameter NOT being used). Otherwise the message Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables
is shown.efibootmgr
, some UEFI BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI system partition and manually enter the EFI stub location. (for example '\EFI\refind\refind_x64.efi')efibootmgr
fails to create the boot entry, check for existence of /sys/firmware/efi/efivars/dump-*
files, if they exist, delete them, reboot and retry efibootmgr
again. If even this fails, retry efibootmgr
after booting with efi_no_storage_paranoia
kernel parameter.efibootmgr
completely fails to work in your system, you can reboot into UEFI Shell v2 and use bcfg
command to create a boot entry for the bootloader.Initially the user may be required to manually launch the boot-loader from the firmware itself (using maybe the UEFI Shell) if the UEFI boot-loader was installed when the system is booted in BIOS mode. Then efibootmgr
should be run to make the UEFI boot-loader entry as the default entry in the UEFI Boot Manager.
To use efibootmgr, first load the 'efivars' kernel module (if compiled as a external module):
# modprobe efivars
If you get no such device found error for this command, that means you have not booted in UEFI mode or due to some reason the kernel is unable to access UEFI Runtime Variables (noefi?).
Verify whether there are files in /sys/firmware/efi/vars/ (and /sys/firmware/efi/efivars/ for kernel >=3.8) directory. This directory and its contents are created by "efivars" kernel module and it will exist only if you have booted in UEFI mode, without the "noefi" kernel parameter.
If /sys/firmware/efi/vars/ directory is empty or does not exist, then efibootmgr
command will not work. If you are unable to make the ISO/CD/DVD/USB boot in UEFI mode try #Create_UEFI_bootable_USB_from_ISO.
Assume the boot-loader file to be launched is /boot/efi/EFI/refind/refind_x64.efi
. /boot/efi/EFI/refind/refind_x64.efi
can be split up as /boot/efi
and /EFI/refind/refind_x64.efi
, wherein /boot/efi
is the mountpoint of the EFI System Partition, which is assumed to be /dev/sdXY
(here X and Y are just placeholders for the actual values - eg:- in /dev/sda1
, X=a Y=1).
To determine the actual device path for the UEFI System Partition (should be in the form /dev/sdXY
), try :
# findmnt /boot/efi TARGET SOURCE FSTYPE OPTIONS /boot/efi /dev/sdXY vfat rw,flush,tz=UTC
Then create the boot entry using efibootmgr as follows :
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"
\
as path separator (similar to Windows paths), but the efibootmgr-0.6.0-3 and above pkgs support passing unix-style paths with forward-slash /
as path-separator for the -l
option. Efibootmgr internally converts /
to \
before encoding the loader path. The relevant commit that added this feature to efibootmgr is http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .In the above command /boot/efi/EFI/refind/refind_x64.efi
translates to /boot/efi
and /EFI/refind/refind_x64.efi
which in turn translate to drive /dev/sdX
-> partition Y
-> file /EFI/refind/refind_x64.efi
.
The 'label' is the name of the menu entry shown in the UEFI boot menu. This name is user's choice and does not affect the booting of the system. More info can be obtained from efibootmgr GIT README .
FAT32 filesystem is case-insensitive since it does not use UTF-8 encoding by default. In that case the firmware uses capital 'EFI' instead of small 'efi', therefore using \EFI\refind\refindx64.efi
or \efi\refind\refind_x64.efi
does not matter (this will change if the filesystem encoding is UTF-8).
Linux Bootloaders for UEFI
See UEFI Bootloaders.
EFI System Partition
The EFI System Partition needs to be formatted with a FAT32 filesystem (non-FAT filesystems like ext2/3/4, reiserfs, NTFS, UDF etc. are not supported). Although ESPs with size >=100 MiB and formatted as FAT32 are allowed by Microsoft Windows and many Linux distros, Microsoft documentation specifies that the minimum partition/volume size for FAT32 is 512 MiB. Therefore an ESP should be at least 512 MiB size for maximum compatibility. If you are using Linux EFISTUB booting, then you need to make sure there is adequate space available for keeping the Kernel and Initramfs files in the ESP.
It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.
For GPT partitioned disks
Two choices:
- Using GNU Parted/GParted: Create a FAT32 partition. Set "boot" flag on for that partition.
- Using GPT fdisk (aka gdisk): Create a partition with partition type
ef00
. Then format that partition as FAT32 usingmkfs.vfat -F32 /dev/<THAT_PARTITION>
For MBR partitioned disks
Two choices:
- Using GNU Parted/GParted: Create FAT32 partition. Change the type code of that partition to
0xEF
using fdisk, cfdisk or sfdisk. - Using fdisk: Create a partition with partition type
0xEF
. Then format that partition as FAT32 usingmkfs.vfat -F32 /dev/<THAT_PARTITION>
UEFI Shell
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc.
UEFI Shell download links
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project.
- AUR uefi-shell-svnAUR pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source
- Precompiled x86_64 UEFI Shell v2 binary (may not be up-to-date)
- Precompiled x86_64 UEFI Shell v1 binary (not updated anymore upstream)
- Precompiled IA32 UEFI Shell v2 binary (may not be up-to-date)
- Precompiled IA32 UEFI Shell v1 binary (not updated anymore upstream)
Shell v2 works best in UEFI 2.3+ systems and is recommended over Shell v1 in those systems. Shell v1 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at ShellPkg and this mail
Launching UEFI Shell
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called "Launch EFI Shell from filesystem device"
. For those motherboards, download the x86_64 UEFI Shell and copy it to your UEFI SYSTEM PARTITION as <UEFI_SYSTEM_PARTITION>/shellx64.efi
(mostly /boot/efi/shellx64.efi
) .
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key.
Important UEFI Shell Commands
UEFI Shell commands usually support -b
option which makes output pause after each page. map
lists recognized filesystems (fs0
, ...) and data storage devices (blk0
, ...). Run help -b
to list available commands.
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/
bcfg
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" pdf document.
bcfg
only if efibootmgr
fails to create working boot entries in their system.bcfg
command. You can download a modified UEFI Shell v2 binary which may work in UEFI pre-2.3 firmwares.To dump a list of current boot entries -
Shell> bcfg boot dump -v
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"
where fs0: is the mapping corresponding to the UEFI System Partition and fs0:\EFI\refind\refind_x64.efi is the file to be launched.
To remove the 4th boot option
Shell> bcfg boot rm 3
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu)
Shell> bcfg boot mv 3 0
For bcfg help text
Shell> help bcfg -v -b
or
Shell> bcfg -? -v -b
edit
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.
To edit, for example rEFInd's refind.conf in the UEFI System Partition (fs0: in the firmware)
Shell> fs0: FS0:\> cd \EFI\arch\refind FS0:\EFI\arch\refind\> edit refind.conf
Type Ctrl-E
for help.
Hardware Compatibility
Main page HCL/Firmwares/UEFI
Create UEFI bootable USB from ISO
- First create either a MBR or GPT (recommended) partition table and at least one partition in the USB (so it is fine to use an already partitioned USB). Note: Using a GPT partition table is recommended as some firmwares don't support booting from MBR devices in full UEFI mode (e.g. Gigabyte).
- Mount the ISO image from the Arch Linux download page.
# mkdir -p /mnt/{usb,iso} # mount -o loop archlinux-2013.06.01-dual.iso /mnt/iso
- Then create a FAT32 filesystem in the partition on the USB (unmount before if necessary) with LABEL as used in the Archiso configuration. Obtain the label from
/mnt/iso/loader/entries/archiso-x86_64.conf
; this is used by thearchiso
hook in initramfs to identify the udev path to the installation media.mkfs.vfat
is part of package dosfstools.Note: The filesystem should be either FAT32 (recommended), FAT16, or FAT12.
- awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n
- Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.
# mount /dev/sdXY /mnt/usb # cp -a /mnt/iso/* /mnt/usb # sync # umount /mnt/{usb,iso}
Fixing errors
If you find the error: "No loader found. Configuration files in /loader/entries/*.conf are needed." First, try to convert filenames in /loader/entries/ to lower case. A possible fix is to use a different uefi bootloader to the included one, gummiboot.
Download refind-efi pkg and extract the file /usr/lib/refind/refind_x64.efi
from within the package to (USB)/EFI/boot/bootx64.efi
(overwrite or rename any existing (USB)/EFI/boot/bootx64.efi
file).
Then copy this text to EFI/boot/refind.conf
. Take care that the label in the Arch menu section (ARCH_201304
here) matches that of your usb's.
refind.conf
timeout 5 textonly showtools about,reboot,shutdown,exit # scan_driver_dirs EFI/tools/drivers_x64 scanfor manual,internal,external,optical scan_delay 1 dont_scan_dirs EFI/boot max_tags 0 default_selection "Arch Linux Archiso x86_64 UEFI USB" menuentry "Arch Linux Archiso x86_64 UEFI USB" { loader /arch/boot/x86_64/vmlinuz initrd /arch/boot/x86_64/archiso.img ostype Linux graphics off options "archisobasedir=arch archisolabel=ARCH_201304 add_efi_memmap" } menuentry "UEFI x86_64 Shell v2" { loader /EFI/shellx64_v2.efi graphics off } menuentry "UEFI x86_64 Shell v1" { loader /EFI/shellx64_v1.efi graphics off }
You should now be able to successfully boot, and you can choose which EFI you'd like to load.
Remove UEFI boot support from ISO
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.
Mount the official installation media and obtain the archisolabel
as shown in the previous section.
Rebuild the ISO using xorriso
from libisoburn:
$ xorriso -as mkisofs -iso-level 3 \ -full-iso9660-filenames\ -volid "ARCH_201212" \ -appid "Arch Linux CD" \ -publisher "Arch Linux <https://www.archlinux.org>" \ -preparer "prepared like a BAWSE" \ -eltorito-boot isolinux/isolinux.bin \ -eltorito-catalog isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \ -output "~/archiso.iso" "/mnt/iso/"
Burn ~/archiso.iso
to optical media and proceed with installation normally.
QEMU with OVMF
OVMF [1] is a project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU and KVM.
You can build OVMF (with Secure Boot support) from AUR ovmf-svnAUR and run it as follows:
qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin
Troubleshooting
Windows 7 won't boot in UEFI Mode
If you have installed Windows to a different harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows won't boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.
Mainboards with this kind of problem:
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)
- UEFI BIOS option for booting UEFI Only doesn't pretend the UEFI BIOS from starting CSM
See also
- Wikipedia's page on UEFI
- Wikipedia's page on UEFI SYSTEM Partition
- Linux Kernel UEFI Documentation
- UEFI Forum - contains the official UEFI Specifications - GUID Partition Table is part of UEFI Specification
- Intel's Tianocore Project for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox
- Intel's page on EFI
- FGA: The EFI boot process
- Microsoft's Windows and GPT FAQ - Contains info on Windows UEFI booting also
- Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall
- Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive
- Rod Smith - A BIOS to UEFI Transformation
- UEFI Boot problems on some newer machines (LKML)
- EFI Shells and Scripting - Intel Documentation
- UEFI Shell - Intel Documentation
- UEFI Shell - bcfg command info
- UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot
- LPC 2012 Plumbing UEFI into Linux
- LPC 2012 UEFI Tutorial : part 1
- LPC 2012 UEFI Tutorial : part 2