Difference between revisions of "Unified Extensible Firmware Interface"
m (→Inconsistency between efivarfs and sysfs-efivars) |
m (→Inconsistency between efivarfs and sysfs-efivars) |
||
Line 302: | Line 302: | ||
==== Switch to efivarfs ==== | ==== Switch to efivarfs ==== | ||
− | {{Note|The below commands should be BEFORE '''chroot''', if any.}} | + | {{Note|The below commands should be run BEFORE '''chroot''', if any.}} |
# umount /sys/firmware/efi/efivars | # umount /sys/firmware/efi/efivars | ||
Line 314: | Line 314: | ||
==== Switch to sysfs-efivars ==== | ==== Switch to sysfs-efivars ==== | ||
− | {{Note|The below commands should be BEFORE '''chroot''', if any.}} | + | {{Note|The below commands should be run BEFORE '''chroot''', if any.}} |
# umount /sys/firmware/efi/efivars | # umount /sys/firmware/efi/efivars |
Revision as of 14:03, 25 August 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.
Before understanding UEFI, it is important to understand how the pre-UEFI (BIOS) systems boot. This is explained in subsequent sections.
Contents
BIOS
A BIOS or Basic Input-Output System is the very first program (firmware) that is executed once the system is switched on. In most cases it is stored in a flash memory in the motherboard itself and independent of the system storage.
Boot Process under BIOS
- System switched on - Power On Self Test, or POST process
- After POST BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.)
- BIOS launches the first 440 bytes (MBR boot code region) of the first disk in the BIOS disk order
- The MBR boot code then takes control from BIOS and launches its next stage code (if any) (mostly bootloader code)
- The launched (2nd stage) code (actual bootloader) then reads its support and config files
- Based on the data in its config files, the bootloader loads the kernel and initramfs into system memory (RAM) and launches the kernel
Multibooting in 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.
UEFI
UEFI has support for reading both the partition table as well as understanding filesystems. Hence it is not limited by 440 byte code limitation (MBR boot code) as in BIOS systems. It does not use the MBR boot code at all.
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.
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 bitness/architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use IA32 (32-bit) EFI are older (pre 2008) Apple Macs, some recent Intel Cloverfield ultrabooks and some older Intel Server boards are known to operate on Intel EFI 1.10 firmware
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 UEFI application must be compiled for that specific firmware processor bitness/architecture.
Boot Process under UEFI
- System switched on - Power On Self Test, or POST process.
- UEFI firmware is loaded. Firmware initializes the hardware required for booting.
- Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).
- Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.
- The launched 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.
<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi
(for 64-bit x86 system)Multibooting in 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.
Booting Microsoft Windows
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot.
This limitation is not enforced by Linux kernel itself, but rather depends on how the bootloader is configured. However this Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case of Windows and Linux dual boot in the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases. versions use the type of partition table do determine the boot method, and thus support either UEFI-GPT booting or BIOS-MBR booting.
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk can use only MBR. See http://support.microsoft.com/kb/2581408 for more info.
Detecting UEFI Firmware bitness
Non Macs
Check whether the dir /sys/firmware/efi
exists, if it exists it means the kernel has booted in EFI mode. In that case the UEFI bitness is same as kernel bitness. (ie. i686 or x86_64)
Apple Macs
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 Mac OS X terminal:
ioreg -l -p IODeviceTree | grep firmware-abi
If the command returns EFI32 then it is IA32 (32-bit) EFI firmware. If it returns EFI64 then it is x86_64 EFI firmware. Most of the Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI 2.x Specification.
UEFI Variables
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.
Sample List of UEFI Variables
Sample list of UEFI Variables in a Lenovo Thinkpad E430 3254-DAQ (UEFI 2.3.1, x86_64 firmware, Secure Boot support present):
UEFI Variables List
$ efivar -l 0b7646a4-6b44-4332-8588-c8998117f2ef-BmEssentialVariableNames 0ec1a7f5-4904-40a0-8eab-4bcc4666da45-PbaStatusVar 1054354b-b543-4dfe-558b-a7ad6351c9d8-DptfProtocolSetupVar 1827cfc7-4e61-4273-b796-d35f4b0c88fc-LenovoHiddenSetting 1bad711c-d451-4241-b1f3-8537812e0c70-MeBiosExtensionSetup 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBC 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBL 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOL 2a4dc6b7-41f5-45dd-b46f-2dd334c1cf65-LBOP0000 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-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-LWO 34f73d4d-963e-4c65-b3b3-515e720175d6-SaProtocolSetupVar 3e72b3ad-2b91-424a-ad73-c3270e91ed88-PwdStatusVar 4650c401-93f1-4aeb-b87d-c8204c047dec-SctHotkey 47355e9f-0857-45e1-8a6f-a4f5eda89a77-LocalSecurityVars 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-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 4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformation 4c19049f-4137-4dd3-9c10-8b97a83ffdfa-MemoryTypeInformationBackup 4dfbbaab-1392-4fde-abb8-c41cc5ad7d5d-Setup 5e724c0c-5c03-4543-bcb6-c1e23de24136-TpmSaveState 608dc793-15de-4a7f-a0c5-6c29beaf5d23-MemRestoreVariable 6403753b-abde-4da2-aa11-6983ef2a7a69-TpmAcpiData 65827a61-99e2-4f07-a7aa-0b1f98edad39-PlatformOpRomSetup 67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoFlashScratch1 67c3208e-4fcb-498f-9729-0760bb4109a7-LenovoScratchData 67c3208e-4fcb-498f-9729-0760bb4109a7-MailBoxQ 753ab903-444c-41f8-a235-569e8341147e-TcgSetup 7d4adce1-930d-40c7-9cd2-6d2148413dc7-CpuProtocolSetupVar 7da81437-866b-4143-8e08-a25c6ef0fa5b-SaPpiSetupVar 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000 8be4df61-93ca-11d2-aa0d-00e098032b8c-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-ConIn 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConInDev 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOutDev 8be4df61-93ca-11d2-aa0d-00e098032b8c-DIAGSPLSHSCRN 8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOutDev 8be4df61-93ca-11d2-aa0d-00e098032b8c-HDDPWD 8be4df61-93ca-11d2-aa0d-00e098032b8c-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-OsIndications 8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported 8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang 8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes 8be4df61-93ca-11d2-aa0d-00e098032b8c-ProtectedBootOptions 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupHotKey 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode 8be4df61-93ca-11d2-aa0d-00e098032b8c-SimpleBootFlag 8be4df61-93ca-11d2-aa0d-00e098032b8c-Timeout 955b9041-133a-4bcf-90d1-97e1693c0e30-IEIT 955b9041-133a-4bcf-90d1-97e1693c0e30-SecureBootOption 9da5909e-ef5e-4851-8715-bf9e22b7a600-BGRTLogoIndex 9dab39a4-3f8a-47ac-80c3-400729332c81-FirmwarePerformanceDataTable a2c1808f-0d4f-4cc9-a619-d1e641d39d49-LenovoSecurityConfig af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e-AcpiGlobalVariable c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOG000 c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSELOGNUMBER c3eeae98-23bf-412b-ab60-efcbb48e1534-SMBIOSMEMSIZE c4975200-64f1-4fb6-9773-f6a9f89d985e-SaPegData d719b2cb-3d3a-4596-a3bc-dad00e67656f-db d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx e5bbf7be-2417-499b-97db-39f4896391bc-BuildDate e5bbf7be-2417-499b-97db-39f4896391bc-BuildTime e6c2f70a-b604-4877-85ba-deec89e117eb-PchInit e6c2f70a-b604-4877-85ba-deec89e117eb-PchS3Peim eb704011-1402-11d3-8e77-00a0c969723b-MTC f9f0b131-f346-4f16-80dd-f941072b3a7d-iFfsData
Linux Kernel UEFI Support
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 in Kernel
Linux kernel exposes EFI variables data to userspace via 2 interfaces:
- sysfs-efivars (efivars kernel module, /sys/firmware/efi/vars) which is not recommended by kernel devs
- efivarfs (efivarfs kernel module, /sys/firmware/efi/efivars) that was designed to overcome the limitations of sysfs-efivars interface
efivarfs was introduced in kernel 3.8 and most of its bugs were ironed out in kernel 3.10 . Subsequently until kernel 3.9.X, sysfs-efivars was built-in in the Arch's core/linux kernel. However since core/linux 3.10 efivarfs is built-in and efivars is again a separate module.
Gummiboot (/usr/bin/gummiboot), systemd, and all tools that modify UEFI Secure Boot functions use only efivarfs. As of 2013-08, it seems that only efibootmgr uses sysfs-efivars. Running both sysfs-efivars and efivarfs can create inconsistencies in EFI variables data in the kernel and is discouraged. Going forward efivarfs is the recommended way for tools to interact with kernel reg EFI variables.
Requirements for UEFI Variables support to work properly
- EFI Runtime Services support should be present in the kernel (CONFIG_EFI=y).
- Kernel processor bitness/arch and EFI processor bitness/arch should match.
- Kernel should be booted in EFI mode (via EFISTUB or any EFI bootloader, not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM)
- EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. "noefi" kernel parameter SHOULD NOT be used.
- If any userspace tool is unable to modify efi variables data, check for existence of
/sys/firmware/efi/efivars/dump-*
files. If they exist, delete them, reboot and retry again. - If the above step does not fix the issue, try booting with
efi_no_storage_paranoia
kernel parameter to disable kernel efi variable storage space check that may prevent writing/modification of efi variables.
efi_no_storage_paranoia
should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full.Inconsistency between efivarfs and sysfs-efivars
Both sysfs-efivars and efivarfs can run simultaneously, but this can cause inconsistency between sysfs-efivars data and efivarfs data, especially if data in both are simultaneously modified. See https://lkml.org/lkml/2013/4/16/473 for more info. Therefore it is advisable to use enable only one interface at a time and disable the other one.
Switch to efivarfs
# umount /sys/firmware/efi/efivars # modprobe -r efivars
# modprobe efivarfs # mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Verify that there are files in /sys/firmware/efi/efivars/
directory. If not, check whether all the conditions in #Requirements_for_UEFI_Variables_support_to_work_properly are met.
Switch to sysfs-efivars
# umount /sys/firmware/efi/efivars # modprobe -r efivars
# modprobe efivars
Verify that there are files/directories within /sys/firmware/efi/vars/
directory. If not, check whether all the conditions in #Requirements_for_UEFI_Variables_support_to_work_properly are met.
Userspace Tools
Supporting both efivarfs and sysfs-efivars
There are few tools that can access/modify the UEFI variables, namely
- efivar - Library and Tool to manipulate UEFI Variables (supports both efivarfs and sysfs-efivars) - efivar or efivar-gitAUR
Supporting efivarfs only
- efitools - Tools to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - efitools-gitAUR
Supporting sysfs-efivars only
- efibootmgr - Tool to manipulate UEFI Firmware Boot Manager Settings (supports only sysfs-efivars currently) - efibootmgr or efibootmgr-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
efibootmgr
efibootmgr
in Apple Macs may 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
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.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')To use efibootmgr, first switch to sysfs-efivars interface (do this always, to prevent inconsistency between efivarfs and sysfs-efivars data so that the firmware does not get confused)
Assuming 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).
UEFI Bootloaders
See UEFI Bootloaders for the main article.
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.
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>
If you get the message WARNING: Not enough clusters for a 32 bit FAT!
, reduce cluster size with mkfs.vfat -s2 -F32 ...
or -s1
, otherwise the partition may be unreadable by UEFI.
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.
Obtaining UEFI Shell
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.
UEFI Linux Hardware Compatibility
See HCL/Firmwares/UEFI for the main article.
UEFI Bootable Media
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}
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.
Testing UEFI in systems without native support
OVMF for Virtual Machines
OVMF [1] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.
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
DUET for BIOS only systems
DUET is a tianocore project that enables chainloading a full UEFI environment from a BIOS system, in a way similar to BIOS OS booting. This method is being discussed extensively in http://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/ . Pre-build DUET images can be downloaded from one of the repos at https://gitorious.org/tianocore_uefi_duet_builds . Specific instructions for setting up DUET is available at https://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blobs/raw/master/Migle_BootDuet_INSTALL.txt .
You can also try http://sourceforge.net/projects/cloverefiboot/ which provides modified DUET images that may contain some system specific fixes and is more frequently updated compared to the gitorious repos.
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