https://wiki.archlinux.org/api.php?action=feedcontributions&user=Dockland&feedformat=atomArchWiki - User contributions [en]2024-03-28T18:29:52ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=441628Unified Extensible Firmware Interface2016-07-16T11:15:47Z<p>Dockland: /* See also */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|EFI System Partition}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related|UEFI/Hardware}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations may carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular mainboard model before proceeding.}}<br />
<br />
The [http://www.uefi.org/ Unified Extensible Firmware Interface] (EFI or UEFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications. <br />
<br />
It is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI Boot Loaders, see [[Boot loaders]].<br />
<br />
== UEFI versions ==<br />
* UEFI started as Intel's EFI in versions 1.x. <br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0. <br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. <br />
* As of 15 April 2015, UEFI Specification 2.5 is the most recent version. <br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
== UEFI Firmware bitness ==<br />
<br />
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. <br />
<br />
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 Intel Cloverfield ultrabooks and some older Intel Server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
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.<br />
<br />
=== Non Macs ===<br />
<br />
Check whether the dir {{ic|/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)<br />
<br />
{{Note|Intel Atom System-on-Chip systems ship with 32-bit UEFI (as on 2 November 2013). See [[#Using GRUB]] for more info.}}<br />
<br />
=== Apple Macs ===<br />
<br />
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. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
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.<br />
<br />
== Linux Kernel Config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI Runtime Variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt .<br />
<br />
== UEFI Variables ==<br />
<br />
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. You can get the list using <br />
$ efivar -l<br />
<br />
=== UEFI Variables Support in Linux Kernel ===<br />
<br />
Linux kernel exposes EFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# Kernel processor [[#UEFI Firmware bitness|bitness]] and EFI processor bitness should match.<br />
# Kernel should be booted in EFI mode (via [[EFISTUB]] or any [[Boot loaders|EFI boot loader]], not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}) the EFI Variables without any error.<br />
<br />
If EFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify efi variables data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel efi variable storage space check that may prevent writing/modification of efi variables.<br />
<br />
{{Note|{{ic|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.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
{{Warning|1=''efivars'' is mounted writeable by default [https://github.com/systemd/systemd/issues/2402], which may cause permanent damage to the system. [https://bbs.archlinux.org/viewtopic.php?id=207549] As such, consider mounting ''efivars'' read-only ({{ic|-o ro}}) as described below. Note that when it is mounted read-only, tools such as ''efibootmgr'' and bootloaders will not be able to change boot settings, nor will commands like {{ic|systemctl reboot --firmware-setup}} work.}}<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools]] like {{ic|efibootmgr}}:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
To mount {{ic|efivarfs}} read-only during boot, add to {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|2=<br />
efivarfs /sys/firmware/efi/efivars efivarfs '''ro''',nosuid,nodev,noexec,noatime 0 0<br />
}}<br />
<br />
To remount with write support, run:<br />
<br />
# mount -o remount /sys/firmware/efi/efivars -o '''rw''',nosuid,nodev,noexec,noatime<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# '''efivar''' - Library and Tool to manipulate UEFI Variables (used by efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings - https://github.com/vathpela/efibootmgr - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# '''uefivars''' - Dumps list of EFI variables with some additional PCI related info (uses efibootmgr code internally) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 supports only efivarfs and https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 supports only sysfs-efivars . AUR package {{AUR|uefivars-git}} <br />
# '''efitools''' - Tools for manipulating UEFI secure boot platforms - {{Pkg|efitools}} or {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}}{{Broken package link|{{aur-mirror|fwts}}}} (along with {{AUR|fwts-efi-runtime-dkms}}{{Broken package link|{{aur-mirror|fwts-efi-runtime-dkms}}}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Note|<br />
* If {{ic|efibootmgr}} completely fails to work in your system, you can reboot into UEFI Shell v2 and use {{ic|bcfg}} command to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage uefi boot entries from within its boot-time interface. For example, some ASUS firmwares have an "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
}}<br />
<br />
Assuming the boot-loader file to be launched is {{ic|/boot/efi/EFI/refind/refind_x64.efi}}, {{ic|/boot/efi/EFI/refind/refind_x64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the EFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here {{ic|X}} and {{ic|Y}} are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , {{ic|1=X==a}} {{ic|1=Y==1}}).<br />
<br />
To determine the actual device path for the EFI System Partition (assuming mountpoint {{ic|/boot/efi}} for example) (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Verify that uefi variables support in kernel is working properly by running:<br />
<br />
# efivar -l<br />
<br />
If efivar lists the uefi variables without any error, then you can proceed. If not, check whether all the conditions in [[#Requirements for UEFI variable support]] are met.<br />
<br />
Then create the boot entry using efibootmgr as follows:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"<br />
<br />
{{Note|1=UEFI uses backward slash {{ic|\}} as path separator (similar to Windows paths), but the official {{Pkg|efibootmgr}} pkg support passing unix-style paths with forward-slash {{ic|/}} as path-separator for the {{ic|-l}} option. Efibootmgr internally converts {{ic|/}} to {{ic|\}} before encoding the loader path. The relevant git commit that incorporated this feature in efibootmgr is http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .}}<br />
<br />
In the above command {{ic|/boot/efi/EFI/refind/refind_x64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/refind/refind_x64.efi}}.<br />
<br />
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 [http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/plain/README efibootmgr GIT README] .<br />
<br />
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 {{ic|\EFI\refind\refindx64.efi}} or {{ic|\efi\refind\refind_x64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== UEFI Shell ==<br />
<br />
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. <br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project:<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/tree/master/ShellBinPkg Precompiled UEFI Shell v2 binaries] (may not be up-to-date)<br />
* [https://github.com/tianocore/edk2/tree/master/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream)<br />
<br />
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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI System Partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/efi/boot/bootx64.efi}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows 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.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. You can download a [http://dl.dropbox.com/u/17629062/Shell2.zip modified UEFI Shell v2 binary] which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|fs0:}} is the mapping corresponding to the EFI System Partition and {{ic|fs0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|fs0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> fs0:<br />
fs0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI System Partition ({{ic|fs0:}} in the firmware),<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI Linux Hardware Compatibility ==<br />
<br />
See [[Unified Extensible Firmware Interface/Hardware]] for more information.<br />
<br />
== UEFI Bootable Media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI Bootable USB]]<br />
<br />
=== Remove UEFI boot support from Optical Media ===<br />
<br />
{{Note|This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media), not from a USB flash drive.}}<br />
<br />
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.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI Optical Media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for Virtual Machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI Mode ===<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen UEFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop. <br />
* If your motherboard is booting the default UEFI path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different UEFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set {bootmgr} path \EFI\''path''\''to''\''app.efi''}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set {fwbootmgr} DEFAULT ''{copied boot identifier}''}}<br />
*# Open ''gpedit'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
* This issue can occur either due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
* If the issue is not due to KMS, then it may be due to bug in [[EFISTUB]] booting (see {{Bug|33745}} and [https://bbs.archlinux.org/viewtopic.php?id=156670] for more information.). Both Official ISO ([[Archiso]]) and [[Archboot]] iso use EFISTUB (via [[Gummiboot]] Boot Manager for menu) for booting the kernel in UEFI mode. In such a case you have to use [[GRUB]] as the USB's UEFI bootloader by following the below section.<br />
<br />
==== Using GRUB ====<br />
{{Deletion|Through bug report this issue should be fixed in kernel 3.16 and after, so this workaround is not needed anymore.}}<br />
{{Tip|The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].}}<br />
<br />
* [[USB flash installation media#BIOS_and_UEFI_Bootable_USB|Create an USB Flash Installation]]<br />
<br />
* Backup {{ic|EFI/boot/loader.efi}} to {{ic|EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_standalone|Create a GRUB standalone image]] and copy the generate {{ic|grub*.efi}} to the USB as {{ic|EFI/boot/loader.efi}}, {{ic|EFI/boot/bootx64.efi}} and/or {{ic|EFI/boot/bootia32.efi}} (useful when running on a 32-bit UEFI)<br />
<br />
* Create {{ic|EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{hc|grub.cfg for Official ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap<br />
initrd /arch/boot/x86_64/archiso.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
{{hc|grub.cfg for Archboot ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux x86_64 Archboot" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap<br />
initrd /boot/initramfs_x86_64.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On some UEFI motherboards like boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the EFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the {{ic|.efi}} file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
FS1:<br />
cd EFI<br />
mkdir Microsoft<br />
cd Microsoft<br />
mkdir Boot<br />
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]{{Dead link|2016|07|16}}<br />
* [http://uefidk.intel.com/ Intel UEFI Community Resource Center]{{Dead link|2016|07|16}}<br />
* [http://uefidk.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]{{Dead link|2016|07|16}}<br />
* [http://uefidk.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]{{Dead link|2016|07|16}}<br />
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore 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<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://dl.dropbox.com/u/17629062/Shell2.zip UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=441627Unified Extensible Firmware Interface2016-07-16T11:14:10Z<p>Dockland: Undo revision 441613 by Dockland (talk)</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|EFI System Partition}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related|UEFI/Hardware}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations may carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular mainboard model before proceeding.}}<br />
<br />
The [http://www.uefi.org/ Unified Extensible Firmware Interface] (EFI or UEFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications. <br />
<br />
It is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI Boot Loaders, see [[Boot loaders]].<br />
<br />
== UEFI versions ==<br />
* UEFI started as Intel's EFI in versions 1.x. <br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0. <br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. <br />
* As of 15 April 2015, UEFI Specification 2.5 is the most recent version. <br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
== UEFI Firmware bitness ==<br />
<br />
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. <br />
<br />
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 Intel Cloverfield ultrabooks and some older Intel Server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
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.<br />
<br />
=== Non Macs ===<br />
<br />
Check whether the dir {{ic|/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)<br />
<br />
{{Note|Intel Atom System-on-Chip systems ship with 32-bit UEFI (as on 2 November 2013). See [[#Using GRUB]] for more info.}}<br />
<br />
=== Apple Macs ===<br />
<br />
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. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
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.<br />
<br />
== Linux Kernel Config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI Runtime Variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt .<br />
<br />
== UEFI Variables ==<br />
<br />
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. You can get the list using <br />
$ efivar -l<br />
<br />
=== UEFI Variables Support in Linux Kernel ===<br />
<br />
Linux kernel exposes EFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# Kernel processor [[#UEFI Firmware bitness|bitness]] and EFI processor bitness should match.<br />
# Kernel should be booted in EFI mode (via [[EFISTUB]] or any [[Boot loaders|EFI boot loader]], not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}) the EFI Variables without any error.<br />
<br />
If EFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify efi variables data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel efi variable storage space check that may prevent writing/modification of efi variables.<br />
<br />
{{Note|{{ic|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.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
{{Warning|1=''efivars'' is mounted writeable by default [https://github.com/systemd/systemd/issues/2402], which may cause permanent damage to the system. [https://bbs.archlinux.org/viewtopic.php?id=207549] As such, consider mounting ''efivars'' read-only ({{ic|-o ro}}) as described below. Note that when it is mounted read-only, tools such as ''efibootmgr'' and bootloaders will not be able to change boot settings, nor will commands like {{ic|systemctl reboot --firmware-setup}} work.}}<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools]] like {{ic|efibootmgr}}:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
To mount {{ic|efivarfs}} read-only during boot, add to {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|2=<br />
efivarfs /sys/firmware/efi/efivars efivarfs '''ro''',nosuid,nodev,noexec,noatime 0 0<br />
}}<br />
<br />
To remount with write support, run:<br />
<br />
# mount -o remount /sys/firmware/efi/efivars -o '''rw''',nosuid,nodev,noexec,noatime<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# '''efivar''' - Library and Tool to manipulate UEFI Variables (used by efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings - https://github.com/vathpela/efibootmgr - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# '''uefivars''' - Dumps list of EFI variables with some additional PCI related info (uses efibootmgr code internally) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 supports only efivarfs and https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 supports only sysfs-efivars . AUR package {{AUR|uefivars-git}} <br />
# '''efitools''' - Tools for manipulating UEFI secure boot platforms - {{Pkg|efitools}} or {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}}{{Broken package link|{{aur-mirror|fwts}}}} (along with {{AUR|fwts-efi-runtime-dkms}}{{Broken package link|{{aur-mirror|fwts-efi-runtime-dkms}}}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Note|<br />
* If {{ic|efibootmgr}} completely fails to work in your system, you can reboot into UEFI Shell v2 and use {{ic|bcfg}} command to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage uefi boot entries from within its boot-time interface. For example, some ASUS firmwares have an "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
}}<br />
<br />
Assuming the boot-loader file to be launched is {{ic|/boot/efi/EFI/refind/refind_x64.efi}}, {{ic|/boot/efi/EFI/refind/refind_x64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the EFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here {{ic|X}} and {{ic|Y}} are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , {{ic|1=X==a}} {{ic|1=Y==1}}).<br />
<br />
To determine the actual device path for the EFI System Partition (assuming mountpoint {{ic|/boot/efi}} for example) (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Verify that uefi variables support in kernel is working properly by running:<br />
<br />
# efivar -l<br />
<br />
If efivar lists the uefi variables without any error, then you can proceed. If not, check whether all the conditions in [[#Requirements for UEFI variable support]] are met.<br />
<br />
Then create the boot entry using efibootmgr as follows:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"<br />
<br />
{{Note|1=UEFI uses backward slash {{ic|\}} as path separator (similar to Windows paths), but the official {{Pkg|efibootmgr}} pkg support passing unix-style paths with forward-slash {{ic|/}} as path-separator for the {{ic|-l}} option. Efibootmgr internally converts {{ic|/}} to {{ic|\}} before encoding the loader path. The relevant git commit that incorporated this feature in efibootmgr is http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .}}<br />
<br />
In the above command {{ic|/boot/efi/EFI/refind/refind_x64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/refind/refind_x64.efi}}.<br />
<br />
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 [http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/plain/README efibootmgr GIT README] .<br />
<br />
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 {{ic|\EFI\refind\refindx64.efi}} or {{ic|\efi\refind\refind_x64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== UEFI Shell ==<br />
<br />
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. <br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project:<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/tree/master/ShellBinPkg Precompiled UEFI Shell v2 binaries] (may not be up-to-date)<br />
* [https://github.com/tianocore/edk2/tree/master/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream)<br />
<br />
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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI System Partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/efi/boot/bootx64.efi}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows 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.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. You can download a [http://dl.dropbox.com/u/17629062/Shell2.zip modified UEFI Shell v2 binary] which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|fs0:}} is the mapping corresponding to the EFI System Partition and {{ic|fs0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|fs0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> fs0:<br />
fs0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI System Partition ({{ic|fs0:}} in the firmware),<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI Linux Hardware Compatibility ==<br />
<br />
See [[Unified Extensible Firmware Interface/Hardware]] for more information.<br />
<br />
== UEFI Bootable Media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI Bootable USB]]<br />
<br />
=== Remove UEFI boot support from Optical Media ===<br />
<br />
{{Note|This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media), not from a USB flash drive.}}<br />
<br />
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.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI Optical Media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for Virtual Machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI Mode ===<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen UEFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop. <br />
* If your motherboard is booting the default UEFI path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different UEFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set {bootmgr} path \EFI\''path''\''to''\''app.efi''}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set {fwbootmgr} DEFAULT ''{copied boot identifier}''}}<br />
*# Open ''gpedit'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
* This issue can occur either due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
* If the issue is not due to KMS, then it may be due to bug in [[EFISTUB]] booting (see {{Bug|33745}} and [https://bbs.archlinux.org/viewtopic.php?id=156670] for more information.). Both Official ISO ([[Archiso]]) and [[Archboot]] iso use EFISTUB (via [[Gummiboot]] Boot Manager for menu) for booting the kernel in UEFI mode. In such a case you have to use [[GRUB]] as the USB's UEFI bootloader by following the below section.<br />
<br />
==== Using GRUB ====<br />
{{Deletion|Through bug report this issue should be fixed in kernel 3.16 and after, so this workaround is not needed anymore.}}<br />
{{Tip|The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].}}<br />
<br />
* [[USB flash installation media#BIOS_and_UEFI_Bootable_USB|Create an USB Flash Installation]]<br />
<br />
* Backup {{ic|EFI/boot/loader.efi}} to {{ic|EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_standalone|Create a GRUB standalone image]] and copy the generate {{ic|grub*.efi}} to the USB as {{ic|EFI/boot/loader.efi}}, {{ic|EFI/boot/bootx64.efi}} and/or {{ic|EFI/boot/bootia32.efi}} (useful when running on a 32-bit UEFI)<br />
<br />
* Create {{ic|EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{hc|grub.cfg for Official ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap<br />
initrd /arch/boot/x86_64/archiso.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
{{hc|grub.cfg for Archboot ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux x86_64 Archboot" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap<br />
initrd /boot/initramfs_x86_64.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On some UEFI motherboards like boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the EFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the {{ic|.efi}} file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
FS1:<br />
cd EFI<br />
mkdir Microsoft<br />
cd Microsoft<br />
mkdir Boot<br />
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<br />
* [http://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://uefidk.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]<br />
* [http://uefidk.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]<br />
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore 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<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://dl.dropbox.com/u/17629062/Shell2.zip UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=441626Unified Extensible Firmware Interface2016-07-16T11:13:54Z<p>Dockland: Undo revision 441614 by Dockland (talk)</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|EFI System Partition}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related|UEFI/Hardware}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations may carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular mainboard model before proceeding.}}<br />
<br />
The [http://www.uefi.org/ Unified Extensible Firmware Interface] (EFI or UEFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications. <br />
<br />
It is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI Boot Loaders, see [[Boot loaders]].<br />
<br />
== UEFI versions ==<br />
* UEFI started as Intel's EFI in versions 1.x. <br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0. <br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. <br />
* As of 15 April 2015, UEFI Specification 2.5 is the most recent version. <br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
== UEFI Firmware bitness ==<br />
<br />
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. <br />
<br />
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 Intel Cloverfield ultrabooks and some older Intel Server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
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.<br />
<br />
=== Non Macs ===<br />
<br />
Check whether the dir {{ic|/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)<br />
<br />
{{Note|Intel Atom System-on-Chip systems ship with 32-bit UEFI (as on 2 November 2013). See [[#Using GRUB]] for more info.}}<br />
<br />
=== Apple Macs ===<br />
<br />
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. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
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.<br />
<br />
== Linux Kernel Config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI Runtime Variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt .<br />
<br />
== UEFI Variables ==<br />
<br />
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. You can get the list using <br />
$ efivar -l<br />
<br />
=== UEFI Variables Support in Linux Kernel ===<br />
<br />
Linux kernel exposes EFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# Kernel processor [[#UEFI Firmware bitness|bitness]] and EFI processor bitness should match.<br />
# Kernel should be booted in EFI mode (via [[EFISTUB]] or any [[Boot loaders|EFI boot loader]], not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}) the EFI Variables without any error.<br />
<br />
If EFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify efi variables data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel efi variable storage space check that may prevent writing/modification of efi variables.<br />
<br />
{{Note|{{ic|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.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
{{Warning|1=''efivars'' is mounted writeable by default [https://github.com/systemd/systemd/issues/2402], which may cause permanent damage to the system. [https://bbs.archlinux.org/viewtopic.php?id=207549] As such, consider mounting ''efivars'' read-only ({{ic|-o ro}}) as described below. Note that when it is mounted read-only, tools such as ''efibootmgr'' and bootloaders will not be able to change boot settings, nor will commands like {{ic|systemctl reboot --firmware-setup}} work.}}<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools]] like {{ic|efibootmgr}}:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
To mount {{ic|efivarfs}} read-only during boot, add to {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|2=<br />
efivarfs /sys/firmware/efi/efivars efivarfs '''ro''',nosuid,nodev,noexec,noatime 0 0<br />
}}<br />
<br />
To remount with write support, run:<br />
<br />
# mount -o remount /sys/firmware/efi/efivars -o '''rw''',nosuid,nodev,noexec,noatime<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# '''efivar''' - Library and Tool to manipulate UEFI Variables (used by efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings - https://github.com/vathpela/efibootmgr - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# '''uefivars''' - Dumps list of EFI variables with some additional PCI related info (uses efibootmgr code internally) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 supports only efivarfs and https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 supports only sysfs-efivars . AUR package {{AUR|uefivars-git}} <br />
# '''efitools''' - Tools for manipulating UEFI secure boot platforms - {{Pkg|efitools}} or {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}}{{Broken package link|{{aur-mirror|fwts}}}} (along with {{AUR|fwts-efi-runtime-dkms}}{{Broken package link|{{aur-mirror|fwts-efi-runtime-dkms}}}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Note|<br />
* If {{ic|efibootmgr}} completely fails to work in your system, you can reboot into UEFI Shell v2 and use {{ic|bcfg}} command to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage uefi boot entries from within its boot-time interface. For example, some ASUS firmwares have an "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
}}<br />
<br />
Assuming the boot-loader file to be launched is {{ic|/boot/efi/EFI/refind/refind_x64.efi}}, {{ic|/boot/efi/EFI/refind/refind_x64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the EFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here {{ic|X}} and {{ic|Y}} are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , {{ic|1=X==a}} {{ic|1=Y==1}}).<br />
<br />
To determine the actual device path for the EFI System Partition (assuming mountpoint {{ic|/boot/efi}} for example) (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Verify that uefi variables support in kernel is working properly by running:<br />
<br />
# efivar -l<br />
<br />
If efivar lists the uefi variables without any error, then you can proceed. If not, check whether all the conditions in [[#Requirements for UEFI variable support]] are met.<br />
<br />
Then create the boot entry using efibootmgr as follows:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"<br />
<br />
{{Note|1=UEFI uses backward slash {{ic|\}} as path separator (similar to Windows paths), but the official {{Pkg|efibootmgr}} pkg support passing unix-style paths with forward-slash {{ic|/}} as path-separator for the {{ic|-l}} option. Efibootmgr internally converts {{ic|/}} to {{ic|\}} before encoding the loader path. The relevant git commit that incorporated this feature in efibootmgr is http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .}}<br />
<br />
In the above command {{ic|/boot/efi/EFI/refind/refind_x64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/refind/refind_x64.efi}}.<br />
<br />
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 [http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/plain/README efibootmgr GIT README] .<br />
<br />
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 {{ic|\EFI\refind\refindx64.efi}} or {{ic|\efi\refind\refind_x64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== UEFI Shell ==<br />
<br />
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. <br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project:<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/tree/master/ShellBinPkg Precompiled UEFI Shell v2 binaries] (may not be up-to-date)<br />
* [https://github.com/tianocore/edk2/tree/master/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream)<br />
<br />
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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI System Partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/efi/boot/bootx64.efi}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows 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.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. You can download a [http://dl.dropbox.com/u/17629062/Shell2.zip modified UEFI Shell v2 binary] which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|fs0:}} is the mapping corresponding to the EFI System Partition and {{ic|fs0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|fs0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> fs0:<br />
fs0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI System Partition ({{ic|fs0:}} in the firmware),<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI Linux Hardware Compatibility ==<br />
<br />
See [[Unified Extensible Firmware Interface/Hardware]] for more information.<br />
<br />
== UEFI Bootable Media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI Bootable USB]]<br />
<br />
=== Remove UEFI boot support from Optical Media ===<br />
<br />
{{Note|This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media), not from a USB flash drive.}}<br />
<br />
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.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI Optical Media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for Virtual Machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI Mode ===<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen UEFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop. <br />
* If your motherboard is booting the default UEFI path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different UEFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set {bootmgr} path \EFI\''path''\''to''\''app.efi''}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set {fwbootmgr} DEFAULT ''{copied boot identifier}''}}<br />
*# Open ''gpedit'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
* This issue can occur either due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
* If the issue is not due to KMS, then it may be due to bug in [[EFISTUB]] booting (see {{Bug|33745}} and [https://bbs.archlinux.org/viewtopic.php?id=156670] for more information.). Both Official ISO ([[Archiso]]) and [[Archboot]] iso use EFISTUB (via [[Gummiboot]] Boot Manager for menu) for booting the kernel in UEFI mode. In such a case you have to use [[GRUB]] as the USB's UEFI bootloader by following the below section.<br />
<br />
==== Using GRUB ====<br />
{{Deletion|Through bug report this issue should be fixed in kernel 3.16 and after, so this workaround is not needed anymore.}}<br />
{{Tip|The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].}}<br />
<br />
* [[USB flash installation media#BIOS_and_UEFI_Bootable_USB|Create an USB Flash Installation]]<br />
<br />
* Backup {{ic|EFI/boot/loader.efi}} to {{ic|EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_standalone|Create a GRUB standalone image]] and copy the generate {{ic|grub*.efi}} to the USB as {{ic|EFI/boot/loader.efi}}, {{ic|EFI/boot/bootx64.efi}} and/or {{ic|EFI/boot/bootia32.efi}} (useful when running on a 32-bit UEFI)<br />
<br />
* Create {{ic|EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{hc|grub.cfg for Official ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap<br />
initrd /arch/boot/x86_64/archiso.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
{{hc|grub.cfg for Archboot ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux x86_64 Archboot" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap<br />
initrd /boot/initramfs_x86_64.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On some UEFI motherboards like boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the EFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the {{ic|.efi}} file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
FS1:<br />
cd EFI<br />
mkdir Microsoft<br />
cd Microsoft<br />
mkdir Boot<br />
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [http://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://uefidk.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]<br />
* [http://uefidk.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]<br />
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore 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<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://dl.dropbox.com/u/17629062/Shell2.zip UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Init&diff=441625Init2016-07-16T11:12:33Z<p>Dockland: /* See also */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:Init]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Init Rosetta}}<br />
{{Related articles end}}<br />
<br />
{{Warning|Arch Linux only has official support for [[systemd]]. [https://lists.archlinux.org/pipermail/arch-general/2015-July/039460.html] When using a different init system, please mention so in support requests.}}<br />
<br />
[[Wikipedia:Init|Init]] is the first process started during system boot. It is a a daemon process that continues running until the system is shut down. Init is the direct or indirect ancestor of all other processes, and automatically adopts all orphaned processes. It is started by the kernel using a hard-coded filename; if the kernel is unable to start it, panic will result. Init is typically assigned process identifier 1.<br />
<br />
The init ''scripts'' (or ''rc'') are launched by the init process to guarantee basic functionality on system start and shutdown. This includes (un)mounting of [[file system]]s and launching of [[daemons]]. A ''service manager'' takes this one step further by providing active control over launched processes, or [[Wikipedia:Process Supervision|process supervision]]. An example is to monitor for crashes and restart processes accordingly.<br />
<br />
These components combine to the init ''system''. Some inits include the service manager in the init process, or have init scripts in close relation to them. These inits are below referred to as ''integrated'', though entries in different categories may explicitly depend on each other.<br />
<br />
== Inits (integrated) ==<br />
<br />
* {{App|[[systemd]]|Dependency-based init system with aggressive parallelization, process supervision using cgroups, and the ability to depend on a given mount point or dbus service.|http://freedesktop.org/wiki/Software/systemd/|{{Pkg|systemd}}}}<br />
* {{App|[[Wikipedia:Upstart|Upstart]]|Event-based init system which handles starting, stopping and supervising of tasks and services.|http://upstart.ubuntu.com/|{{AUR|upstart}}{{Broken package link|{{aur-mirror|upstart}}}}}}<br />
* {{App|initng|Dependency-based init system with parallelization and asynchronous start.|http://initng.sourceforge.net/trac|{{AUR|initng-git}}{{Broken package link|{{aur-mirror|initng-git}}}}}}<br />
* {{App|Epoch|Single-threaded init system designed for minimal footprint, compatibility and unified configuration.|http://universe2.us/epoch.html|}}{{AUR|epoch-init-system}}{{Broken package link|{{aur-mirror|epoch-init-system}}}}<br />
* {{App|finit|Fast and extensible init, originally based on EeePC fastinit.|https://github.com/troglobit/finit|{{AUR|finit-arc}}{{Broken package link|{{aur-mirror|finit-arc}}}} / {{AUR|finit-arc-git}}{{Broken package link|{{aur-mirror|finit-arc-git}}}}}}<br />
<br />
== Inits ==<br />
<br />
* {{App|[[BusyBox]]|Utilities for rescue and embedded systems.|http://busybox.net/|{{Pkg|busybox}}}}<br />
* {{App|[[SysVinit]]|Traditional System V init.|http://savannah.nongnu.org/projects/sysvinit|{{AUR|sysvinit}}}}<br />
* {{App|ninit|Fork from [http://www.fefe.de/minit/ minit]|http://riemann.fmi.uni-sofia.bg/ninit/|{{AUR|ninit}}}}<br />
* {{App|sinit|Simple init initially based on Rich Felker’s minimal init.|http://core.suckless.org/sinit|{{AUR|sinit}}}}<br />
<br />
== Init scripts ==<br />
<br />
* {{App|initscripts-fork|Maintained fork of SysVinit scripts in Arch Linux.|https://bitbucket.org/TZ86/initscripts-fork/overview|{{AUR|initscripts-fork}}}}<br />
* {{App|minirc|Minimal init script designed for BusyBox.|https://github.com/hut/minirc/|{{AUR|minirc-git}}}}<br />
* {{App|OpenRC Arch services|OpenRC service scripts compatible to Arch Linux.|https://github.com/andrewgregory/openrc-arch-services|{{AUR|openrc-arch-services-git}}}}<br />
* {{App|spark-rc|A simple rc script to kickstart your system.|https://gitlab.com/fbt/spark-rc|{{AUR|spark-rc}}}}<br />
* {{App|watchman-sm-services|Examples of services for watchman.|https://gitlab.com/fbt/watchman-services|{{AUR|watchman-sm-services-git}}}}<br />
<br />
== Service managers ==<br />
<br />
* {{App|daemontools|Collection of tools for managing UNIX services.|http://cr.yp.to/daemontools.html|{{AUR|daemontools}}}}<br />
* {{App|[[Monit]]|Monit is a process supervision tool for Unix and Linux. With monit, system status can be viewed directly from the command line, or via the native HTTP(S) web server.|http://mmonit.com/monit/|{{Pkg|monit}}}}<br />
* {{App|[[OpenRC]]|Dependency-based rc system that works with the system-provided init, normally SysVinit.|http://www.gentoo.org/proj/en/base/openrc/|{{AUR|openrc}}}}<br />
* {{App|perp|Persistent process (service) supervisor and managment framework for UNIX.|http://b0llix.net/perp/|{{AUR|perp}}}}<br />
* {{App|[[runit]]|UNIX init scheme with service supervision, a replacement for SysVinit, and other init schemes.|http://smarden.org/runit/|{{AUR|runit}}}}<br />
* {{App|s6|Small suite of programs for UNIX, designed to allow service supervision in the line of daemontools and runit.|http://skarnet.org/software/s6/|{{AUR|s6}}}}<br />
* {{App|watchman|A not-so-simple service manager for Linux.|https://gitlab.com/fbt/watchman|{{AUR|watchman-sm}}}}<br />
<br />
== Configuration ==<br />
<br />
=== Migrate running daemons ===<br />
<br />
To run daemons under the new init, save a list of running daemons:<br />
<br />
$ systemctl list-units --state=running "*.service" > daemons.list<br />
<br />
then configure the [[#Init scripts]] accordingly. See also [http://unix.stackexchange.com/questions/175380/how-to-list-all-running-daemons].<br />
<br />
Temporary files (''systemd-tmpfiles''), [[kernel modules]] and [[sysctl]] may also need configuration.<br />
<br />
=== logind ===<br />
<br />
[http://www.freedesktop.org/wiki/Software/systemd/logind/ logind] requires ''systemd'' to be the init process. [http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/] As such, [[General_troubleshooting#Session_permissions|local sessions]] and other functionality is not available.<br />
<br />
==== Device permissions ====<br />
<br />
Add users to the correct [[Users_and_groups#Group_list|groups]] for device access, and reboot. Current group membership should first be checked with {{ic|id ''user''}}. For example:<br />
<br />
# usermod -a -G video,audio,power,disk,storage,optical,lp,scanner ''user''<br />
<br />
See [[Policykit#Bypass password prompt]] to create group rules for use with Policykit.<br />
<br />
==== Rootless X (1.16) ====<br />
<br />
As {{ic|Xorg.wrap}} does not check if logind is active [https://bugs.freedesktop.org/show_bug.cgi?id=86975#c5], [[Xorg#Rootless Xorg (v1.16)|root rights for Xorg]] need be enabled manually:<br />
<br />
{{hc|1=/etc/X11/Xwrapper.config|2=<br />
needs_root_rights = yes<br />
}}<br />
<br />
==== Power management ====<br />
<br />
See [[pm-utils]] and [[acpid]] to replace [[Power_management#Power_management_with_systemd|Power management with systemd]].<br />
<br />
=== Scheduled tasks ===<br />
<br />
Arch uses [[Systemd#Timers|timer]] files instead of [[cron]] by default. See [https://github.com/notfoss/archlinux-cronjobs archlinux-cronjobs] for basic cron jobs.<br />
<br />
=== Dbus ===<br />
<br />
User instances of ''dbus-daemon'' are launched by [[systemd/User#D-Bus|systemd/User]]. [https://www.archlinux.org/news/d-bus-now-launches-user-buses/] When requring IPC between desktop applications, restore {{ic|30-dbus.sh}}:<br />
<br />
{{hc|1=/etc/X11/xinit/xinitrc.d/30-dbus.sh|2=<br />
#!/bin/bash<br />
<br />
# launches a session dbus instance<br />
if [ -z "${DBUS_SESSION_BUS_ADDRESS-}" ] && type dbus-launch >/dev/null; then<br />
eval $(dbus-launch --sh-syntax --exit-with-session)<br />
fi<br />
}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== systemd-nspawn ===<br />
<br />
[[systemd-nspawn]] is a tool for systemd systems. Since Linux 2.6.19 it is however possible to run systemd on a non-systemd system by using PID namespace. For it, the kernel needs to be configured with {{ic|CONFIG_PID_NS}} and {{ic|CONFIG_NAMESPACES}}). <br />
<br />
The PID namespace creates a new hierarchy of processes starting with PID 1. In addition to this, systemd requires a chrooted root filesystem to be mounted. Hence, you have to at least make a bind mount, because otherwise some services will fail with <br />
<br />
"Failed at step NAMESPACE spawning" due to "Invalid operation" <br />
<br />
as systemd tries to remount the root with {{ic|private}} option. <br />
<br />
To setup a chroot with a new PID namespace you can use jchroot.[http://vincent.bernat.im/en/blog/2011-jchroot-isolation.html] [https://github.com/vincentbernat/jchroot]. <br />
Make sure not to mount {{ic|/proc}} inside the new root before chrooting, otherwise systemd will detect the chroot environment. You can mount it later once systemd is running.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.debian.org/Debate/initsystem Debian init system debate]<br />
* [http://skarnet.org/software/s6/s6-svscan-1.html How to run s6-svscan as process 1]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=162606&p=1 Replace systemd with busybox + minirc]<br />
* [http://www.troubleshooters.com/linux/init/manjaro_experiments.htm Experiments of Manjaro]<br />
* [http://busybox.net/~vda/init_vs_runsv.html Init vs. runsv]{{Dead link|2016|07|16}}<br />
* [https://felipec.wordpress.com/2013/11/04/init/ Demystifying the init system]<br />
* [http://blog.darknedgy.net/technology/2015/09/05/0/ A history of modern init systems (1992-2015)]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Init&diff=441624Init2016-07-16T11:12:18Z<p>Dockland: Undo revision 441615 by Dockland (talk)</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:Init]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Init Rosetta}}<br />
{{Related articles end}}<br />
<br />
{{Warning|Arch Linux only has official support for [[systemd]]. [https://lists.archlinux.org/pipermail/arch-general/2015-July/039460.html] When using a different init system, please mention so in support requests.}}<br />
<br />
[[Wikipedia:Init|Init]] is the first process started during system boot. It is a a daemon process that continues running until the system is shut down. Init is the direct or indirect ancestor of all other processes, and automatically adopts all orphaned processes. It is started by the kernel using a hard-coded filename; if the kernel is unable to start it, panic will result. Init is typically assigned process identifier 1.<br />
<br />
The init ''scripts'' (or ''rc'') are launched by the init process to guarantee basic functionality on system start and shutdown. This includes (un)mounting of [[file system]]s and launching of [[daemons]]. A ''service manager'' takes this one step further by providing active control over launched processes, or [[Wikipedia:Process Supervision|process supervision]]. An example is to monitor for crashes and restart processes accordingly.<br />
<br />
These components combine to the init ''system''. Some inits include the service manager in the init process, or have init scripts in close relation to them. These inits are below referred to as ''integrated'', though entries in different categories may explicitly depend on each other.<br />
<br />
== Inits (integrated) ==<br />
<br />
* {{App|[[systemd]]|Dependency-based init system with aggressive parallelization, process supervision using cgroups, and the ability to depend on a given mount point or dbus service.|http://freedesktop.org/wiki/Software/systemd/|{{Pkg|systemd}}}}<br />
* {{App|[[Wikipedia:Upstart|Upstart]]|Event-based init system which handles starting, stopping and supervising of tasks and services.|http://upstart.ubuntu.com/|{{AUR|upstart}}{{Broken package link|{{aur-mirror|upstart}}}}}}<br />
* {{App|initng|Dependency-based init system with parallelization and asynchronous start.|http://initng.sourceforge.net/trac|{{AUR|initng-git}}{{Broken package link|{{aur-mirror|initng-git}}}}}}<br />
* {{App|Epoch|Single-threaded init system designed for minimal footprint, compatibility and unified configuration.|http://universe2.us/epoch.html|}}{{AUR|epoch-init-system}}{{Broken package link|{{aur-mirror|epoch-init-system}}}}<br />
* {{App|finit|Fast and extensible init, originally based on EeePC fastinit.|https://github.com/troglobit/finit|{{AUR|finit-arc}}{{Broken package link|{{aur-mirror|finit-arc}}}} / {{AUR|finit-arc-git}}{{Broken package link|{{aur-mirror|finit-arc-git}}}}}}<br />
<br />
== Inits ==<br />
<br />
* {{App|[[BusyBox]]|Utilities for rescue and embedded systems.|http://busybox.net/|{{Pkg|busybox}}}}<br />
* {{App|[[SysVinit]]|Traditional System V init.|http://savannah.nongnu.org/projects/sysvinit|{{AUR|sysvinit}}}}<br />
* {{App|ninit|Fork from [http://www.fefe.de/minit/ minit]|http://riemann.fmi.uni-sofia.bg/ninit/|{{AUR|ninit}}}}<br />
* {{App|sinit|Simple init initially based on Rich Felker’s minimal init.|http://core.suckless.org/sinit|{{AUR|sinit}}}}<br />
<br />
== Init scripts ==<br />
<br />
* {{App|initscripts-fork|Maintained fork of SysVinit scripts in Arch Linux.|https://bitbucket.org/TZ86/initscripts-fork/overview|{{AUR|initscripts-fork}}}}<br />
* {{App|minirc|Minimal init script designed for BusyBox.|https://github.com/hut/minirc/|{{AUR|minirc-git}}}}<br />
* {{App|OpenRC Arch services|OpenRC service scripts compatible to Arch Linux.|https://github.com/andrewgregory/openrc-arch-services|{{AUR|openrc-arch-services-git}}}}<br />
* {{App|spark-rc|A simple rc script to kickstart your system.|https://gitlab.com/fbt/spark-rc|{{AUR|spark-rc}}}}<br />
* {{App|watchman-sm-services|Examples of services for watchman.|https://gitlab.com/fbt/watchman-services|{{AUR|watchman-sm-services-git}}}}<br />
<br />
== Service managers ==<br />
<br />
* {{App|daemontools|Collection of tools for managing UNIX services.|http://cr.yp.to/daemontools.html|{{AUR|daemontools}}}}<br />
* {{App|[[Monit]]|Monit is a process supervision tool for Unix and Linux. With monit, system status can be viewed directly from the command line, or via the native HTTP(S) web server.|http://mmonit.com/monit/|{{Pkg|monit}}}}<br />
* {{App|[[OpenRC]]|Dependency-based rc system that works with the system-provided init, normally SysVinit.|http://www.gentoo.org/proj/en/base/openrc/|{{AUR|openrc}}}}<br />
* {{App|perp|Persistent process (service) supervisor and managment framework for UNIX.|http://b0llix.net/perp/|{{AUR|perp}}}}<br />
* {{App|[[runit]]|UNIX init scheme with service supervision, a replacement for SysVinit, and other init schemes.|http://smarden.org/runit/|{{AUR|runit}}}}<br />
* {{App|s6|Small suite of programs for UNIX, designed to allow service supervision in the line of daemontools and runit.|http://skarnet.org/software/s6/|{{AUR|s6}}}}<br />
* {{App|watchman|A not-so-simple service manager for Linux.|https://gitlab.com/fbt/watchman|{{AUR|watchman-sm}}}}<br />
<br />
== Configuration ==<br />
<br />
=== Migrate running daemons ===<br />
<br />
To run daemons under the new init, save a list of running daemons:<br />
<br />
$ systemctl list-units --state=running "*.service" > daemons.list<br />
<br />
then configure the [[#Init scripts]] accordingly. See also [http://unix.stackexchange.com/questions/175380/how-to-list-all-running-daemons].<br />
<br />
Temporary files (''systemd-tmpfiles''), [[kernel modules]] and [[sysctl]] may also need configuration.<br />
<br />
=== logind ===<br />
<br />
[http://www.freedesktop.org/wiki/Software/systemd/logind/ logind] requires ''systemd'' to be the init process. [http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/] As such, [[General_troubleshooting#Session_permissions|local sessions]] and other functionality is not available.<br />
<br />
==== Device permissions ====<br />
<br />
Add users to the correct [[Users_and_groups#Group_list|groups]] for device access, and reboot. Current group membership should first be checked with {{ic|id ''user''}}. For example:<br />
<br />
# usermod -a -G video,audio,power,disk,storage,optical,lp,scanner ''user''<br />
<br />
See [[Policykit#Bypass password prompt]] to create group rules for use with Policykit.<br />
<br />
==== Rootless X (1.16) ====<br />
<br />
As {{ic|Xorg.wrap}} does not check if logind is active [https://bugs.freedesktop.org/show_bug.cgi?id=86975#c5], [[Xorg#Rootless Xorg (v1.16)|root rights for Xorg]] need be enabled manually:<br />
<br />
{{hc|1=/etc/X11/Xwrapper.config|2=<br />
needs_root_rights = yes<br />
}}<br />
<br />
==== Power management ====<br />
<br />
See [[pm-utils]] and [[acpid]] to replace [[Power_management#Power_management_with_systemd|Power management with systemd]].<br />
<br />
=== Scheduled tasks ===<br />
<br />
Arch uses [[Systemd#Timers|timer]] files instead of [[cron]] by default. See [https://github.com/notfoss/archlinux-cronjobs archlinux-cronjobs] for basic cron jobs.<br />
<br />
=== Dbus ===<br />
<br />
User instances of ''dbus-daemon'' are launched by [[systemd/User#D-Bus|systemd/User]]. [https://www.archlinux.org/news/d-bus-now-launches-user-buses/] When requring IPC between desktop applications, restore {{ic|30-dbus.sh}}:<br />
<br />
{{hc|1=/etc/X11/xinit/xinitrc.d/30-dbus.sh|2=<br />
#!/bin/bash<br />
<br />
# launches a session dbus instance<br />
if [ -z "${DBUS_SESSION_BUS_ADDRESS-}" ] && type dbus-launch >/dev/null; then<br />
eval $(dbus-launch --sh-syntax --exit-with-session)<br />
fi<br />
}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== systemd-nspawn ===<br />
<br />
[[systemd-nspawn]] is a tool for systemd systems. Since Linux 2.6.19 it is however possible to run systemd on a non-systemd system by using PID namespace. For it, the kernel needs to be configured with {{ic|CONFIG_PID_NS}} and {{ic|CONFIG_NAMESPACES}}). <br />
<br />
The PID namespace creates a new hierarchy of processes starting with PID 1. In addition to this, systemd requires a chrooted root filesystem to be mounted. Hence, you have to at least make a bind mount, because otherwise some services will fail with <br />
<br />
"Failed at step NAMESPACE spawning" due to "Invalid operation" <br />
<br />
as systemd tries to remount the root with {{ic|private}} option. <br />
<br />
To setup a chroot with a new PID namespace you can use jchroot.[http://vincent.bernat.im/en/blog/2011-jchroot-isolation.html] [https://github.com/vincentbernat/jchroot]. <br />
Make sure not to mount {{ic|/proc}} inside the new root before chrooting, otherwise systemd will detect the chroot environment. You can mount it later once systemd is running.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.debian.org/Debate/initsystem Debian init system debate]<br />
* [http://skarnet.org/software/s6/s6-svscan-1.html How to run s6-svscan as process 1]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=162606&p=1 Replace systemd with busybox + minirc]<br />
* [http://www.troubleshooters.com/linux/init/manjaro_experiments.htm Experiments of Manjaro]<br />
* [http://busybox.net/~vda/init_vs_runsv.html Init vs. runsv]<br />
* [https://felipec.wordpress.com/2013/11/04/init/ Demystifying the init system]<br />
* [http://blog.darknedgy.net/technology/2015/09/05/0/ A history of modern init systems (1992-2015)]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Arch_boot_process&diff=441623Arch boot process2016-07-16T11:11:40Z<p>Dockland: /* See also */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:About Arch]]<br />
[[ar:Arch boot process]]<br />
[[cs:Arch boot process]]<br />
[[es:Arch boot process]]<br />
[[fr:Processus de boot]]<br />
[[it:Arch boot process]]<br />
[[ja:Arch ブートプロセス]]<br />
[[ru:Arch boot process]]<br />
[[zh-cn:Arch boot process]]<br />
{{Related articles start}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|mkinitcpio}}<br />
{{Related|init}}<br />
{{Related|systemd}}<br />
{{Related|fstab}}<br />
{{Related|Autostarting}}<br />
{{Related articles end}}<br />
<br />
In order to boot Arch Linux, a Linux-capable [[boot loader]] such as [[GRUB]] or [[Syslinux]] must be installed to the [[Master Boot Record]] or the [[GUID Partition Table]]. The boot loader is responsible for loading the kernel and [[initial ramdisk]] before initiating the boot process. The procedure is quite different for [[Wikipedia:BIOS|BIOS]] and [[UEFI]] systems, the detailed description is given on this or linked pages.<br />
<br />
== Firmware types ==<br />
=== BIOS ===<br />
<br />
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. <br />
<br />
The BIOS loads the beginning 512 bytes ([[Master Boot Record]]) of the first valid disk in the BIOS disk order. Of these 512 bytes, the first 440 contains the first stage of a boot loader like [[GRUB]], [[Syslinux]] or [[LILO]]. Since very little can be achieved by a program of this size, the second stage (residing on the next disk sectors) is loaded from here and looks up a file stored on the partition itself (the actual bootloader). This then loads an operating system by either chain-loading or directly loading the operating system kernel.<br />
<br />
=== UEFI ===<br />
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.<br />
<br />
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 Intel Macs can also access HFS/HFS+ filesystems, in addition to the mentioned ones.<br />
<br />
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 {{ic|<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 or (less commonly) FAT16.<br />
<br />
== System initialization ==<br />
<br />
=== Under BIOS ===<br />
<br />
# System switched on - [[Wikipedia:Power-on self-test|Power-on self-test]] or POST process<br />
# After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.)<br />
# BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order<br />
# The MBR boot code then takes control from BIOS and launches its next stage code (if any) (mostly [[boot loader]] code)<br />
# The launched actual boot loader<br />
<br />
=== Under UEFI ===<br />
<br />
# System switched on. The Power On Self Test (POST) is executed.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware reads the boot entries in the firmware's boot manager to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware launches the UEFI application.<br />
#* This could be the Arch kernel itself (since [[EFISTUB]] is enabled by default).<br />
#* It could be some other application such as a shell or a graphical boot manager.<br />
#* Or the boot entry could simply be a disk. In this case the firmware looks for an [[EFI System Partition]] on that disk and tries to run the fallback UEFI application {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} on 32-bit systems). This is how UEFI bootable thumb drives work.<br />
<br />
If [[Secure Boot]] is enabled, the boot process will verify authenticity of the EFI binary by signature.<br />
<br />
{{Note|On some (poorly-designed) UEFI systems the only way to boot is using a disk boot entry with the fallback UEFI application path.}}<br />
<br />
=== Multibooting in UEFI ===<br />
<br />
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 [[boot loader]] to load another to switch OSes.<br />
<br />
See also [[Dual boot with Windows]].<br />
<br />
== Boot loader ==<br />
<br />
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] based on config files. <br />
<br />
== Kernel ==<br />
The kernel is the core of an operating system. It functions on a low level (''kernelspace'') interacting between the hardware of the machine and the programs which use the hardware to run. To make efficient use of the CPU, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion of many tasks being executed simultaneously.<br />
<br />
== initramfs ==<br />
After the kernel is loaded, it unpacks the [[initramfs]] (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes {{ic|/init}} as the first process. The ''early userspace'' starts.<br />
<br />
The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem (see [[FHS]] for details). This means that any modules that are required for devices like IDE, SCSI, SATA, USB/FW (if booting from an external drive) must be loadable from the initramfs if not built into the kernel; once the proper modules are loaded (either explicitly via a program or script, or implicitly via [[udev]]), the boot process continues. For this reason, the initramfs only needs to contain the modules necessary to access the root filesystem; it does not need to contain every module one would ever want to use. The majority of modules will be loaded later on by udev, during the init process.<br />
<br />
== Init process ==<br />
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem. {{ic|/sbin/init}} is executed, replacing the {{ic|/init}} process. Arch uses [[systemd]] as the default [[init]].<br />
<br />
== Getty ==<br />
[[init]] calls [[getty]] once for each [[Wikipedia:Virtual console|virtual terminal]] (typically six of them), which initializes each tty and asks for a username and password. Once the username and password are provided, getty checks them against {{ic|/etc/passwd}}, then calls [[#Login|login]], which begins a session for the user, and executes the user's shell according to {{ic|/etc/passwd}}. Alternatively, getty may start a display manager if one is present on the system.<br />
<br />
== Display Manager ==<br />
A [[display manager]] can be configured to replace the getty login prompt on a tty.<br />
<br />
== Login ==<br />
The ''login'' program begins a session for the user by setting environment variables and starting the user's shell, based on {{ic|/etc/passwd}}.<br />
<br />
=== Message of the day ===<br />
<br />
The ''login'' program displays the contents of [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) after a successful login, just before it executes the login shell.<br />
<br />
It is a good place to display your Terms of Service to remind users of your local policies or anything you wish to tell them.<br />
<br />
== Shell ==<br />
Once the user's [[shell]] is started, it will typically run a runtime configuration file, such as [[bashrc]], before presenting a prompt to the user. If the account is configured to [[Start X at login]], the runtime configuration file will call [[startx]] or [[xinit]].<br />
<br />
== xinit ==<br />
[[xinit]] runs the user's [[xinitrc]] runtime configuration file, which normally starts a [[window manager]]. When the user is finished and exits the window manager, xinit, startx, the shell, and login will terminate in that order, returning to getty.<br />
<br />
== See also ==<br />
* [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]{{Dead link|2016|07|16}}<br />
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]<br />
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]<br />
* [[Wikipedia:Linux startup process]]<br />
* [[Wikipedia:initrd]]<br />
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]<br />
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Arch_boot_process&diff=441622Arch boot process2016-07-16T11:11:19Z<p>Dockland: Undo revision 441612 by Dockland (talk)</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:About Arch]]<br />
[[ar:Arch boot process]]<br />
[[cs:Arch boot process]]<br />
[[es:Arch boot process]]<br />
[[fr:Processus de boot]]<br />
[[it:Arch boot process]]<br />
[[ja:Arch ブートプロセス]]<br />
[[ru:Arch boot process]]<br />
[[zh-cn:Arch boot process]]<br />
{{Related articles start}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|mkinitcpio}}<br />
{{Related|init}}<br />
{{Related|systemd}}<br />
{{Related|fstab}}<br />
{{Related|Autostarting}}<br />
{{Related articles end}}<br />
<br />
In order to boot Arch Linux, a Linux-capable [[boot loader]] such as [[GRUB]] or [[Syslinux]] must be installed to the [[Master Boot Record]] or the [[GUID Partition Table]]. The boot loader is responsible for loading the kernel and [[initial ramdisk]] before initiating the boot process. The procedure is quite different for [[Wikipedia:BIOS|BIOS]] and [[UEFI]] systems, the detailed description is given on this or linked pages.<br />
<br />
== Firmware types ==<br />
=== BIOS ===<br />
<br />
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. <br />
<br />
The BIOS loads the beginning 512 bytes ([[Master Boot Record]]) of the first valid disk in the BIOS disk order. Of these 512 bytes, the first 440 contains the first stage of a boot loader like [[GRUB]], [[Syslinux]] or [[LILO]]. Since very little can be achieved by a program of this size, the second stage (residing on the next disk sectors) is loaded from here and looks up a file stored on the partition itself (the actual bootloader). This then loads an operating system by either chain-loading or directly loading the operating system kernel.<br />
<br />
=== UEFI ===<br />
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.<br />
<br />
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 Intel Macs can also access HFS/HFS+ filesystems, in addition to the mentioned ones.<br />
<br />
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 {{ic|<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 or (less commonly) FAT16.<br />
<br />
== System initialization ==<br />
<br />
=== Under BIOS ===<br />
<br />
# System switched on - [[Wikipedia:Power-on self-test|Power-on self-test]] or POST process<br />
# After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.)<br />
# BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order<br />
# The MBR boot code then takes control from BIOS and launches its next stage code (if any) (mostly [[boot loader]] code)<br />
# The launched actual boot loader<br />
<br />
=== Under UEFI ===<br />
<br />
# System switched on. The Power On Self Test (POST) is executed.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware reads the boot entries in the firmware's boot manager to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware launches the UEFI application.<br />
#* This could be the Arch kernel itself (since [[EFISTUB]] is enabled by default).<br />
#* It could be some other application such as a shell or a graphical boot manager.<br />
#* Or the boot entry could simply be a disk. In this case the firmware looks for an [[EFI System Partition]] on that disk and tries to run the fallback UEFI application {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} on 32-bit systems). This is how UEFI bootable thumb drives work.<br />
<br />
If [[Secure Boot]] is enabled, the boot process will verify authenticity of the EFI binary by signature.<br />
<br />
{{Note|On some (poorly-designed) UEFI systems the only way to boot is using a disk boot entry with the fallback UEFI application path.}}<br />
<br />
=== Multibooting in UEFI ===<br />
<br />
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 [[boot loader]] to load another to switch OSes.<br />
<br />
See also [[Dual boot with Windows]].<br />
<br />
== Boot loader ==<br />
<br />
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] based on config files. <br />
<br />
== Kernel ==<br />
The kernel is the core of an operating system. It functions on a low level (''kernelspace'') interacting between the hardware of the machine and the programs which use the hardware to run. To make efficient use of the CPU, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion of many tasks being executed simultaneously.<br />
<br />
== initramfs ==<br />
After the kernel is loaded, it unpacks the [[initramfs]] (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes {{ic|/init}} as the first process. The ''early userspace'' starts.<br />
<br />
The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem (see [[FHS]] for details). This means that any modules that are required for devices like IDE, SCSI, SATA, USB/FW (if booting from an external drive) must be loadable from the initramfs if not built into the kernel; once the proper modules are loaded (either explicitly via a program or script, or implicitly via [[udev]]), the boot process continues. For this reason, the initramfs only needs to contain the modules necessary to access the root filesystem; it does not need to contain every module one would ever want to use. The majority of modules will be loaded later on by udev, during the init process.<br />
<br />
== Init process ==<br />
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem. {{ic|/sbin/init}} is executed, replacing the {{ic|/init}} process. Arch uses [[systemd]] as the default [[init]].<br />
<br />
== Getty ==<br />
[[init]] calls [[getty]] once for each [[Wikipedia:Virtual console|virtual terminal]] (typically six of them), which initializes each tty and asks for a username and password. Once the username and password are provided, getty checks them against {{ic|/etc/passwd}}, then calls [[#Login|login]], which begins a session for the user, and executes the user's shell according to {{ic|/etc/passwd}}. Alternatively, getty may start a display manager if one is present on the system.<br />
<br />
== Display Manager ==<br />
A [[display manager]] can be configured to replace the getty login prompt on a tty.<br />
<br />
== Login ==<br />
The ''login'' program begins a session for the user by setting environment variables and starting the user's shell, based on {{ic|/etc/passwd}}.<br />
<br />
=== Message of the day ===<br />
<br />
The ''login'' program displays the contents of [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) after a successful login, just before it executes the login shell.<br />
<br />
It is a good place to display your Terms of Service to remind users of your local policies or anything you wish to tell them.<br />
<br />
== Shell ==<br />
Once the user's [[shell]] is started, it will typically run a runtime configuration file, such as [[bashrc]], before presenting a prompt to the user. If the account is configured to [[Start X at login]], the runtime configuration file will call [[startx]] or [[xinit]].<br />
<br />
== xinit ==<br />
[[xinit]] runs the user's [[xinitrc]] runtime configuration file, which normally starts a [[window manager]]. When the user is finished and exits the window manager, xinit, startx, the shell, and login will terminate in that order, returning to getty.<br />
<br />
== See also ==<br />
* [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]<br />
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]<br />
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]<br />
* [[Wikipedia:Linux startup process]]<br />
* [[Wikipedia:initrd]]<br />
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]<br />
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Solid_state_drive/NVMe&diff=441621Solid state drive/NVMe2016-07-16T11:08:54Z<p>Dockland: /* References */ dead link template added</p>
<hr />
<div>[[Category:Storage]]<br />
[[ja:ソリッドステートドライブ/NVMe]]<br />
{{Related articles start}}<br />
{{Related|Solid State Drives}}<br />
{{Related articles end}}<br />
<br />
NVM Express (NVMe) is a specification for accessing SSDs attached through the PCI Express bus. As a logical device interface, NVM Express has been designed from the ground up, capitalizing on the low latency and parallelism of PCI Express SSDs, and mirroring the parallelism of contemporary CPUs, platforms and applications.<br />
<br />
== Installation ==<br />
<br />
The Linux NVMe driver is natively included in the kernel since version 3.3. NVMe devices should show up under {{ic|/dev/nvme*}}.<br />
<br />
Extra userspace NVMe tools can be found in {{aur|nvme-cli-git}}.<br />
<br />
See [[Solid State Drives]] for supported filesystems, maximizing performance, minimizing disk reads/writes, etc.<br />
<br />
{{Note|It may be needed to add the '''nvme''' module to the [[Mkinitcpio#MODULES|MODULES]] array within {{ic|/etc/mkinitcpio.conf}} to successfully boot into the root filesystem.}}<br />
<br />
== Performance ==<br />
<br />
=== Sector size ===<br />
<br />
See [[Advanced Format#How to determine if HDD employ a 4k sector]].<br />
<br />
=== Discards ===<br />
{{note|Contrary to recommendations for SSDs, '''NVMe devices should not be issued discards'''.}}<br />
<br />
Discards are disabled by default on typical setups that use [[ext4]] and [[LVM]], but other filesystems might need discards to be disabled explicitly.<br />
<br />
Intel, as one device manufacturer, recommends not to enable discards at the filesystem level, but suggests the [[Solid State Drives#Apply periodic TRIM via fstrim]] method, or apply ''fstrim'' manually.[https://communities.intel.com/thread/75161?start=0&tstart=0]<br />
<br />
=== Airflow ===<br />
<br />
NVMe SSDs are known to be affected by high operating temperatures and will throttle performance over certain thresholds.[http://www.legitreviews.com/samsung-ssd-950-pro-512gb-nvme-pcie-ssd-review_174096/3]<br />
<br />
=== Testing ===<br />
<br />
Raw device performance tests can be run with {{pkg|hdparm}}:<br />
<br />
# hdparm -Tt --direct /dev/nvme0n1<br />
<br />
== References ==<br />
* [http://downloadmirror.intel.com/23929/eng/Intel_Linux_NVMe_Driver_Reference_Guide_330602-002.pdf Intel Linux NVMe driver reference]{{Dead link|2016|07|16}}</div>Docklandhttps://wiki.archlinux.org/index.php?title=User_talk:Dockland&diff=441619User talk:Dockland2016-07-16T11:05:39Z<p>Dockland: /* Dead links */</p>
<hr />
<div>== Dead links ==<br />
<br />
Hi,<br />
<br />
maybe you could flag dead links with [[Template:Dead link]] instead of removing them right away? Sometimes people can find similar resources and replace the old links with them, but when the old links have been removed, they can't do that because there is no hint.<br />
<br />
Thanks in any case for your contributions.<br />
<br />
[[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:53, 16 July 2016 (UTC)<br />
<br />
Thanks, will do. I'll revert the pages.</div>Docklandhttps://wiki.archlinux.org/index.php?title=Init&diff=441615Init2016-07-16T10:38:59Z<p>Dockland: /* See also */ removed dead link</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:Init]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Init Rosetta}}<br />
{{Related articles end}}<br />
<br />
{{Warning|Arch Linux only has official support for [[systemd]]. [https://lists.archlinux.org/pipermail/arch-general/2015-July/039460.html] When using a different init system, please mention so in support requests.}}<br />
<br />
[[Wikipedia:Init|Init]] is the first process started during system boot. It is a a daemon process that continues running until the system is shut down. Init is the direct or indirect ancestor of all other processes, and automatically adopts all orphaned processes. It is started by the kernel using a hard-coded filename; if the kernel is unable to start it, panic will result. Init is typically assigned process identifier 1.<br />
<br />
The init ''scripts'' (or ''rc'') are launched by the init process to guarantee basic functionality on system start and shutdown. This includes (un)mounting of [[file system]]s and launching of [[daemons]]. A ''service manager'' takes this one step further by providing active control over launched processes, or [[Wikipedia:Process Supervision|process supervision]]. An example is to monitor for crashes and restart processes accordingly.<br />
<br />
These components combine to the init ''system''. Some inits include the service manager in the init process, or have init scripts in close relation to them. These inits are below referred to as ''integrated'', though entries in different categories may explicitly depend on each other.<br />
<br />
== Inits (integrated) ==<br />
<br />
* {{App|[[systemd]]|Dependency-based init system with aggressive parallelization, process supervision using cgroups, and the ability to depend on a given mount point or dbus service.|http://freedesktop.org/wiki/Software/systemd/|{{Pkg|systemd}}}}<br />
* {{App|[[Wikipedia:Upstart|Upstart]]|Event-based init system which handles starting, stopping and supervising of tasks and services.|http://upstart.ubuntu.com/|{{AUR|upstart}}{{Broken package link|{{aur-mirror|upstart}}}}}}<br />
* {{App|initng|Dependency-based init system with parallelization and asynchronous start.|http://initng.sourceforge.net/trac|{{AUR|initng-git}}{{Broken package link|{{aur-mirror|initng-git}}}}}}<br />
* {{App|Epoch|Single-threaded init system designed for minimal footprint, compatibility and unified configuration.|http://universe2.us/epoch.html|}}{{AUR|epoch-init-system}}{{Broken package link|{{aur-mirror|epoch-init-system}}}}<br />
* {{App|finit|Fast and extensible init, originally based on EeePC fastinit.|https://github.com/troglobit/finit|{{AUR|finit-arc}}{{Broken package link|{{aur-mirror|finit-arc}}}} / {{AUR|finit-arc-git}}{{Broken package link|{{aur-mirror|finit-arc-git}}}}}}<br />
<br />
== Inits ==<br />
<br />
* {{App|[[BusyBox]]|Utilities for rescue and embedded systems.|http://busybox.net/|{{Pkg|busybox}}}}<br />
* {{App|[[SysVinit]]|Traditional System V init.|http://savannah.nongnu.org/projects/sysvinit|{{AUR|sysvinit}}}}<br />
* {{App|ninit|Fork from [http://www.fefe.de/minit/ minit]|http://riemann.fmi.uni-sofia.bg/ninit/|{{AUR|ninit}}}}<br />
* {{App|sinit|Simple init initially based on Rich Felker’s minimal init.|http://core.suckless.org/sinit|{{AUR|sinit}}}}<br />
<br />
== Init scripts ==<br />
<br />
* {{App|initscripts-fork|Maintained fork of SysVinit scripts in Arch Linux.|https://bitbucket.org/TZ86/initscripts-fork/overview|{{AUR|initscripts-fork}}}}<br />
* {{App|minirc|Minimal init script designed for BusyBox.|https://github.com/hut/minirc/|{{AUR|minirc-git}}}}<br />
* {{App|OpenRC Arch services|OpenRC service scripts compatible to Arch Linux.|https://github.com/andrewgregory/openrc-arch-services|{{AUR|openrc-arch-services-git}}}}<br />
* {{App|spark-rc|A simple rc script to kickstart your system.|https://gitlab.com/fbt/spark-rc|{{AUR|spark-rc}}}}<br />
* {{App|watchman-sm-services|Examples of services for watchman.|https://gitlab.com/fbt/watchman-services|{{AUR|watchman-sm-services-git}}}}<br />
<br />
== Service managers ==<br />
<br />
* {{App|daemontools|Collection of tools for managing UNIX services.|http://cr.yp.to/daemontools.html|{{AUR|daemontools}}}}<br />
* {{App|[[Monit]]|Monit is a process supervision tool for Unix and Linux. With monit, system status can be viewed directly from the command line, or via the native HTTP(S) web server.|http://mmonit.com/monit/|{{Pkg|monit}}}}<br />
* {{App|[[OpenRC]]|Dependency-based rc system that works with the system-provided init, normally SysVinit.|http://www.gentoo.org/proj/en/base/openrc/|{{AUR|openrc}}}}<br />
* {{App|perp|Persistent process (service) supervisor and managment framework for UNIX.|http://b0llix.net/perp/|{{AUR|perp}}}}<br />
* {{App|[[runit]]|UNIX init scheme with service supervision, a replacement for SysVinit, and other init schemes.|http://smarden.org/runit/|{{AUR|runit}}}}<br />
* {{App|s6|Small suite of programs for UNIX, designed to allow service supervision in the line of daemontools and runit.|http://skarnet.org/software/s6/|{{AUR|s6}}}}<br />
* {{App|watchman|A not-so-simple service manager for Linux.|https://gitlab.com/fbt/watchman|{{AUR|watchman-sm}}}}<br />
<br />
== Configuration ==<br />
<br />
=== Migrate running daemons ===<br />
<br />
To run daemons under the new init, save a list of running daemons:<br />
<br />
$ systemctl list-units --state=running "*.service" > daemons.list<br />
<br />
then configure the [[#Init scripts]] accordingly. See also [http://unix.stackexchange.com/questions/175380/how-to-list-all-running-daemons].<br />
<br />
Temporary files (''systemd-tmpfiles''), [[kernel modules]] and [[sysctl]] may also need configuration.<br />
<br />
=== logind ===<br />
<br />
[http://www.freedesktop.org/wiki/Software/systemd/logind/ logind] requires ''systemd'' to be the init process. [http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/] As such, [[General_troubleshooting#Session_permissions|local sessions]] and other functionality is not available.<br />
<br />
==== Device permissions ====<br />
<br />
Add users to the correct [[Users_and_groups#Group_list|groups]] for device access, and reboot. Current group membership should first be checked with {{ic|id ''user''}}. For example:<br />
<br />
# usermod -a -G video,audio,power,disk,storage,optical,lp,scanner ''user''<br />
<br />
See [[Policykit#Bypass password prompt]] to create group rules for use with Policykit.<br />
<br />
==== Rootless X (1.16) ====<br />
<br />
As {{ic|Xorg.wrap}} does not check if logind is active [https://bugs.freedesktop.org/show_bug.cgi?id=86975#c5], [[Xorg#Rootless Xorg (v1.16)|root rights for Xorg]] need be enabled manually:<br />
<br />
{{hc|1=/etc/X11/Xwrapper.config|2=<br />
needs_root_rights = yes<br />
}}<br />
<br />
==== Power management ====<br />
<br />
See [[pm-utils]] and [[acpid]] to replace [[Power_management#Power_management_with_systemd|Power management with systemd]].<br />
<br />
=== Scheduled tasks ===<br />
<br />
Arch uses [[Systemd#Timers|timer]] files instead of [[cron]] by default. See [https://github.com/notfoss/archlinux-cronjobs archlinux-cronjobs] for basic cron jobs.<br />
<br />
=== Dbus ===<br />
<br />
User instances of ''dbus-daemon'' are launched by [[systemd/User#D-Bus|systemd/User]]. [https://www.archlinux.org/news/d-bus-now-launches-user-buses/] When requring IPC between desktop applications, restore {{ic|30-dbus.sh}}:<br />
<br />
{{hc|1=/etc/X11/xinit/xinitrc.d/30-dbus.sh|2=<br />
#!/bin/bash<br />
<br />
# launches a session dbus instance<br />
if [ -z "${DBUS_SESSION_BUS_ADDRESS-}" ] && type dbus-launch >/dev/null; then<br />
eval $(dbus-launch --sh-syntax --exit-with-session)<br />
fi<br />
}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== systemd-nspawn ===<br />
<br />
[[systemd-nspawn]] is a tool for systemd systems. Since Linux 2.6.19 it is however possible to run systemd on a non-systemd system by using PID namespace. For it, the kernel needs to be configured with {{ic|CONFIG_PID_NS}} and {{ic|CONFIG_NAMESPACES}}). <br />
<br />
The PID namespace creates a new hierarchy of processes starting with PID 1. In addition to this, systemd requires a chrooted root filesystem to be mounted. Hence, you have to at least make a bind mount, because otherwise some services will fail with <br />
<br />
"Failed at step NAMESPACE spawning" due to "Invalid operation" <br />
<br />
as systemd tries to remount the root with {{ic|private}} option. <br />
<br />
To setup a chroot with a new PID namespace you can use jchroot.[http://vincent.bernat.im/en/blog/2011-jchroot-isolation.html] [https://github.com/vincentbernat/jchroot]. <br />
Make sure not to mount {{ic|/proc}} inside the new root before chrooting, otherwise systemd will detect the chroot environment. You can mount it later once systemd is running.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.debian.org/Debate/initsystem Debian init system debate]<br />
* [http://skarnet.org/software/s6/s6-svscan-1.html How to run s6-svscan as process 1]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=162606&p=1 Replace systemd with busybox + minirc]<br />
* [http://www.troubleshooters.com/linux/init/manjaro_experiments.htm Experiments of Manjaro]<br />
* [https://felipec.wordpress.com/2013/11/04/init/ Demystifying the init system]<br />
* [http://blog.darknedgy.net/technology/2015/09/05/0/ A history of modern init systems (1992-2015)]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=441614Unified Extensible Firmware Interface2016-07-16T10:37:35Z<p>Dockland: /* See also */ removed dead links</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|EFI System Partition}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related|UEFI/Hardware}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations may carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular mainboard model before proceeding.}}<br />
<br />
The [http://www.uefi.org/ Unified Extensible Firmware Interface] (EFI or UEFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications. <br />
<br />
It is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI Boot Loaders, see [[Boot loaders]].<br />
<br />
== UEFI versions ==<br />
* UEFI started as Intel's EFI in versions 1.x. <br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0. <br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. <br />
* As of 15 April 2015, UEFI Specification 2.5 is the most recent version. <br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
== UEFI Firmware bitness ==<br />
<br />
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. <br />
<br />
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 Intel Cloverfield ultrabooks and some older Intel Server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
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.<br />
<br />
=== Non Macs ===<br />
<br />
Check whether the dir {{ic|/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)<br />
<br />
{{Note|Intel Atom System-on-Chip systems ship with 32-bit UEFI (as on 2 November 2013). See [[#Using GRUB]] for more info.}}<br />
<br />
=== Apple Macs ===<br />
<br />
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. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
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.<br />
<br />
== Linux Kernel Config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI Runtime Variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt .<br />
<br />
== UEFI Variables ==<br />
<br />
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. You can get the list using <br />
$ efivar -l<br />
<br />
=== UEFI Variables Support in Linux Kernel ===<br />
<br />
Linux kernel exposes EFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# Kernel processor [[#UEFI Firmware bitness|bitness]] and EFI processor bitness should match.<br />
# Kernel should be booted in EFI mode (via [[EFISTUB]] or any [[Boot loaders|EFI boot loader]], not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}) the EFI Variables without any error.<br />
<br />
If EFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify efi variables data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel efi variable storage space check that may prevent writing/modification of efi variables.<br />
<br />
{{Note|{{ic|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.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
{{Warning|1=''efivars'' is mounted writeable by default [https://github.com/systemd/systemd/issues/2402], which may cause permanent damage to the system. [https://bbs.archlinux.org/viewtopic.php?id=207549] As such, consider mounting ''efivars'' read-only ({{ic|-o ro}}) as described below. Note that when it is mounted read-only, tools such as ''efibootmgr'' and bootloaders will not be able to change boot settings, nor will commands like {{ic|systemctl reboot --firmware-setup}} work.}}<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools]] like {{ic|efibootmgr}}:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
To mount {{ic|efivarfs}} read-only during boot, add to {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|2=<br />
efivarfs /sys/firmware/efi/efivars efivarfs '''ro''',nosuid,nodev,noexec,noatime 0 0<br />
}}<br />
<br />
To remount with write support, run:<br />
<br />
# mount -o remount /sys/firmware/efi/efivars -o '''rw''',nosuid,nodev,noexec,noatime<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# '''efivar''' - Library and Tool to manipulate UEFI Variables (used by efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings - https://github.com/vathpela/efibootmgr - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# '''uefivars''' - Dumps list of EFI variables with some additional PCI related info (uses efibootmgr code internally) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 supports only efivarfs and https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 supports only sysfs-efivars . AUR package {{AUR|uefivars-git}} <br />
# '''efitools''' - Tools for manipulating UEFI secure boot platforms - {{Pkg|efitools}} or {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}}{{Broken package link|{{aur-mirror|fwts}}}} (along with {{AUR|fwts-efi-runtime-dkms}}{{Broken package link|{{aur-mirror|fwts-efi-runtime-dkms}}}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Note|<br />
* If {{ic|efibootmgr}} completely fails to work in your system, you can reboot into UEFI Shell v2 and use {{ic|bcfg}} command to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage uefi boot entries from within its boot-time interface. For example, some ASUS firmwares have an "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
}}<br />
<br />
Assuming the boot-loader file to be launched is {{ic|/boot/efi/EFI/refind/refind_x64.efi}}, {{ic|/boot/efi/EFI/refind/refind_x64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the EFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here {{ic|X}} and {{ic|Y}} are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , {{ic|1=X==a}} {{ic|1=Y==1}}).<br />
<br />
To determine the actual device path for the EFI System Partition (assuming mountpoint {{ic|/boot/efi}} for example) (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Verify that uefi variables support in kernel is working properly by running:<br />
<br />
# efivar -l<br />
<br />
If efivar lists the uefi variables without any error, then you can proceed. If not, check whether all the conditions in [[#Requirements for UEFI variable support]] are met.<br />
<br />
Then create the boot entry using efibootmgr as follows:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"<br />
<br />
{{Note|1=UEFI uses backward slash {{ic|\}} as path separator (similar to Windows paths), but the official {{Pkg|efibootmgr}} pkg support passing unix-style paths with forward-slash {{ic|/}} as path-separator for the {{ic|-l}} option. Efibootmgr internally converts {{ic|/}} to {{ic|\}} before encoding the loader path. The relevant git commit that incorporated this feature in efibootmgr is http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .}}<br />
<br />
In the above command {{ic|/boot/efi/EFI/refind/refind_x64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/refind/refind_x64.efi}}.<br />
<br />
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 [http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/plain/README efibootmgr GIT README] .<br />
<br />
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 {{ic|\EFI\refind\refindx64.efi}} or {{ic|\efi\refind\refind_x64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== UEFI Shell ==<br />
<br />
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. <br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project:<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/tree/master/ShellBinPkg Precompiled UEFI Shell v2 binaries] (may not be up-to-date)<br />
* [https://github.com/tianocore/edk2/tree/master/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream)<br />
<br />
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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI System Partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/efi/boot/bootx64.efi}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows 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.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. You can download a [http://dl.dropbox.com/u/17629062/Shell2.zip modified UEFI Shell v2 binary] which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|fs0:}} is the mapping corresponding to the EFI System Partition and {{ic|fs0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|fs0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> fs0:<br />
fs0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI System Partition ({{ic|fs0:}} in the firmware),<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI Linux Hardware Compatibility ==<br />
<br />
See [[Unified Extensible Firmware Interface/Hardware]] for more information.<br />
<br />
== UEFI Bootable Media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI Bootable USB]]<br />
<br />
=== Remove UEFI boot support from Optical Media ===<br />
<br />
{{Note|This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media), not from a USB flash drive.}}<br />
<br />
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.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI Optical Media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for Virtual Machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI Mode ===<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen UEFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop. <br />
* If your motherboard is booting the default UEFI path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different UEFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set {bootmgr} path \EFI\''path''\''to''\''app.efi''}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set {fwbootmgr} DEFAULT ''{copied boot identifier}''}}<br />
*# Open ''gpedit'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
* This issue can occur either due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
* If the issue is not due to KMS, then it may be due to bug in [[EFISTUB]] booting (see {{Bug|33745}} and [https://bbs.archlinux.org/viewtopic.php?id=156670] for more information.). Both Official ISO ([[Archiso]]) and [[Archboot]] iso use EFISTUB (via [[Gummiboot]] Boot Manager for menu) for booting the kernel in UEFI mode. In such a case you have to use [[GRUB]] as the USB's UEFI bootloader by following the below section.<br />
<br />
==== Using GRUB ====<br />
{{Deletion|Through bug report this issue should be fixed in kernel 3.16 and after, so this workaround is not needed anymore.}}<br />
{{Tip|The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].}}<br />
<br />
* [[USB flash installation media#BIOS_and_UEFI_Bootable_USB|Create an USB Flash Installation]]<br />
<br />
* Backup {{ic|EFI/boot/loader.efi}} to {{ic|EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_standalone|Create a GRUB standalone image]] and copy the generate {{ic|grub*.efi}} to the USB as {{ic|EFI/boot/loader.efi}}, {{ic|EFI/boot/bootx64.efi}} and/or {{ic|EFI/boot/bootia32.efi}} (useful when running on a 32-bit UEFI)<br />
<br />
* Create {{ic|EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{hc|grub.cfg for Official ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap<br />
initrd /arch/boot/x86_64/archiso.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
{{hc|grub.cfg for Archboot ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux x86_64 Archboot" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap<br />
initrd /boot/initramfs_x86_64.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On some UEFI motherboards like boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the EFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the {{ic|.efi}} file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
FS1:<br />
cd EFI<br />
mkdir Microsoft<br />
cd Microsoft<br />
mkdir Boot<br />
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore 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<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://dl.dropbox.com/u/17629062/Shell2.zip UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=441613Unified Extensible Firmware Interface2016-07-16T10:36:50Z<p>Dockland: /* See also */ removed dead link</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|EFI System Partition}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related|UEFI/Hardware}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations may carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular mainboard model before proceeding.}}<br />
<br />
The [http://www.uefi.org/ Unified Extensible Firmware Interface] (EFI or UEFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications. <br />
<br />
It is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI Boot Loaders, see [[Boot loaders]].<br />
<br />
== UEFI versions ==<br />
* UEFI started as Intel's EFI in versions 1.x. <br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0. <br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. <br />
* As of 15 April 2015, UEFI Specification 2.5 is the most recent version. <br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
== UEFI Firmware bitness ==<br />
<br />
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. <br />
<br />
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 Intel Cloverfield ultrabooks and some older Intel Server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
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.<br />
<br />
=== Non Macs ===<br />
<br />
Check whether the dir {{ic|/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)<br />
<br />
{{Note|Intel Atom System-on-Chip systems ship with 32-bit UEFI (as on 2 November 2013). See [[#Using GRUB]] for more info.}}<br />
<br />
=== Apple Macs ===<br />
<br />
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. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
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.<br />
<br />
== Linux Kernel Config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI Runtime Variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt .<br />
<br />
== UEFI Variables ==<br />
<br />
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. You can get the list using <br />
$ efivar -l<br />
<br />
=== UEFI Variables Support in Linux Kernel ===<br />
<br />
Linux kernel exposes EFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# Kernel processor [[#UEFI Firmware bitness|bitness]] and EFI processor bitness should match.<br />
# Kernel should be booted in EFI mode (via [[EFISTUB]] or any [[Boot loaders|EFI boot loader]], not via BIOS/CSM or Apple's "bootcamp" which is also BIOS/CSM).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}) the EFI Variables without any error.<br />
<br />
If EFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify efi variables data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel efi variable storage space check that may prevent writing/modification of efi variables.<br />
<br />
{{Note|{{ic|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.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
{{Warning|1=''efivars'' is mounted writeable by default [https://github.com/systemd/systemd/issues/2402], which may cause permanent damage to the system. [https://bbs.archlinux.org/viewtopic.php?id=207549] As such, consider mounting ''efivars'' read-only ({{ic|-o ro}}) as described below. Note that when it is mounted read-only, tools such as ''efibootmgr'' and bootloaders will not be able to change boot settings, nor will commands like {{ic|systemctl reboot --firmware-setup}} work.}}<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools]] like {{ic|efibootmgr}}:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
To mount {{ic|efivarfs}} read-only during boot, add to {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|2=<br />
efivarfs /sys/firmware/efi/efivars efivarfs '''ro''',nosuid,nodev,noexec,noatime 0 0<br />
}}<br />
<br />
To remount with write support, run:<br />
<br />
# mount -o remount /sys/firmware/efi/efivars -o '''rw''',nosuid,nodev,noexec,noatime<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# '''efivar''' - Library and Tool to manipulate UEFI Variables (used by efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings - https://github.com/vathpela/efibootmgr - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# '''uefivars''' - Dumps list of EFI variables with some additional PCI related info (uses efibootmgr code internally) - https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 supports only efivarfs and https://github.com/fpmurphy/Various/tree/master/uefivars-1.0 supports only sysfs-efivars . AUR package {{AUR|uefivars-git}} <br />
# '''efitools''' - Tools for manipulating UEFI secure boot platforms - {{Pkg|efitools}} or {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}}{{Broken package link|{{aur-mirror|fwts}}}} (along with {{AUR|fwts-efi-runtime-dkms}}{{Broken package link|{{aur-mirror|fwts-efi-runtime-dkms}}}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Note|<br />
* If {{ic|efibootmgr}} completely fails to work in your system, you can reboot into UEFI Shell v2 and use {{ic|bcfg}} command to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage uefi boot entries from within its boot-time interface. For example, some ASUS firmwares have an "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
}}<br />
<br />
Assuming the boot-loader file to be launched is {{ic|/boot/efi/EFI/refind/refind_x64.efi}}, {{ic|/boot/efi/EFI/refind/refind_x64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the EFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here {{ic|X}} and {{ic|Y}} are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , {{ic|1=X==a}} {{ic|1=Y==1}}).<br />
<br />
To determine the actual device path for the EFI System Partition (assuming mountpoint {{ic|/boot/efi}} for example) (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Verify that uefi variables support in kernel is working properly by running:<br />
<br />
# efivar -l<br />
<br />
If efivar lists the uefi variables without any error, then you can proceed. If not, check whether all the conditions in [[#Requirements for UEFI variable support]] are met.<br />
<br />
Then create the boot entry using efibootmgr as follows:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "rEFInd"<br />
<br />
{{Note|1=UEFI uses backward slash {{ic|\}} as path separator (similar to Windows paths), but the official {{Pkg|efibootmgr}} pkg support passing unix-style paths with forward-slash {{ic|/}} as path-separator for the {{ic|-l}} option. Efibootmgr internally converts {{ic|/}} to {{ic|\}} before encoding the loader path. The relevant git commit that incorporated this feature in efibootmgr is http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/commit/?id=f38f4aaad1dfa677918e417c9faa6e3286411378 .}}<br />
<br />
In the above command {{ic|/boot/efi/EFI/refind/refind_x64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/refind/refind_x64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/refind/refind_x64.efi}}.<br />
<br />
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 [http://linux.dell.com/cgi-bin/cgit.cgi/efibootmgr.git/plain/README efibootmgr GIT README] .<br />
<br />
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 {{ic|\EFI\refind\refindx64.efi}} or {{ic|\efi\refind\refind_x64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== UEFI Shell ==<br />
<br />
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. <br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project:<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/tree/master/ShellBinPkg Precompiled UEFI Shell v2 binaries] (may not be up-to-date)<br />
* [https://github.com/tianocore/edk2/tree/master/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream)<br />
<br />
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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI System Partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/efi/boot/bootx64.efi}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows 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.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. You can download a [http://dl.dropbox.com/u/17629062/Shell2.zip modified UEFI Shell v2 binary] which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|fs0:}} is the mapping corresponding to the EFI System Partition and {{ic|fs0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|fs0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> fs0:<br />
fs0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI System Partition ({{ic|fs0:}} in the firmware),<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI Linux Hardware Compatibility ==<br />
<br />
See [[Unified Extensible Firmware Interface/Hardware]] for more information.<br />
<br />
== UEFI Bootable Media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI Bootable USB]]<br />
<br />
=== Remove UEFI boot support from Optical Media ===<br />
<br />
{{Note|This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media), not from a USB flash drive.}}<br />
<br />
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.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI Optical Media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for Virtual Machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -drive file=/usr/share/ovmf/ovmf_x64.bin,format=raw,if=pflash,readonly<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
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. <br />
<br />
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.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI Mode ===<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen UEFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop. <br />
* If your motherboard is booting the default UEFI path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different UEFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set {bootmgr} path \EFI\''path''\''to''\''app.efi''}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set {fwbootmgr} DEFAULT ''{copied boot identifier}''}}<br />
*# Open ''gpedit'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
* This issue can occur either due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
* If the issue is not due to KMS, then it may be due to bug in [[EFISTUB]] booting (see {{Bug|33745}} and [https://bbs.archlinux.org/viewtopic.php?id=156670] for more information.). Both Official ISO ([[Archiso]]) and [[Archboot]] iso use EFISTUB (via [[Gummiboot]] Boot Manager for menu) for booting the kernel in UEFI mode. In such a case you have to use [[GRUB]] as the USB's UEFI bootloader by following the below section.<br />
<br />
==== Using GRUB ====<br />
{{Deletion|Through bug report this issue should be fixed in kernel 3.16 and after, so this workaround is not needed anymore.}}<br />
{{Tip|The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].}}<br />
<br />
* [[USB flash installation media#BIOS_and_UEFI_Bootable_USB|Create an USB Flash Installation]]<br />
<br />
* Backup {{ic|EFI/boot/loader.efi}} to {{ic|EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_standalone|Create a GRUB standalone image]] and copy the generate {{ic|grub*.efi}} to the USB as {{ic|EFI/boot/loader.efi}}, {{ic|EFI/boot/bootx64.efi}} and/or {{ic|EFI/boot/bootia32.efi}} (useful when running on a 32-bit UEFI)<br />
<br />
* Create {{ic|EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{hc|grub.cfg for Official ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_YYYYMM add_efi_memmap<br />
initrd /arch/boot/x86_64/archiso.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCH_YYYYMM<br />
chainloader /EFI/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
{{hc|grub.cfg for Archboot ISO|<nowiki><br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux x86_64 Archboot" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
linux /boot/vmlinuz_x86_64 cgroup_disable=memory loglevel=7 add_efi_memmap<br />
initrd /boot/initramfs_x86_64.img<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v2" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --file /boot/vmlinuz_x86_64<br />
chainloader /EFI/tools/shellx64_v1.efi<br />
}<br />
</nowiki>}}<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On some UEFI motherboards like boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the EFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the {{ic|.efi}} file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
FS1:<br />
cd EFI<br />
mkdir Microsoft<br />
cd Microsoft<br />
mkdir Boot<br />
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [http://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://uefidk.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]<br />
* [http://uefidk.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]<br />
* [http://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore 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<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://dl.dropbox.com/u/17629062/Shell2.zip UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware - from Clover efiboot]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Arch_boot_process&diff=441612Arch boot process2016-07-16T10:33:19Z<p>Dockland: /* See also */ removed dead link</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:About Arch]]<br />
[[ar:Arch boot process]]<br />
[[cs:Arch boot process]]<br />
[[es:Arch boot process]]<br />
[[fr:Processus de boot]]<br />
[[it:Arch boot process]]<br />
[[ja:Arch ブートプロセス]]<br />
[[ru:Arch boot process]]<br />
[[zh-cn:Arch boot process]]<br />
{{Related articles start}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|mkinitcpio}}<br />
{{Related|init}}<br />
{{Related|systemd}}<br />
{{Related|fstab}}<br />
{{Related|Autostarting}}<br />
{{Related articles end}}<br />
<br />
In order to boot Arch Linux, a Linux-capable [[boot loader]] such as [[GRUB]] or [[Syslinux]] must be installed to the [[Master Boot Record]] or the [[GUID Partition Table]]. The boot loader is responsible for loading the kernel and [[initial ramdisk]] before initiating the boot process. The procedure is quite different for [[Wikipedia:BIOS|BIOS]] and [[UEFI]] systems, the detailed description is given on this or linked pages.<br />
<br />
== Firmware types ==<br />
=== BIOS ===<br />
<br />
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. <br />
<br />
The BIOS loads the beginning 512 bytes ([[Master Boot Record]]) of the first valid disk in the BIOS disk order. Of these 512 bytes, the first 440 contains the first stage of a boot loader like [[GRUB]], [[Syslinux]] or [[LILO]]. Since very little can be achieved by a program of this size, the second stage (residing on the next disk sectors) is loaded from here and looks up a file stored on the partition itself (the actual bootloader). This then loads an operating system by either chain-loading or directly loading the operating system kernel.<br />
<br />
=== UEFI ===<br />
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.<br />
<br />
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 Intel Macs can also access HFS/HFS+ filesystems, in addition to the mentioned ones.<br />
<br />
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 {{ic|<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 or (less commonly) FAT16.<br />
<br />
== System initialization ==<br />
<br />
=== Under BIOS ===<br />
<br />
# System switched on - [[Wikipedia:Power-on self-test|Power-on self-test]] or POST process<br />
# After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.)<br />
# BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order<br />
# The MBR boot code then takes control from BIOS and launches its next stage code (if any) (mostly [[boot loader]] code)<br />
# The launched actual boot loader<br />
<br />
=== Under UEFI ===<br />
<br />
# System switched on. The Power On Self Test (POST) is executed.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware reads the boot entries in the firmware's boot manager to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware launches the UEFI application.<br />
#* This could be the Arch kernel itself (since [[EFISTUB]] is enabled by default).<br />
#* It could be some other application such as a shell or a graphical boot manager.<br />
#* Or the boot entry could simply be a disk. In this case the firmware looks for an [[EFI System Partition]] on that disk and tries to run the fallback UEFI application {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} on 32-bit systems). This is how UEFI bootable thumb drives work.<br />
<br />
If [[Secure Boot]] is enabled, the boot process will verify authenticity of the EFI binary by signature.<br />
<br />
{{Note|On some (poorly-designed) UEFI systems the only way to boot is using a disk boot entry with the fallback UEFI application path.}}<br />
<br />
=== Multibooting in UEFI ===<br />
<br />
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 [[boot loader]] to load another to switch OSes.<br />
<br />
See also [[Dual boot with Windows]].<br />
<br />
== Boot loader ==<br />
<br />
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] based on config files. <br />
<br />
== Kernel ==<br />
The kernel is the core of an operating system. It functions on a low level (''kernelspace'') interacting between the hardware of the machine and the programs which use the hardware to run. To make efficient use of the CPU, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion of many tasks being executed simultaneously.<br />
<br />
== initramfs ==<br />
After the kernel is loaded, it unpacks the [[initramfs]] (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes {{ic|/init}} as the first process. The ''early userspace'' starts.<br />
<br />
The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem (see [[FHS]] for details). This means that any modules that are required for devices like IDE, SCSI, SATA, USB/FW (if booting from an external drive) must be loadable from the initramfs if not built into the kernel; once the proper modules are loaded (either explicitly via a program or script, or implicitly via [[udev]]), the boot process continues. For this reason, the initramfs only needs to contain the modules necessary to access the root filesystem; it does not need to contain every module one would ever want to use. The majority of modules will be loaded later on by udev, during the init process.<br />
<br />
== Init process ==<br />
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem. {{ic|/sbin/init}} is executed, replacing the {{ic|/init}} process. Arch uses [[systemd]] as the default [[init]].<br />
<br />
== Getty ==<br />
[[init]] calls [[getty]] once for each [[Wikipedia:Virtual console|virtual terminal]] (typically six of them), which initializes each tty and asks for a username and password. Once the username and password are provided, getty checks them against {{ic|/etc/passwd}}, then calls [[#Login|login]], which begins a session for the user, and executes the user's shell according to {{ic|/etc/passwd}}. Alternatively, getty may start a display manager if one is present on the system.<br />
<br />
== Display Manager ==<br />
A [[display manager]] can be configured to replace the getty login prompt on a tty.<br />
<br />
== Login ==<br />
The ''login'' program begins a session for the user by setting environment variables and starting the user's shell, based on {{ic|/etc/passwd}}.<br />
<br />
=== Message of the day ===<br />
<br />
The ''login'' program displays the contents of [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) after a successful login, just before it executes the login shell.<br />
<br />
It is a good place to display your Terms of Service to remind users of your local policies or anything you wish to tell them.<br />
<br />
== Shell ==<br />
Once the user's [[shell]] is started, it will typically run a runtime configuration file, such as [[bashrc]], before presenting a prompt to the user. If the account is configured to [[Start X at login]], the runtime configuration file will call [[startx]] or [[xinit]].<br />
<br />
== xinit ==<br />
[[xinit]] runs the user's [[xinitrc]] runtime configuration file, which normally starts a [[window manager]]. When the user is finished and exits the window manager, xinit, startx, the shell, and login will terminate in that order, returning to getty.<br />
<br />
== See also ==<br />
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]<br />
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]<br />
* [[Wikipedia:Linux startup process]]<br />
* [[Wikipedia:initrd]]<br />
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]<br />
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]</div>Docklandhttps://wiki.archlinux.org/index.php?title=Talk:Solid_state_drive/NVMe&diff=441606Talk:Solid state drive/NVMe2016-07-16T09:17:14Z<p>Dockland: /* Link to Intel-wesite does not work */</p>
<hr />
<div>== Add the reason/link as to why discard is not recommended for NVMe SSDs? ==<br />
<br />
The note merely states it shouldn't be done, but there is no reason or link to the source that supports the statement provided. [[User:Soukyuu|Soukyuu]] ([[User talk:Soukyuu|talk]]) 21:54, 12 February 2016 (UTC)<br />
<br />
== "GRUB does not support booting from /boot partitions that reside on NVMe drives, see FS#47447" ==<br />
<br />
This is not true. I ran into an issue in this regard and fixed it somehow (I'm booting from /boot on NVMe at this moment). Can't remember how I fixed this. Will post back if I figure it out. [[User:Greyltc|Greyltc]] ([[User talk:Greyltc|talk]]) 16:28, 3 March 2016 (UTC)<br />
<br />
== Link to Intel-website does not work ==<br />
<br />
The link http://downloadmirror.intel.com/23929/eng/Intel_Linux_NVMe_Driver_Reference_Guide_330602-002.pdf is dead. There is a page: http://www.intel.com/content/dam/support/us/en/documents/ssdc/data-center-ssds/Intel_Linux_NVMe_Guide_330602-002.pdf that is targeted towards developers. But I don't know it it's applicable to this article. <br />
The Wiki states that discard is not recommended on Nvme drives, but there is no information why.</div>Docklandhttps://wiki.archlinux.org/index.php?title=Talk:Solid_state_drive/NVMe&diff=441605Talk:Solid state drive/NVMe2016-07-16T09:17:02Z<p>Dockland: /* Link to Intel-wesite does not work */ new section</p>
<hr />
<div>== Add the reason/link as to why discard is not recommended for NVMe SSDs? ==<br />
<br />
The note merely states it shouldn't be done, but there is no reason or link to the source that supports the statement provided. [[User:Soukyuu|Soukyuu]] ([[User talk:Soukyuu|talk]]) 21:54, 12 February 2016 (UTC)<br />
<br />
== "GRUB does not support booting from /boot partitions that reside on NVMe drives, see FS#47447" ==<br />
<br />
This is not true. I ran into an issue in this regard and fixed it somehow (I'm booting from /boot on NVMe at this moment). Can't remember how I fixed this. Will post back if I figure it out. [[User:Greyltc|Greyltc]] ([[User talk:Greyltc|talk]]) 16:28, 3 March 2016 (UTC)<br />
<br />
== Link to Intel-wesite does not work ==<br />
<br />
The link http://downloadmirror.intel.com/23929/eng/Intel_Linux_NVMe_Driver_Reference_Guide_330602-002.pdf is dead. There is a page: http://www.intel.com/content/dam/support/us/en/documents/ssdc/data-center-ssds/Intel_Linux_NVMe_Guide_330602-002.pdf that is targeted towards developers. But I don't know it it's applicable to this article. <br />
The Wiki states that discard is not recommended on Nvme drives, but there is no information why.</div>Dockland