https://wiki.archlinux.org/api.php?action=feedcontributions&user=The.ridikulus.rat&feedformat=atomArchWiki - User contributions [en]2024-03-19T02:35:10ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=557993User:The.ridikulus.rat2018-12-01T17:45:13Z<p>The.ridikulus.rat: </p>
<hr />
<div>Hello, I am Keshav. I have contributed and edited various wiki pages, notably those related to [[Boot Loaders]], [[UEFI]] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/the.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/KA2108 GitHub], [https://bitbucket.org/KA2108/ Bitbucket] and [https://gitlab.com/KA2108 Gitlab].<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=557992User:The.ridikulus.rat2018-12-01T17:42:31Z<p>The.ridikulus.rat: Updated links</p>
<hr />
<div>Hi, I am Keshav. I have contributed and edited various wiki pages, notably those related to [[Boot Loaders]], [[UEFI]] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/the.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/KA2108 GitHub], [https://bitbucket.org/KA2108/ Bitbucket] and [https://gitlab.com/KA2108 Gitlab].<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=414493User:The.ridikulus.rat2016-01-05T22:19:19Z<p>The.ridikulus.rat: Fix Github, Bitbucket and Gitlab links</p>
<hr />
<div>Hi, I am Keshav Amburay. I am native of Tamil Nadu, India but I currently reside in USA. My native language is Tamil but I actually did my schooling in English so I am quiet fluent in it. I also understand Hindi, and know beginner level German.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulusrat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/the.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/KeshavA2015 GitHub], [https://bitbucket.org/KeshavA2015/ Bitbucket] and [https://gitlab.com/u/KeshavA2015 Gitlab]. I also co-maintain [[Archboot]] installer code.<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=378045User:The.ridikulus.rat2015-06-10T03:27:17Z<p>The.ridikulus.rat: </p>
<hr />
<div>Hi, I am Keshav Amburay. I am native of Tamil Nadu, India but I currently reside in USA. My native language is Tamil but I actually did my schooling in English so I am quiet fluent in it. I also understand Hindi, and know beginner level German.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulusrat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/the.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/keshav21 GitHub], [https://bitbucket.org/keshav21 Bitbucket] and [https://gitlab.com/u/keshav21 Gitlab]. I also co-maintain [[Archboot]] installer code.<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=378044User:The.ridikulus.rat2015-06-10T03:26:22Z<p>The.ridikulus.rat: </p>
<hr />
<div>Hi, I am Keshav Amburay. I am native of Tamil Nadu, India but I currently reside in USA. My native language is Tamil but I actually did my schooling in English so I am quiet fluent in it. I also understand Hindi, and know beginner level German.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulusrat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/ridikulusrat]].<br />
<br />
I also maintain few git repos at [https://github.com/keshav21 GitHub], [https://bitbucket.org/keshav21 Bitbucket] and [https://gitlab.com/u/keshav21 Gitlab]. I also co-maintain [[Archboot]] installer code.<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=368041User:The.ridikulus.rat2015-03-31T19:05:40Z<p>The.ridikulus.rat: </p>
<hr />
<div>Hi, This is Keshav Amburay. I am native of Chennai, Tamil Nadu, India but I currently reside in Indiana, USA. My native language is Tamil but I actually did most of my schooling in English so I am quiet proficient in it, though not to the extent of a native speaker. I also understand Hindi, and know beginner level German.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulus.rat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/The.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/the-ridikulus-rat GitHub], [https://bitbucket.org/the_ridikulus_rat Bitbucket] and [https://gitorious.org/~the-ridikulus-rat Gitorious]. I also co-maintain [[Archboot]] installer code.<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=368040User:The.ridikulus.rat2015-03-31T19:05:29Z<p>The.ridikulus.rat: </p>
<hr />
<div>Hi, This is Keshav Amburay. I am native of Chennai, Tamil Nadu, India but I currently reside in Indiana, USA. My native language is Tamil but I actually did most of my schooling in English so I am quiet proficient in it, though not to the extent of a native speaker. I also understand Hindi, and know beginner level German.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulus.rat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/The.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/the-ridikulus-rat GitHub], [https://bitbucket.org/the_ridikulus_rat Bitbucket] and [https://gitorious.org/~the-ridikulus-rat Gitorious]. I also co-maintain [[Archboot]] installer code.<br />
<br />
For my system info please refer to [[HCL/Firmwares/UEFI#Lenovo_Thinkpad_Edge_E430_3254-DAQ]].<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User_talk:The.ridikulus.rat&diff=368039User talk:The.ridikulus.rat2015-03-31T19:03:28Z<p>The.ridikulus.rat: Fix my Name</p>
<hr />
<div>== Question about edit to [[Beginners' Guide]] ==<br />
<br />
Hi,<br />
<br />
I noticed your recent edits in the [[Beginners' Guide]], where you stated that the --target parameter is required. The man page however states that it defaults to the current platform (should be sufficient for beginners). I also just tested this (at least for BIOS), and it seems to work fine without the parameter.<br />
<br />
Can you explain why it is needed?<br />
<br />
Thanks --[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 20:43, 28 August 2013 (UTC)<br />
<br />
AFAIK in the initial release of grub 2.00 grub-install explicitly required the user to provide the --target parameter, but then in some later bzr snapshot grub-install tries to guess the platform. In my experience grub-install defaults to i386-pc (BIOS) target most of the time, even in case of x86_64-efi (UEFI) system. I suggest changing all grub-install commands across the wiki to use --target parameter to remove this confusion. -- [[User:The.ridikulus.rat|Keshav Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 15:21, 29 August 2013 (UTC)<br />
<br />
:Ok, I understand, I thought the 'guessing' was more robust and failure-proof. Thanks for the reply! :) --[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 19:47, 29 August 2013 (UTC)<br />
<br />
----<br />
<br />
<br />
Hi,<br />
<br />
I noticed your recent changes to the Beginner's Guide on the 18th September, particularly around EFISTUB. You have certainly managed to reduce the number of lines on the page which is good.<br />
<br />
However I wanted to confirm that the user really is no longer required to reload the efivars module before chroot ? I read your entry about Jones' new and improved efibootmgr and this should mean that the module reload is no longer required, but has the fork been mainlined into the Arch core repository yet ?<br />
<br />
Also is there a way to simplify the call to efibootmgr especially to be easier for new Archers or at least some way to make it easier. For example : '''"root=''/dev/sdaX''''' may be a little more welcoming than '''"root=PARTUUID=xxxxxxxxxxxxxxxxx"'''.<br />
What do you think ? <br />
Thanks. [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 19:41, 18 September 2013 (UTC)<br />
<br />
<br />
From core/linux-3.11.1-1 onwards efivars module is not even compiled in the kernel https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=ebf4d782ffe29e3b00e93011a493cbedffbd7415 . This is a deliberate change made by the devs http://www.mail-archive.com/arch-dev-public@archlinux.org/msg21788.html . THis chaneg was made only after new efibootmgr moved to core, see 'Upstream URL' in https://www.archlinux.org/packages/core/x86_64/efibootmgr/ .<br />
<br />
Reg /dev/sdaX vs PARTUUID, sdaX is very ambiguous and not recommended even in case of bios boot. IN case of UEFI boot, since we are already using GPT, PARTUUIDs are the best FS-independent unambiguous way of specifying a partition. You can even mention (FS) UUID here but in case of GPT I recommend PARTUUID. Even if they are no Archers, they should not be simply conpy-pasting the commands from this page. They should understand what efibootmgr is, what PARTUUID is etc. and then type the command on their own. My intention is not be more welcoming to newbies. I just don't want them to come back later complaining sdaX is not the partition they want when they make some changes in their system and then it refuses to boot due to using ambiguous sdaX.<br />
-- [[User:The.ridikulus.rat|Keshav Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 04:43, 19 September 2013 (UTC)<br />
<br />
<br />
<br />
Hi Keshav,<br />
<br />
Thanks for the full and prompt reply.<br />
<br />
I am still on a 3.10 series kernel and was unaware of the recent changes that you mentioned. The links were informative and your information has brought me up to date, cheers.<br />
<br />
I take your point about /dev/sdaX being more ambiguous than UUIDs and I agree that no-one should be copy-pasting instructions from the guide into their terminal (I hope no-one actually does that). You are right, it is important that everyone should be trying to understand what they are doing.<br />
<br />
Therefore, what I propose to do is to add a note explaining what the efibootmgr options are and why UUIDs are recommended over the alternative . This will force users to actually read and think about what they are doing and then make an informed, intelligent decision.<br />
<br />
What do you think ?<br />
<br />
-- [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 13:22, 20 September 2013 (UTC)<br />
<br />
== Disabling modesetting ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=Kernel_Mode_Setting&diff=next&oldid=273583 This] really looks like the user should add ''all'' of the parameters. In fact, it does not make sense to add {{ic|1=nouveau.modeset=0}} on a Radeon card. Also note that the {{ic|radeon}} driver/module [[ATI#Kernel mode-setting (KMS)|requires]] modeseting. So I'll have to undo your edit. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:35, 7 October 2013 (UTC)<br />
<br />
== UEFI Bootable Media ==<br />
<br />
Hi,<br />
<br />
just a quick note on your [https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=283870&oldid=283149 recent edit]: the section [[Unified_Extensible_Firmware_Interface#Remove_UEFI_boot_support_from_ISO]] which was left in place refers to "previous section", which was merged into [[USB Flash Installation Media]]. I think it should be merged too, what is your opinion?<br />
<br />
Otherwise I really like your work, keep up!<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:14, 21 November 2013 (UTC)<br />
<br />
I have changed the "Note" to point directly to the [[USB Flash Installation Media#BIOS and UEFI Bootable USB]]. The '''Remove UEFI boot support from ISO''' actually talks about removing CD/DVD UEFI boot support. I changed the title of that section to '''Remove UEFI boot support from Optical Media''' to make it more clear. <br />
<br />
To remove USB UEFI boot, you just have make sure <USB>/EFI/Boot/bootx64.efi (case-insensitive) file does not exist (simply delete or rename it, and the USB no longer supports UEFI boot). Setting up a USB drive to UEFI boot is much more easier and straight-forward compared to setting up a CD/DVD (or actually the ISO) (via the El-torito entry) to UEFI boot.<br />
<br />
-- [[User:The.ridikulus.rat|Keshav Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 18:08, 21 November 2013 (UTC)<br />
<br />
:Thanks for taking care of this, and for the very useful explanation! -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 21 November 2013 (UTC)<br />
<br />
== efivars question ==<br />
<br />
Hi Keshav, as you seem to be the wiki's resident EFI-expert, I hope you don't mind me asking. :)<br />
<br />
As I understand from [[UEFI#UEFI Variables Support in Linux Kernel]], {{ic|/sys/firmware/efi/efivars}} is currently enabled and mounted on all default Arch setups (as is the case on my own machine). <br />
<br />
If this is the case, does this mean that the line {{ic|mount -t efivarfs efivarfs /sys/firmware/efi/efivars # required even inside chroot if any, ignore if already mounted}}, which is present in most EFI-related articles (such as [[gummiboot]] and [[Beginners' Guide]]), can be removed, as it is no longer necessary? I find it quite messy as like this, especially without any explanation, so it would be great if it could be removed.<br />
<br />
Thanks! --[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 19:25, 28 April 2014 (UTC)<br />
<br />
:I have tested this with all recent ISOs on all my UEFI-capable machines, and every time it was mounted automatically. I am going to remove the command from the above-mentioned articles.<br />
:--[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 11:14, 15 June 2014 (UTC)</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Hardware&diff=324384Unified Extensible Firmware Interface/Hardware2014-07-10T19:50:01Z<p>The.ridikulus.rat: Update few info about my Thinkpad Edge E430</p>
<hr />
<div>[[Category:Hardware Compatibility List]]<br />
=== Required info ===<br />
<br />
# System OEM/Vendor (like Dell, HP, Lenovo etc.) and Model (like ThinkPad x121e etc.) - all info needed<br />
# Processor with the model number (full info like Intel Core i7 xxxx 1.8 GHz - for eg.)<br />
# Chipset info (Intel P67 or H67 etc.)<br />
# Motherboard with full model number - required if desktop, optional for laptop<br />
# BIOS/UEFI vendor - AMI Aptio, Phoenix SecureCore Tiano, Insyde H2O etc. (very important) with updated month/year (will be shown as copyright year in some firmwares)<br />
# Were you able to create a working entry in UEFI Boot menu using efibootmgr? Any specific issues like black screen or something like http://forum-en.msi.com/index.php?topic=153411.0 ?<br />
# If you were able to launch the UEFI Shell in ways other than using {{ic|(USB)/efi/boot/bootx64.efi}} or Archboot, how?<br />
# Output of UEFI Shell "ver" command.<br />
# If efibootmgr did not work for you and you were able to launch UEFI Shell, did you use bcfg command to create UEFI Boot Menu entry? Did bcfg created boot entry work for you?<br />
# Filesystem of UEFI System Partition? FAT32 or FAT16? (Mostly it should be FAT32 but some firmwares have problems with it, which is a violation of UEFI Spec.)<br />
# Any graphics/video card issues that occur in UEFI boot alone and not in BIOS boot? Like Nvidia closed-source driver's lack of Kernel Mode Setting etc.<br />
<br />
{{Note|In any user discussion in irc , forum or mailing lists etc. regarding UEFI, add your system info here and link to this page in the discussion to help solve the issue(s) quickly.}}<br />
<br />
Original Post: https://bbs.archlinux.org/viewtopic.php?id=133074.<br />
<br />
----<br />
<br />
=== Lenovo ThinkPad t420s ===<br />
<br />
* intel core i7 2640M 2.80GHz<br />
* Phoenix SecureCore Tiano, 2011<br />
* UEFI bios version 8CET51WW (1.31), dated 2011-11-29<br />
* efibootmgr can create entries in menu just fine. looks good.<br />
* FAT32<br />
=== Lenovo ThinkPad x121e ===<br />
<br />
# Model: Lenovo ThinkPad x121e 3045CTO<br />
# Processor: Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel<br />
# BIOS/UEFI vendor: Phoenix SecureCore Tiano<br />
# Could create a working entry in UEFI Boot menu using efibootmgr.<br />
# Have not managed to launch UEFI shell.<br />
# Filesystem of UEFI System Partition : FAT16. FAT32 does ''NOT'' work. More info at https://bbs.archlinux.org/viewtopic.php?id=131149.<br />
<br />
==== Additional notes ====<br />
* Works fine with MBR partition map in BIOS mode.<br />
* Also works fine with GPT partition map in UEFI mode but ONLY if the EFI partition is formatted as fat 16.<br />
* Cannot get it to boot from a GPT disk in BIOS mode.<br />
* I did not try archboot.<br />
<br />
=== Lenovo ThinkCenter M92z ===<br />
# Intel(R) Pentium(R) CPU G2020 @ 2.90GHz<br />
# Motherboard: Lenovo MAHOBAY<br />
# Bios Version: American Megatrends, flashed with 9NKT60AUS Lenovo Bios Update, Release Date: 1/16/2014 <br />
# Use of efibootmgr: see just below<br />
# UEFI V.2.3.1 <br />
# I did not try to create entries with bcfg<br />
# Filesystem of UEFI System Partition? FAT32.<br />
<br />
Notes:<br />
The main problem of this computer is that the entries created by efibootmgr sometimes disappear after the next reboot.<br />
Example after the reboot:<br />
<br />
Boot0000* rEFInd Boot Manager Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)<br />
Boot0001* debian HD(1,800,f3800,b500458e-3e0e-4299-bc41-48424508bced)File(\EFI\debian\grubx64.efi)<br />
<br />
In this case after I installed the debian entry, a part of the entry for '''rEFInd''' disappeared.<br />
A step by step boot configuration with refind is available here: https://gist.github.com/EmmanuelKasper/9590327<br />
<br />
<br />
=== Intel DZ77GA-70K ===<br />
# System OEM/Vendor (like Dell, HP, Lenovo etc.) and Model (like ThinkPad x121e etc.) - all info needed <br />
#* Intel DZ77GA-70K<br />
# Processor with the model number (full info like Intel Core i7 xxxx 1.8 GHz - for eg.)<br />
#* Intel Core i7 3770K<br />
# Chipset info (Intel P67 or H67 etc.)<br />
#* Z77<br />
# Motherboard with full model number - required if desktop, optional for laptop<br />
#* Intel DZ77GA-70K<br />
# BIOS/UEFI vendor - AMI Aptio, Phoenix SecureCore Tiano, Insyde H2O etc. (very important) with updated month/year (will be shown as copyright year in some firmwares)<br />
#* (from hardinfo, under a bios boot)<br />
-BIOS-<br />
Date : 07/13/2012<br />
Vendor : Intel Corp. (www.intel.com)<br />
Version : GAZ7711H.86A.0049.2012.0713.1518<br />
-Board-<br />
Name : DZ77GA-70K<br />
Vendor : Intel Corporation (www.intel.com)<br />
# Were you able to create a working entry in UEFI Boot menu using efibootmgr? Any specific issues like black screen or something like http://forum-en.msi.com/index.php?topic=153411.0 ?<br />
#* No. Linux cannot boot through uefi on this motherboard, with this bios revision.<br />
# If you were able to launch the UEFI Shell in ways other than using {{ic|(USB)/efi/boot/bootx64.efi}} or Archboot, how?<br />
#* No, however bootx64.efi works, archboot does not.<br />
# Output of UEFI Shell "ver" command.<br />
UEFI Interactive Shell v2.0<br />
Copyright 2009-2011 Intel(r) Corporation. All rights reserved. Beta build 1.0<br />
UEFI v2.31 (American Megatrends, 0x0004028D)<br />
# If efibootmgr did not work for you and you were able to launch UEFI Shell, did you use bcfg command to create UEFI Boot Menu entry? Did bcfg created boot entry work for you?<br />
#* booting through bcfg produced the same results as booting from the shell, didn't work.<br />
# Filesystem of UEFI System Partition? FAT32 or FAT16? (Mostly it should be FAT32 but some firmwares have problems with it, which is a violation of UEFI Spec.)<br />
#* Both FAT32 and FAT16 do not work.<br />
# Any graphics/video card issues that occur in UEFI boot alone and not in BIOS boot? Like Nvidia closed-source driver's lack of Kernel Mode Setting etc.<br />
#* Kernel hangs after attempting to boot, no graphics output after changing to the kernel. Graphics output before that is fine.<br />
<br />
==== Additional notes ====<br />
More info at [https://bbs.archlinux.org/viewtopic.php?id=146990 archlinux forums] and [http://unix.stackexchange.com/questions/45312/how-can-i-tell-if-i-have-a-bug-with-my-kernel-or-with-my-bios-firmware stack overflow]. Similar problems with [http://comments.gmane.org/gmane.linux.redhat.fedora.devel/167170 a different motherboard]. Seems to be a buggy uefi implementation by intel.<br />
<br />
mihanson on '''2013-07-21''': tried with latest BIOS, version 0066, and the results are the same as the above. No go in UEFI mode on the Intel DZ77GA-70K.<br />
----<br />
<br />
=== Asus M5A99X EVO ===<br />
# System OEM/Vendor<br />
#* Asus M5A99X EVO<br />
# Processor with the model number<br />
#* AMD FX(tm)-8150 Eight-Core Processor<br />
# Chipset info<br />
#* AMD 990X/SB950<br />
# BIOS/UEFI vendor<br />
Vendor: American Megatrends Inc.<br />
Version: 0901<br />
Release Date: 12/02/2011<br />
# Were you able to create a working entry in UEFI Boot menu using efibootmgr?<br />
#* Yes<br />
# If you were able to launch the UEFI Shell in ways other than using {{ic|(USB)/efi/boot/bootx64.efi}} <br />
#* Yes, option in the Exit menu of the UEFI BIOS "Launch UEFI from system partition"<br />
# Output of UEFI Shell "ver" command.<br />
#* To be updated<br />
# Filesystem of UEFI System Partition? FAT32 or FAT16? <br />
#* FAT32<br />
# Any graphics/video card issues that occur in UEFI boot alone and not in BIOS boot? Like Nvidia closed-source driver's lack of Kernel Mode Setting etc.<br />
#* No<br />
<br />
----<br />
<br />
=== HP EliteBook 840 G1 ===<br />
See [[HP_EliteBook_840_G1]] for details.<br />
<br />
=== Lenovo Thinkpad Edge E430 3254-DAQ ===<br />
<br />
The below information was added by user [[User:The.ridikulus.rat]] .<br />
<br />
==== System Info ====<br />
<br />
# [[Lenovo_ThinkPad_Edge_E430|Lenovo Thinkpad Edge E430]] 3254-DAQ (India)<br />
# Intel Core i5 3210M 2.50 GHz (3rd Gen aka Ivy Bridge), 8 GB RAM<br />
# Intel HM77 Express Chipset<br />
# UEFI Firmware Vendor : Phoenix SecureCore Tiano<br />
# UEFI/BIOS Version : 2.55<br />
# Lenovo UEFI/BIOS Build Date : 27-FEB-2014<br />
# External Ports: 3 USB 3.0, 1 USB 2.0, 1 VGA, 1 HDMI, 1 RJ45 Ethernet/LAN port (Realtek), 1 ExpressCard 34 port, 1 3.5mm Headphones jack<br />
# 1 Tray-Load CD/DVD Writer <br />
# Switchable Graphics : Intel HD Graphics 4000 and Nvidia GeForce 610M (1GB Dedicated RAM)<br />
# WiFi card : Intel Centrino Wireless-N 2230 (B/G/N + Bluetooth 4.0), no 802.11a and 802.11ac support<br />
<br />
==== Observations ====<br />
<br />
# UEFI Secure Boot support is present in firmware, but I have currently disabled it. System came pre-installed with Windows 7 Pro x64 in BIOS-MBR mode, with BIOS version 1.14 (which did not include UEFI Secure Boot).<br />
# Using a 1 GiB FAT32 UEFISYS partition (/dev/sda1) mounted at /boot/efi (i.e. separate from /boot). Kernel and initramfs files synced during update using [[UEFI_Bootloaders#Sync_EFISTUB_Kernel_in_UEFISYS_partition_using_Systemd]].<br />
# No issues with efibootmgr<br />
# Currently using gummiboot (textonly mode) as main boot manager. No need for {{ic|/EFI/Microsoft/Boot/bootmgfw.efi}} hack. Dual-booting Windows 8.1 Pro x64 UEFI-GPT. Windows boot files are stored in same EFISYS partition.<br />
# Both UEFI Shell v2 and v1 work. No option in the firmware setup/menu to directly launch the shell. <br />
# Currently using only intel and nouveau drivers. Haven't yet tried nvidia binary drivers or nvidia optimus graphics switching support. Kernel Mode Setting enabled.<br />
# grub-bios works if the firmware is changed to boot "Legacy only" without any boot/active flag in 0xEE Protective MBR partition entry.<br />
# Using only PARTUUID in /etc/fstab and in bootloader config files.<br />
<br />
==== Important Info ====<br />
<br />
I didn't use Archiso or Archboot to install the system. I transferred the Arch installation from my old Sony Vaio laptop to my new Thinkpad E430 using an external USB HDD and rsync from within SystemRescueCD, after manually creating the partitions using GParted, and then manually setup fstab and rEFInd. After that I rebooted into Arch and installed grub-efi-x86_64 and grub-bios.<br />
<br />
======From WonderWoofy======<br />
<br />
On an E430-3254(CTO) I had the same issues as the.ridikulus.rat with efibootmgr and truncated kerl command line parameters. This usually lead to the inability of the kernel to find the initramfs. What I ended up doing is putting the kernel and intramfs in the root of the ESP, and from there the efibootmgr entries worked nicely. This does lead to an ESP that is not organized in the recommended way though.<br />
<br />
Also, I did actually install via Archboot, and all worked fine. I have actually installed twice on this machine, once to a Momentus XT and once to a Samsung 830. The first time I used a CD, and therefore selected the "UEFI First" preference in the bios. This supposedly will try UEFI (\EFI\boot\bootx64.efi) first, and if that fails it will look to the MBR. Unfortunately, it did not honor this setting for the optical drive, and I had to turn off legacy bios mode entirely to get it to boot in UEFI from the CD. Interestingly, this "UEFI First" setting works just fine for interal drives. USB flash drives are a whole different story though, and more information can be found [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Create_UEFI_bootable_USB_from_ISO here].<br />
----<br />
<br />
=== System76 Galago UltraPro / TUXEDO Book BU1402 ===<br />
<br />
==== System Info ====<br />
<br />
* System76 Galago UltraPro / TUXEDO Book BU1402 (Clevo W740SU)<br />
* intel core i7 4750HQ 2.0GHz<br />
* intel HM87 Chipset<br />
* Original firmware version unknown, but from American Megatrends Inc.<br />
* Boot in UEFI mode only possible by starting an UEFI shell via the BIOS setup ({{ic|$esp/shellx64.efi}})<br />
* UEFI menu entries could be created by using efibootmgr, but without them being shown in the bootup menu<br />
* ESP filesystem: FAT32<br />
* '''Note:''' UEFI boot is not officially supported by System76 or TUXEDO Computers. Currently TUXEDO Computers doesn't provide any BIOS updates. Create a backup if you want to be able to revert to original firmware.<br />
<br />
==== Fix ====<br />
<br />
* Download the Clevo W740SU firmware from [http://repo.palkeo.com/clevo-mirror/W740SU/].<br />
* Flash it using any FreeDOS live medium<br />
* The new firmware is from American Megatrends Inc. V.4.6.5 08/13/2013<br />
* The new firmware doesn't support mixed BIOS and UEFI support, so you have to manually switch if you want to boot from a medium that doesn't support UEFI.<br />
----<br />
<br />
=== Intel Atom System-on-Chip ===<br />
<br />
Intel Atom System-on-Chip (SoC) is the Intel's answer to ARM SoC, primarily targeting Smartphones and Tablets (not regular Desktop and Notebook PCs).<br />
<br />
{{Note|This section was written based on information available online, not based on experience by an actual user of any Intel Atom SoC system.}}<br />
<br />
{{Note|Intel Atom SoC systems that ship with Windows 8/8.1 32-bit provide 32-bit UEFI-only firmware with no BIOS compatibility option (no CSM). In UEFI terms these systems are called Class 3 systems (this term is not specific to 32-bit), ie. UEFI-only with no BIOS CSM. These Atom SoC systems are therefore called as 32-bit UEFI Class 3 systems, and these can be booted only using a 32-bit UEFI bootable USB, which is not provided by default in [[Archiso]] (official install iso) and [[Archboot]]. These systems also come with UEFI Secure Boot enabled by default, but the firmware setup provides option(s) to disable Secure Boot as mandated by Microsoft for x86 systems.}}<br />
<br />
'''Related Links:'''<br />
* [[Wikipedia:Atom (system on chip)]]<br />
<br />
==== MinnowBoard ====<br />
<br />
The MinnowBoard is an Intel Atom SoC based board similar to Raspberry Pi or BeagleBoard. It ships with [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome Tianocore UDK] based 32-bit UEFI-only firmware which does not contain CSM support (no Legacy BIOS boot). The embedded Atom processor is supports only 32-bit, hence it is not possible to replace the 32-bit UEFI in the board with 64-bit (x86_64) UEFI. See below links for more info.<br />
<br />
'''Related Links:'''<br />
* http://www.minnowboard.org/<br />
* http://www.elinux.org/MinnowBoard<br />
* http://uefidk.intel.com/content/minnowboard-uefi-firmware<br />
<br />
==== Intel Atom SoC Clover Trail ====<br />
<br />
Intel Atom SoC Clover Trail processors are 32-bit only, hence they contain only 32-bit UEFI firmware. Officially Intel has stated that Linux will not be supported in Clover Trail tablets. Apart from this, Intel has not released the Clover Trail power-management and (PowerVR based) graphics code for Linux. Hence these systems may not work reliably with Linux.<br />
<br />
'''Related Links:'''<br />
* http://download.lenovo.com/luc/dml/Tablet2_Imaging_considerations.pdf<br />
* http://arstechnica.com/information-technology/2012/09/intel-declares-clover-trail-atom-processor-a-no-linux-zone/<br />
<br />
==== Intel Atom SoC Bay Trail ====<br />
<br />
Intel Atom SoC Bay Trail processors actually support 64-bit, but these tablets ship with only Windows 8/8.1 32-bit (not 64-bit) because of a feature called '''Connected Standby''' (also called '''InstantGo''') which is mandated by Microsoft to be enabled, but currently supported only by Windows 8/8.1 32-bit version (not 64-bit, as of October 2013). '''Connected Standby''' requirements (by Microsoft) include tablets to support only UEFI boot (hence no BIOS CSM) and UEFI bitness to match the OS bitness (hence 32-bit UEFI for sake of Win 8/8.1 32-bit). With only 32-bit UEFI and lack of BIOS compatibility, even Windows XP/Vista/7 32-bit (no UEFI support) and 64-bit (cannot boot in 32-bit UEFI) cannot be installed in these systems. These systems are truly locked to Windows 8/8.1 32-bit (UEFI mode). <br />
<br />
In these systems it should (theoretically) be possible to install 64-bit Linux provided the kernel is instructed to not access EFI runtime code using the '''noefi''' kernel parameter, due to the kernel/UEFI bitness mismatch. Unlike Clover Trail, Intel has stated that Bay Trail will support Android (which is based on Linux), and its graphics is based on Intel HD graphics (not PowerVR). Therefore, Bay Trail systems may work better with Linux compared to Clover Trail.<br />
<br />
'''Related Links:'''<br />
* [[Wikipedia:Connected Standby]]<br />
* http://www.pcworld.com/article/2048599/windows-81-tablets-with-64bit-atom-chips-not-coming-until-q1.html</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=324382Beginners' guide2014-07-10T19:42:02Z<p>The.ridikulus.rat: Add link to Windows_and_Arch_Dual_Boot#Important_information</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:Beginners' Guide]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC Channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the {{ic|man}} page of any command you are unfamiliar with.<br />
<br />
== Preparation ==<br />
<br />
{{Note|If you wish to install from an existing GNU/Linux distribution, please see [[Install from Existing Linux]]. This can be useful particularly if you plan to install Arch via [[VNC]] or [[SSH]] remotely. Users seeking to perform the Arch Linux installation remotely via an [[SSH]] connection should read [[Install from SSH]] for additional tips.}}<br />
<br />
=== System requirements ===<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 64 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
=== Prepare the latest installation medium ===<br />
<br />
The latest release of the installation media can be obtained from the [https://archlinux.org/download/ Download] page. Note that the single ISO image supports both 32 and 64-bit architectures. It is highly recommended to always use the latest ISO image.<br />
<br />
{{Tip|The [https://downloads.archlinux.de/iso/archboot/latest archboot] ISO images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
* Install images are signed and it is highly recommended to verify their signature before use. Dowload the ''.sig'' file from the download page (or one of the mirrors listed there) to the same directory as the ''.iso'' file. On Arch Linux, use {{ic|pacman-key -v ''iso-file''.sig}} as root; in other environments make use, still as root, of gpg2 directly with {{ic|gpg2 --verify ''iso-file''.sig}}. The file integrity checksums md5 and sha1 are also provided {{Note|The gpg2 verification will fail if you have not downloaded the public key corresponding to the RSA key ID. See http://sparewotw.wordpress.com/2012/10/31/how-to-verify-signature-using-sig-file/ for details}}<br />
* Burn the ISO image on a CD or DVD with your preferred software. On Arch, that is covered in [[Optical Disc Drive#Burning]] <br> {{Note|The quality of optical drives and the discs themselves varies greatly. Generally, using a slow burn speed is recommended for reliable burns. If you are experiencing unexpected behaviour from the disc, try burning at the lowest speed supported by your burner}}<br />
* Or you can write the ISO image to a USB stick. For detailed instructions, see [[USB Flash Installation Media]]<br />
<br />
==== Installing over the network ====<br />
<br />
Instead of writing the boot media to a disc or USB stick, you may alternatively boot the ISO image over the network. This works well when you already have a server set up. Please see the [[PXE]] article for more information, and then continue to [[#Boot the installation medium]].<br />
<br />
==== Install from an existing Linux system ====<br />
<br />
Alternatively, it is possible to install from an already running Linux system. See [[Install from Existing Linux]].<br />
<br />
==== Installing on a virtual machine ====<br />
<br />
Installing on a [[Wikipedia:Virtual machine|virtual machine]] is a good way to become familiar with Arch Linux and its installation procedure without leaving your current operating system and repartitioning the storage drive. It will also let you keep this Beginners' Guide open in your browser throughout the installation. Some users may find it beneficial to have an independent Arch Linux system on a virtual drive, for testing purposes.<br />
<br />
Examples of virtualization software are [[VirtualBox]], [[VMware]], [[QEMU]], [[Xen]], [[Parallels]].<br />
<br />
The exact procedure for preparing a virtual machine depends on the software, but will generally follow these steps:<br />
<br />
# Create the virtual disk image that will host the operating system.<br />
# Properly configure the virtual machine parameters.<br />
# Boot the downloaded ISO image with a virtual CD drive.<br />
# Continue with [[#Boot the installation medium|Boot the installation medium]].<br />
<br />
The following articles may be helpful:<br />
<br />
* [[VirtualBox#Installation steps for Arch Linux guests|Arch Linux as VirtualBox guest]]<br />
* [[Installing Arch Linux from VirtualBox]]<br />
* [[VirtualBox Arch Linux Guest On Physical Drive|Arch Linux as VirtualBox guest on a physical drive]]<br />
* [[Installing Arch Linux in VMware|Arch Linux as VMware guest]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
<br />
==== Boot the installation medium ====<br />
<br />
Most modern systems allow you to select the boot device during the [[Wikipedia:Power-on self test|POST]] phase, usually by pressing the {{ic|F12}} key while the BIOS splash screen is visible. Select the device which contains the Arch ISO. Alternatively, you may need to change the boot order in your computer's BIOS. <br />
<br />
To do this, press a key (usually {{ic|Delete}}, {{ic|F1}}, {{ic|F2}}, {{ic|F11}} or {{ic|F12}}) during the [[Wikipedia:Power-on self test|POST]] phase. This will take you into the BIOS settings screen where you can set the order in which the system searches for devices to boot from. Set the device which contains the Arch ISO as the first device from which boot is attempted. Select "Save & Exit" (or your BIOS's equivalent) and the computer should then complete its normal boot process.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will run the actual installation (if booting from a UEFI boot disk, the option may look more like "Arch Linux archiso x86_64 UEFI").<br />
<br />
===== Testing if you are booted into UEFI mode =====<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard and UEFI Boot mode is enabled (and is preferred over BIOS/Legacy mode), the CD/USB will automatically launch Arch Linux via [[Gummiboot]]. To test if you have booted into UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
If ''efivar'' lists the UEFI variables properly, then you have booted in UEFI mode. If not check whether all the requirements listed in [[Unified Extensible Firmware Interface#Requirements for UEFI Variables support to work properly|Unified Extensible Firmware Interface]] are met.<br />
<br />
==== Troubleshooting boot problems ====<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|e}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Installation ==<br />
<br />
You are now presented with a shell prompt, automatically logged in as root. Your shell is [[Zsh]]; this will provide you advanced Tab completion, and other features as part of the [http://grml.org/zsh/ grml config].<br />
For editing text files, the console editor ''nano'' is suggested. If you are not familiar with it, see [[nano#nano usage]].<br />
If you have (or plan on having) a dual boot setup with Windows, see [[Windows and Arch Dual Boot]].<br />
<br />
=== Change the language ===<br />
<br />
{{Tip|These are optional for the majority of users. Useful only if you plan on writing in your own language in any of the configuration files, if you use diacritical marks in the Wi-Fi password, or if you would like to receive system messages (e.g. possible errors) in your own language. Changes here ''only'' affect the installation process.}}<br />
<br />
By default, the keyboard layout is set to {{ic|us}}. If you have a non-[[Wikipedia:File:KB United States-NoAltGr.svg|US]] keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
...where ''layout'' can be {{ic|fr}}, {{ic|uk}}, {{ic|dvorak}}, {{ic|be-latin1}}, etc. See this [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|wikipedia article]] for a 2-letter country code list. Use the command {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If some glyphs of your language's alphabet (e.g. accented and non Latin letters) show up as white squares or as other symbols, you may want to change the console font with one from {{ic|/usr/share/kbd/consolefonts/}}. For example:<br />
<br />
# setfont lat9w-16<br />
<br />
You can run the {{ic|showconsolefont}} command to display the full contents of the loaded font. Note that the font name is case-sensitive, so type it ''exactly'' as you see it. See [[Fonts#Console fonts]] for more information.<br />
<br />
By default, the language is set to English (US). If you would like to change the language for the install process ''(German, in this example)'', remove the {{ic|#}} in front of the [[locale]] you want from {{ic|/etc/locale.gen}}, along with English (US). Please choose the {{ic|UTF-8}} entries:<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
en_US.UTF-8 UTF-8<br />
de_DE.UTF-8 UTF-8<br />
}}<br />
<br />
# locale-gen<br />
# export LANG=de_DE.UTF-8<br />
<br />
=== Establish an internet connection ===<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
{{Note|Since the ISO released on 2014.04 (but maybe even on previous ones) there seems to be a problem in getting an IP address with DHCP if you are using the family of routers "FritzBox!". At this time models 7390[http://unix.stackexchange.com/questions/126526/archlinux-2014-04-64bit-and-connectivity-problem-during-instalation] and 7112[https://unix.stackexchange.com/questions/126694/enabling-wired-internet-connection-with-dhcp-during-arch-linux-installation/126709] seem to have this issue, but other models may be affected. The issue seems to be between the [[dhcpcd]] client and the FritzBox! routers and the way they assign IP addresses. The solution to the problem seems to be as follows: in your FritzBox! settings, manually delete the entry related to the IP address that identifies your machine. Also, disable the option "Assign always the same IP address to this machine". Now restart the DHCP process or simply reboot your computer and you should get an IP address as usual. If it does not work, try also to reboot your FritzBox!. Once your computer gets the IP address, you can re-enable the previously disabled option. }}<br />
<br />
The {{ic|dhcpcd}} network daemon starts automatically during boot and it will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable or wireless signal strength. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage drive]].<br />
<br />
==== Wired ====<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
First, disable the dhcpcd service which was started automatically at boot:<br />
<br />
# systemctl stop dhcpcd.service<br />
<br />
Identify the name of your Ethernet interface.<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the Ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your Ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
You also need to know these settings:<br />
<br />
* Static IP address.<br />
* Subnet mask.<br />
* Gateway's IP address.<br />
* Name servers' (DNS) IP addresses.<br />
* Domain name (unless you are on a local LAN, in which case you can make it up).<br />
<br />
Activate the connected Ethernet interface (e.g. {{ic|enp2s0f0}}):<br />
<br />
# ip link set enp2s0f0 up<br />
<br />
Add the address:<br />
<br />
# ip addr add ''ip_address''/''mask_bits'' dev ''interface_name''<br />
<br />
For example:<br />
<br />
# ip addr add 192.168.1.2/24 dev enp2s0f0<br />
<br />
For more options, run {{ic|man ip}}.<br />
<br />
Add your gateway like this, substituting your own gateway's IP address:<br />
<br />
# ip route add default via ''ip_address''<br />
<br />
For example:<br />
<br />
# ip route add default via 192.168.1.1<br />
<br />
Edit {{ic|resolv.conf}}, substituting your name servers' IP addresses and your local domain name:<br />
<br />
{{hc|# nano /etc/resolv.conf|<br />
nameserver 61.23.173.5<br />
nameserver 61.95.849.8<br />
search example.com<br />
}}<br />
<br />
{{Note|Currently, you may include a maximum of three {{ic|nameserver}} lines. In order to overcome this limitation, you can use a locally caching nameserver like [[dnsmasq]].}}<br />
<br />
You should now have a working network connection. If you do not, check the detailed [[Network configuration]] page.<br />
<br />
==== Wireless ====<br />
<br />
Follow this procedure if you need wireless connectivity (Wi-Fi) during the installation process.<br />
<br />
First, identify the name of your wireless interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
In this example, {{ic|wlp3s0}} is the available wireless interface. If you are unsure, your wireless interface is likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e". <br />
<br />
{{Note|If you do not see output similar to this, then your wireless driver has not been loaded. If this is the case, you must load the driver yourself. Please see [[Wireless network configuration]] for more detailed information.}}<br />
<br />
Now use [[netctl]]'s {{ic|wifi-menu}} to connect to a network:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
You should now have a working network connection. If you do not, try [[#Without wifi-menu]] or check the detailed [[Wireless network configuration]] page.<br />
<br />
===== Without wifi-menu =====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke {{ic|dmesg}} to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace ''ssid'' with the name of your network (e.g. "Linksys etc...") and ''psk'' with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase ''ssid'' ''passphrase'' >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211 -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
If ''wpa_supplicant'' complains about an unsupported driver at step 4, just leave out the {{ic|-D nl80211}} parameter:<br />
<br />
# wpa_supplicant -B -c /etc/wpa_supplicant.conf -i ''interface''<br />
<br />
==== Analog modem, ISDN, or PPPoE DSL ====<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
==== Behind a proxy server ====<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
=== Prepare the storage drive ===<br />
<br />
{{Warning|Partitioning can destroy data. You are '''strongly''' cautioned and advised to backup any critical data before proceeding.}}<br />
{{Note|If you are installing to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
{{Tip|If you want to create any stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], do it now.}}<br />
<br />
==== Choose a partition table type ====<br />
<br />
{{Note|If Arch and Windows are dual-booting from same disk, then Arch SHOULD follow the same firmware boot mode and partitioning combination used by the installed Windows in the disk. Otherwise Windows will fail to boot. Refer to [[Windows and Arch Dual Boot#Important information|this page]] for more information.}}<br />
<br />
You have to choose between [[GUID Partition Table]] (GPT) and [[Master Boot Record]] (MBR), see also [[Partitioning#Choosing between GPT and MBR]].<br />
<br />
* It is recommended to always use GPT for UEFI boot, as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* Some BIOS systems may have issues with GPT. See http://mjg59.dreamwidth.org/8035.html and http://rodsbooks.com/gdisk/bios.html for more info and possible workarounds.<br />
<br />
==== Partitioning tool ====<br />
<br />
Absolute beginners are encouraged to use a graphical partitioning tool. [[GParted]] is a good example, and is [http://gparted.sourceforge.net/livecd.php provided as a live CD]. A drive should first be [[partitioning|partitioned]] and afterwards the partitions should be formatted with a [[File systems|file system]].<br />
<br />
While ''gparted'' may be easier to use, if you just want to create a few partitions on a new disk you can get the job done quickly by just using one of the [[Partitioning#Partitioning tools|fdisk variants]] which are included on the install medium. In the next section short usage instructions for both [[Partitioning#Gdisk usage summary|gdisk]] and [[Partitioning#Fdisk usage summary|fdisk]] follow.<br />
<br />
==== Erase partition table ====<br />
<br />
If you want to start from scratch, and do not intend to keep existing partitions, erase the partition table with the following command. This simplifies creating new partitions and avoids problems with converting disks from MBR to GPT and vice versa.<br />
<br />
# sgdisk --zap-all /dev/sda<br />
<br />
==== Partition scheme ====<br />
<br />
You can decide into how many partitions the disk should be split, and for which directory each partition should be used in the system. The mapping from partitions to directories (frequently called 'mount points') is the [[Partitioning#Partition scheme|Partition scheme]]. The simplest, and not a bad choice, is to make just one huge {{ic|/}} partition. Another popular choice is to have a {{ic|/}} and a {{ic|/home}} partition.<br />
<br />
'''Additional required partitions:'''<br />
* If you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard, you will need to create an extra [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
* If you have a BIOS motherboard (or plan on booting in BIOS compatibility mode) and you want to setup GRUB on a GPT-partitioned drive, you will need to create an extra [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]] of size 1 or 2 MiB and {{ic|EF02}} type code. Syslinux does not need one.<br />
* If you have a requirement for a [[Disk encryption]] of the system itself, this must be reflected in your partition scheme. It is unproblematic to add encrypted folders, containers or home directories after the system is installed.<br />
<br />
See [[Swap]] for details if you wish to set up a swap partition or swap file. A swap file is easier to resize than a partition and can be created at any point after installation, but cannot be used with a Btrfs filesystem.<br />
<br />
If you have already created your partitions, proceed to [[#Create filesystems]]. Otherwise, see the following example.<br />
<br />
==== Example ====<br />
<br />
The Arch Linux install media includes the following partitioning tools: {{ic|fdisk}}, {{ic|gdisk}}, {{ic|cfdisk}}, {{ic|cgdisk}} and {{ic|parted}}.<br />
<br />
{{Tip|Use the {{ic|lsblk -f}} or {{ic|lsblk -o NAME,FSTYPE,SIZE,LABEL}} command to list the hard disks attached to your system, along with the sizes of their existing partitions. This will help you to be confident you are partitioning the right disk.}}<br />
<br />
The example system will contain a 15 GB root partition, and a [[Partitioning#/home|home]] partition for the remaining space. Choose either MBR or GPT, as described above. Do not choose both!<br />
<br />
It should be emphasized that partitioning is a personal choice and that this example is only for illustrative purposes. See [[Partitioning]].<br />
<br />
===== Using cgdisk to create GPT partitions =====<br />
<br />
Launch ''cgdisk'' with:<br />
<br />
# cgdisk /dev/sda<br />
<br />
{{Tip|If cgdisk cannot change your disk to GPT, {{pkg|parted}} can.}}<br />
<br />
'''Root:'''<br />
* Choose ''New'' (or press {{ic|N}}) – {{ic|Enter}} for the first sector (2048) – type in {{ic|15G}} – {{ic|Enter}} for the default hex code (8300) – {{ic|Enter}} for a blank partition name.<br />
<br />
'''Home:'''<br />
* Press the down arrow a couple of times to move to the larger free space area.<br />
* Choose ''New'' (or press {{ic|N}}) – {{ic|Enter}} for the first sector – {{ic|Enter}} to use the rest of the drive (or you could type in the desired size; for example {{ic|30G}}) – {{ic|Enter}} for the default hex code (8300) – {{ic|Enter}} for a blank partition name.<br />
<br />
Here is what it should look like:<br />
<br />
Part. # Size Partition Type Partition Name<br />
----------------------------------------------------------------<br />
1007.0 KiB free space<br />
1 15.0 GiB Linux filesystem<br />
2 123.45 GiB Linux filesystem<br />
<br />
Double check and make sure that you are happy with the partition sizes as well as the partition table layout before continuing.<br />
<br />
If you would like to start over, you can simply select ''Quit'' (or press {{ic|Q}}) to exit without saving changes and then restart ''cgdisk''.<br />
<br />
If you are satisfied, choose ''Write'' (or press {{ic|Shift+W}}) to finalize and to write the partition table to the drive. Type {{ic|yes}} and choose ''Quit'' (or press {{ic|Q}}) to exit without making any more changes.<br />
<br />
===== Using fdisk to create MBR partitions =====<br />
<br />
{{Note|There is also ''cfdisk'', which is similar in UI to ''cgdisk'', but it currently does not automatically align the first partition properly. That is why the classic ''fdisk'' tool is used here.}}<br />
<br />
Launch ''fdisk'' with:<br />
<br />
# fdisk /dev/sda<br />
<br />
Create the partition table:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|o}} and press {{ic|Enter}}<br />
<br />
Then create the first partition:<br />
<br />
# {{ic|Command (m for help):}} type {{ic|n}} and press {{ic|Enter}}<br />
# Partition type: {{ic|Select (default p):}} press {{ic|Enter}}<br />
# {{ic|Partition number (1-4, default 1):}} press {{ic|Enter}}<br />
# {{ic|First sector (2048-209715199, default 2048):}} press {{ic|Enter}}<br />
# {{ic|Last sector, +sectors or +size{K,M,G,T,P} (2048-209715199....., default 209715199):}} type {{ic|+15G}} and press {{ic|Enter}}<br />
<br />
Then create a second partition:<br />
<br />
# {{ic|Command (m for help):}} type {{ic|n}} and press {{ic|Enter}}<br />
# Partition type: {{ic|Select (default p):}} press {{ic|Enter}}<br />
# {{ic|Partition number (1-4, default 2):}} press {{ic|Enter}}<br />
# {{ic|First sector (31459328-209715199, default 31459328):}} press {{ic|Enter}}<br />
# {{ic|Last sector, +sectors or +size{K,M,G,T,P} (31459328-209715199....., default 209715199):}} press {{ic|Enter}}<br />
<br />
Now preview the new partition table:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|p}} and press {{ic|Enter}}<br />
<br />
{{bc|<br />
Disk /dev/sda: 107.4 GB, 107374182400 bytes, 209715200 sectors<br />
Units &#61; sectors of 1 * 512 &#61; 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x5698d902<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sda1 2048 31459327 15728640 83 Linux<br />
/dev/sda2 31459328 209715199 89127936 83 Linux<br />
}}<br />
<br />
Then write the changes to disk:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|w}} and press {{ic|Enter}}<br />
<br />
If everything went well fdisk will now quit with the following message:<br />
<br />
{{bc|<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks. <br />
}}<br />
<br />
In case this does not work because ''fdisk'' encountered an error, you can use the {{ic|q}} command to exit.<br />
<br />
==== Create filesystems ====<br />
<br />
Simply partitioning is not enough; the partitions also need a [[File systems|filesystem]]. To format the partitions with an ext4 filesystem:<br />
<br />
{{Warning|Double check and triple check that it is actually {{ic|/dev/sda1}} and {{ic|/dev/sda2}} that you want to format. You can use {{ic|lsblk}} to help with this.}}<br />
<br />
# mkfs.ext4 /dev/sda1<br />
# mkfs.ext4 /dev/sda2<br />
<br />
If you have made a partition dedicated to swap (code 82), do not forget to format and activate it with:<br />
<br />
# mkswap /dev/sda''X''<br />
# swapon /dev/sda''X''<br />
<br />
For UEFI, you should format the EFI System Partition (for example /dev/sd''XY'') with:<br />
<br />
# mkfs.fat -F32 /dev/sd''XY''<br />
<br />
=== Mount the partitions ===<br />
<br />
Each partition is identified with a number suffix. For example, {{ic|sda1}} specifies the first partition of the first drive, while {{ic|sda}} designates the entire drive.<br />
<br />
To display the current partition layout:<br />
<br />
# lsblk -f<br />
<br />
{{Note|Do not mount more than one partition to the same directory. And pay attention, because the mounting order is important.}}<br />
<br />
First, mount the root partition on {{ic|/mnt}}. Following the example above (yours may be different), it would be:<br />
<br />
# mount /dev/sda1 /mnt<br />
<br />
Then mount the home partition and any other separate partition ({{ic|/boot}}, {{ic|/var}}, etc), if you have any:<br />
<br />
# mkdir /mnt/home<br />
# mount /dev/sda2 /mnt/home<br />
<br />
In case you have a UEFI motherboard, mount the EFI System Partition to {{ic|/boot}}. Whilst other mountpoints are viable, using {{ic|/boot}} is recommended as explained in the [[EFISTUB]] article.<br />
<br />
# mkdir /mnt/boot<br />
# mount /dev/sd''XY'' /mnt/boot<br />
<br />
=== Select a mirror ===<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by {{ic|pacstrap}} as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on 2012-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline.<br />
<br />
{{Tip|<br />
* Use the [https://www.archlinux.org/mirrorlist/ Mirrorlist Generator] to get an updated list for your country. HTTP mirrors are faster than FTP, because of something called [[Wikipedia:Keepalive|keepalive]]. With FTP, ''pacman'' has to send out a signal each time it downloads a package, resulting in a brief pause. For other ways to generate a mirror list, see [[Mirrors#Sorting mirrors|Sorting mirrors]] and [[Reflector]].<br />
* [https://archlinux.org/mirrors/status/ Arch Linux MirrorStatus] reports various aspects about the mirrors such as network problems with mirrors, data collection problems, the last time mirrors have been synced, etc.<br />
}}<br />
<br />
{{Note|<br />
* Whenever in the future you change your mirrorlist, refresh all package lists with {{ic|pacman -Syy}}, to ensure that the package lists are updated consistently. See [[Mirrors]] for more information.<br />
* If you are using an older installation medium, your mirrorlist might be outdated, which might lead to problems when updating Arch Linux (see {{Bug|22510}}). Therefore it is advised to obtain the latest mirror information as described above.<br />
* Some issues have been reported in the [https://bbs.archlinux.org/ Arch Linux forums] regarding network problems that prevent ''pacman'' from updating/synchronizing repositories (see [https://bbs.archlinux.org/viewtopic.php?id&#61;68944] and [https://bbs.archlinux.org/viewtopic.php?id&#61;65728]). When installing Arch Linux natively, these issues have been resolved by replacing the default ''pacman'' file downloader with an alternative (see [[Improve pacman performance]] for more details). When installing Arch Linux as a guest OS in [[VirtualBox]], this issue has also been addressed by using "Host interface" instead of "NAT" in the machine properties.<br />
}}<br />
<br />
=== Install the base system ===<br />
<br />
The base system is installed using the ''pacstrap'' script. The {{ic|-i}} switch can be omitted if you wish to install every package from the {{Grp|base}} group without prompting. You may also want to include {{Grp|base-devel}}, as you will need these packages should you want to build packages from the [[AUR]] or using the [[ABS]]:<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
{{Note|<br />
* If ''pacstrap'' hangs with {{ic|error: failed retrieving file 'core.db' from mirror... : Connection time-out}}, yet your mirrors are configured correctly, try setting a different [[Resolv.conf|name server]].<br />
* If in the middle of the installation of base packages you get a request to import a PGP key, agree to download the key to proceed. This is likely to happen if the Arch ISO you are using is out of date.<br />
* If ''pacman'' fails to verify your packages, stop the process with {{ic|Ctrl+C}} and check the system time with {{ic|cal}}. If the system date is invalid (e.g. it shows the year 2010), signing keys will be considered expired (or invalid), signature checks on packages will fail and installation will be interrupted. Make sure to correct the system time, using the command {{ic|ntpd -qg}}, and retry running the ''pacstrap'' command. Refer to [[Time]] page for more information on correcting system time.<br />
* If ''pacman'' complains that {{ic|error: failed to commit transaction (invalid or corrupted package)}}, run the following command:<br />
# pacman-key --init && pacman-key --populate archlinux<br />
}}<br />
<br />
This will give you a basic Arch system. Other packages can be installed later using [[pacman]].<br />
<br />
=== Generate an fstab ===<br />
<br />
Generate an [[fstab]] file with the following command. UUIDs will be used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you would prefer to use labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file.}}<br />
<br />
A few considerations:<br />
<br />
* The last field determines the order in which partitions are checked at start up: use {{ic|1}} for the (non-Btrfs) root partition, which should be checked first; {{ic|2}} for all other partitions you want checked at start up; and {{ic|0}} means 'do not check' (see [[fstab#Field definitions]]).<br />
* All [[Btrfs]] partitions should have {{ic|0}} for this field. Normally, you will also want your ''swap'' partition to have {{ic|0}}.<br />
<br />
=== Chroot and configure the base system ===<br />
<br />
Next, [[Change Root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
{{Note|Leave out {{ic|/bin/bash}} to chroot into the sh shell.}}<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
==== Locale ====<br />
<br />
Locales are used by {{Pkg|glibc}} and other locale-aware programs or libraries for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards. There are two files that need editing: {{ic|locale.gen}} and {{ic|locale.conf}}.<br />
<br />
The {{ic|locale.gen}} file has everything commented out by default. To uncomment a line remove the {{ic|#}} in the front. Using {{ic|UTF-8}} is highly recommended over {{ic|ISO-8859}}:<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Generate the locale(s) specified in {{ic|/etc/locale.gen}}:<br />
<br />
# locale-gen<br />
<br />
{{Note|This will also run with every update of {{Pkg|glibc}}.}}<br />
<br />
Create the {{ic|/etc/locale.conf}} file substituting your chosen locale:<br />
<br />
# echo LANG=en_US.UTF-8 > /etc/locale.conf<br />
<br />
{{Note|<br />
* The locale specified in the {{ic|LANG}} variable must be uncommented in {{ic|/etc/locale.gen}}.<br />
* The {{ic|locale.conf}} file does not exist by default. Setting only {{ic|LANG}} should be enough as it will act as the default value for all other variables.<br />
}}<br />
<br />
Export substituting your chosen locale:<br />
<br />
# export LANG=en_US.UTF-8<br />
<br />
{{Tip|To use other locales for other {{ic|LC_*}} variables, run {{ic|locale}} to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale#Setting the locale system-wide]] for details.}}<br />
<br />
==== Console font and keymap ====<br />
<br />
If you changed the default console keymap and font in [[#Change the language]], you will have to edit {{ic|/etc/vconsole.conf}} ''accordingly'' (create it if it does not exist) to make those changes persist in the installed system, for example:<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=de-latin1<br />
FONT=lat9w-16<br />
}}<br />
<br />
{{Warning|If you set {{ic|KEYMAP}} to a different value than the one you initially set with ''loadkeys'', and then you [[#Set the root password]], you may have problems logging into the new system after rebooting, because some keys may be mapped differently between the two layouts.}}<br />
<br />
Note that these settings are only valid for your virtual consoles, not in [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
==== Time zone ====<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories.<br />
<br />
To view the available zones, check the directory {{ic|/usr/share/zoneinfo/}}:<br />
<br />
# ls /usr/share/zoneinfo/<br />
<br />
Similarly, you can check the contents of directories belonging to a subzone:<br />
<br />
# ls /usr/share/zoneinfo/Europe<br />
<br />
Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} using this command:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
'''Example:'''<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
==== Hardware clock ====<br />
<br />
Set the hardware clock mode uniformly between your operating systems. Otherwise, they may overwrite the hardware clock and cause time shifts.<br />
<br />
You can generate {{ic|/etc/adjtime}} automatically by using one of the following commands:<br />
<br />
* '''UTC''' (recommended): {{Note|Using [[Wikipedia:Coordinated Universal Time|UTC]] for the hardware clock does not mean that software will display time in UTC.}} {{bc|# hwclock --systohc --utc}}<br />
* '''localtime''' (discouraged; used by default in Windows): {{Warning|Using ''localtime'' may lead to several known and unfixable bugs. However, there are no plans to drop support for ''localtime''.}} {{bc|# hwclock --systohc --localtime}}<br />
<br />
==== Kernel modules ====<br />
<br />
{{Tip|This is just an example, you do not need to set it. All needed modules are automatically loaded by udev, so you will rarely need to add something here. Only add modules that you know are missing.}}<br />
<br />
For kernel modules to load during boot, place a {{ic|*.conf}} file in {{ic|/etc/modules-load.d/}}, with a name based on the program that uses them:<br />
<br />
{{hc|# nano /etc/modules-load.d/virtio-net.conf|<br />
# Load 'virtio-net.ko' at boot.<br />
<br />
virtio-net<br />
}}<br />
<br />
If there are more modules to load per {{ic|*.conf}}, the module names can be separated by newlines. A good example are the [[VirtualBox#Installation steps for Arch Linux guests|VirtualBox Guest Additions]].<br />
<br />
Empty lines and lines starting with {{ic|#}} or {{ic|;}} are ignored.<br />
<br />
==== Hostname ====<br />
<br />
Set the [[Wikipedia:Hostname|hostname]] to your liking (e.g. ''arch''):<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
Add the same hostname to {{ic|/etc/hosts}}:<br />
<br />
{{hc|# nano /etc/hosts|<br />
#<br />
# /etc/hosts: static lookup table for host names<br />
#<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost<br />
<br />
# End of file<br />
}}<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are very similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}. <br />
<br />
{{Note|<br />
* For more in-depth information on network configration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (ie. eth* and wlan*) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
==== Wired ====<br />
<br />
===== Dynamic IP =====<br />
<br />
; Using dhcpcd<br />
<br />
If you only use a single fixed wired network connection, you do not need a network management service and can simply enable the {{ic|dhcpcd}} service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
; Using netctl<br />
<br />
Copy a sample profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/ethernet-dhcp my_network<br />
<br />
Edit the profile as needed (update {{ic|Interface}} from {{ic|eth0}} to the interface name of the system. <br />
# nano my_network<br />
<br />
Enable the {{ic|my_network}} profile:<br />
<br />
# netctl enable my_network<br />
<br />
{{Note|You will get the message "Running in chroot, ignoring request.". This can be ignored for now.}}<br />
<br />
; Using netctl-ifplugd<br />
<br />
{{Warning|You cannot use this method in conjunction with explicitly enabling profiles, such as {{ic|netctl enable ''profile''}}.}}<br />
<br />
Alternatively, you can use {{ic|netctl-ifplugd}}, which gracefully handles dynamic connections to new networks.<br />
<br />
Install {{Pkg|ifplugd}}, which is required for {{ic|netctl-ifplugd}}:<br />
<br />
# pacman -S ifplugd<br />
<br />
Then enable for interface that you want:<br />
<br />
# systemctl enable netctl-ifplugd@''interface''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-auto}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-ifplugd}}.}}<br />
<br />
===== Static IP =====<br />
<br />
; Using netctl<br />
<br />
Copy a sample profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/ethernet-static my_network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|Address}}, {{ic|Gateway}} and {{ic|DNS}}):<br />
<br />
# nano my_network<br />
<br />
Notice the {{ic|/24}} in {{ic|Address}} which is the [[wikipedia:Classless Inter-Domain Routing#CIDR notation|CIDR notation]] of a {{ic|255.255.255.0}} netmask.<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my_network<br />
<br />
; Using systemd-networkd<br />
<br />
See [[systemd-networkd]].<br />
<br />
==== Wireless ====<br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for {{ic|wifi-menu}}:<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with {{ic|wifi-menu ''interface_name''}} (where {{ic|''interface_name''}} is the interface of your wireless chipset).<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
{{Warning|This must be done '''after''' your reboot when you are no longer chrooted. The process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using {{ic|wifi-menu}} at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|You cannot use this method in conjunction with explicitly enabling profiles, such as {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
{{Tip|Most users can skip this step and use the defaults provided in {{ic|mkinitcpio.conf}}. The initramfs image (from the {{ic|/boot}} folder) has already been generated based on this file when the {{Pkg|linux}} package (the Linux kernel) was installed earlier with ''pacstrap''.}}<br />
<br />
Here you need to set the right [[Mkinitcpio#HOOKS|hooks]] if the root is on a USB drive, if you use RAID, LVM, if using a multi-device Btrfs volumes as root, or if {{ic|/usr}} is on a separate partition.<br />
<br />
Edit {{ic|/etc/mkinitcpio.conf}} as needed and re-generate the initramfs image with:<br />
<br />
# mkinitcpio -p linux<br />
<br />
{{Note|Arch VPS installations on QEMU (e.g. when using {{ic|virt-manager}}) may need {{ic|virtio}} modules in {{ic|mkinitcpio.conf}} to be able to boot.<br />
{{hc|# nano /etc/mkinitcpio.conf|2=<br />
MODULES="virtio virtio_blk virtio_pci virtio_net"<br />
}}<br />
}}<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
==== For BIOS motherboards ====<br />
<br />
For BIOS systems, several boot loaders are available, see [[Boot loaders]] for a complete list. Choose one as per your convenience. Here, two of the possibilities are given as examples:<br />
<br />
* [[Syslinux]] is (currently) limited to loading only files from the partition where it was installed. Its configuration file is considered to be easier to understand. An example configuration can be found in the [[Syslinux#Examples|syslinux]] article.<br />
* [[GRUB]] is more feature-rich and supports more complex scenarios. Its configuration file(s) is more similar to 'sh' scripting language, which may be difficult for beginners to manually write. It is recommended that they automatically generate one.<br />
<br />
===== Syslinux =====<br />
<br />
If you opted for a GUID partition table (GPT) for your hard drive earlier, you need to install the {{Pkg|gptfdisk}} package now for the installation of ''syslinux'' to work:<br />
<br />
# pacman -S gptfdisk<br />
<br />
Install the {{Pkg|syslinux}} package and then use the {{ic|syslinux-install_update}} script to automatically ''install'' the bootloader ({{ic|-i}}), mark the partition ''active'' by setting the boot flag ({{ic|-a}}), and install the ''MBR'' boot code ({{ic|-m}}):<br />
<br />
# pacman -S syslinux<br />
# syslinux-install_update -iam<br />
<br />
After installing Syslinux, configure {{ic|syslinux.cfg}} to point to the right root partition. This step is vital. If it points to the wrong partition, Arch Linux will not boot. Change {{ic|/dev/sda3}} to reflect your root partition (if you partitioned your drive as in [[#Prepare the storage drive|the example]], your root partition is {{ic|/dev/sda1}}).<br />
<br />
{{hc|# nano /boot/syslinux/syslinux.cfg|2=<br />
...<br />
LABEL arch<br />
...<br />
APPEND root='''/dev/sda3''' rw<br />
...<br />
}}<br />
<br />
If adding [[UUID]] rather than partition number the syntax is {{ic|1=APPEND root=UUID=''partition_uuid'' rw}}.<br />
<br />
Do the same for the fallback entry.<br />
<br />
For more information on configuring and using Syslinux, see [[Syslinux]].<br />
<br />
===== GRUB =====<br />
<br />
Install the {{Pkg|grub}} package and then run {{ic|grub-install}} to install the bootloader:<br />
<br />
# pacman -S grub<br />
# grub-install --target=i386-pc --recheck '''/dev/sda'''<br />
<br />
{{Note|<br />
* Change {{ic|/dev/sda}} to reflect the drive you installed Arch on. Do not append a partition number (do not use {{ic|sda''X''}}).<br />
* For GPT-partitioned drives on BIOS motherboards, you also need a "BIOS Boot Partition". See [[GRUB#GUID Partition Table (GPT) specific instructions|GPT-specific instructions]] in the GRUB page.<br />
* A sample {{ic|/boot/grub/grub.cfg}} gets installed as part of the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure that your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or some such file.<br />
}}<br />
<br />
While using a manually created {{ic|grub.cfg}} is absolutely fine, it is recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} ({{ic|pacman -S os-prober}}) before running the next command.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|It is possible that multiple redundant menu entries will be generated. See [[GRUB#Redundant_menu_entries]].}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
For UEFI systems, several boot loaders are available, see [[Boot loaders]] for a complete list. Choose one as per your convenience. Here, two of the possibilities are given as examples:<br />
<br />
* [[gummiboot]] is a minimal UEFI Boot Manager which provides a menu for [[EFISTUB]] kernels and other UEFI applications.<br />
* [[GRUB]] is a more complete bootloader, useful if you run into problems with Gummiboot.<br />
<br />
No matter which one you choose, first install the {{Pkg|dosfstools}} package, so you can manipulate your EFI System Partition after installation:<br />
<br />
# pacman -S dosfstools<br />
<br />
{{Note|For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.}}<br />
<br />
===== Gummiboot =====<br />
<br />
Install the {{Pkg|gummiboot}} package and run {{ic|gummiboot install}} to install the bootloader to the EFI System Partition:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot install<br />
<br />
{{Warning|Gummiboot and the Linux Kernel will not automatically update if your EFI System Partition is not mounted at {{ic|/boot}}.}}<br />
<br />
You will need to manually create a configuration file to add an entry for Arch Linux to the gummiboot manager. Create {{ic|/boot/loader/entries/arch.conf}} and add the following contents, replacing {{ic|/dev/sdaX}} with your '''root''' partition, usually {{ic|/dev/sda2}}:<br />
<br />
{{hc|# nano /boot/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
For more information on configuring and using gummiboot, see [[gummiboot]].<br />
<br />
===== GRUB =====<br />
<br />
Install the {{Pkg|grub}} and {{Pkg|efibootmgr}} packages and run {{ic|grub-install}} to install the bootloader:<br />
<br />
# pacman -S grub efibootmgr<br />
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck<br />
<br />
Next, while using a manually created {{ic|grub.cfg}} is absolutely fine, it is recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} before running the next command. However ''os-prober'' is not known to properly detect UEFI OSes.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
=== Unmount the partitions and reboot ===<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
{{Tip|Be sure to remove the installation media, otherwise you will boot back into it.}}<br />
<br />
== Post-installation ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read [[General recommendations#System administration]] and [[General recommendations#Package management]].<br />
<br />
See the rest of the [[General recommendations]] article for post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Hardware&diff=320892Unified Extensible Firmware Interface/Hardware2014-06-20T22:29:15Z<p>The.ridikulus.rat: connected standby is also called instantgo</p>
<hr />
<div>[[Category:Hardware Compatibility List]]<br />
=== Required info ===<br />
<br />
# System OEM/Vendor (like Dell, HP, Lenovo etc.) and Model (like ThinkPad x121e etc.) - all info needed<br />
# Processor with the model number (full info like Intel Core i7 xxxx 1.8 GHz - for eg.)<br />
# Chipset info (Intel P67 or H67 etc.)<br />
# Motherboard with full model number - required if desktop, optional for laptop<br />
# BIOS/UEFI vendor - AMI Aptio, Phoenix SecureCore Tiano, Insyde H2O etc. (very important) with updated month/year (will be shown as copyright year in some firmwares)<br />
# Were you able to create a working entry in UEFI Boot menu using efibootmgr? Any specific issues like black screen or something like http://forum-en.msi.com/index.php?topic=153411.0 ?<br />
# If you were able to launch the UEFI Shell in ways other than using {{ic|(USB)/efi/boot/bootx64.efi}} or Archboot, how?<br />
# Output of UEFI Shell "ver" command.<br />
# If efibootmgr did not work for you and you were able to launch UEFI Shell, did you use bcfg command to create UEFI Boot Menu entry? Did bcfg created boot entry work for you?<br />
# Filesystem of UEFI System Partition? FAT32 or FAT16? (Mostly it should be FAT32 but some firmwares have problems with it, which is a violation of UEFI Spec.)<br />
# Any graphics/video card issues that occur in UEFI boot alone and not in BIOS boot? Like Nvidia closed-source driver's lack of Kernel Mode Setting etc.<br />
<br />
{{Note|In any user discussion in irc , forum or mailing lists etc. regarding UEFI, add your system info here and link to this page in the discussion to help solve the issue(s) quickly.}}<br />
<br />
Original Post: https://bbs.archlinux.org/viewtopic.php?id=133074.<br />
<br />
----<br />
<br />
=== Lenovo ThinkPad t420s ===<br />
<br />
* intel core i7 2640M 2.80GHz<br />
* Phoenix SecureCore Tiano, 2011<br />
* UEFI bios version 8CET51WW (1.31), dated 2011-11-29<br />
* efibootmgr can create entries in menu just fine. looks good.<br />
* FAT32<br />
=== Lenovo ThinkPad x121e ===<br />
<br />
# Model: Lenovo ThinkPad x121e 3045CTO<br />
# Processor: Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel<br />
# BIOS/UEFI vendor: Phoenix SecureCore Tiano<br />
# Could create a working entry in UEFI Boot menu using efibootmgr.<br />
# Have not managed to launch UEFI shell.<br />
# Filesystem of UEFI System Partition : FAT16. FAT32 does ''NOT'' work. More info at https://bbs.archlinux.org/viewtopic.php?id=131149.<br />
<br />
==== Additional notes ====<br />
* Works fine with MBR partition map in BIOS mode.<br />
* Also works fine with GPT partition map in UEFI mode but ONLY if the EFI partition is formatted as fat 16.<br />
* Cannot get it to boot from a GPT disk in BIOS mode.<br />
* I did not try archboot.<br />
<br />
=== Lenovo ThinkCenter M92z ===<br />
# Intel(R) Pentium(R) CPU G2020 @ 2.90GHz<br />
# Motherboard: Lenovo MAHOBAY<br />
# Bios Version: American Megatrends, flashed with 9NKT60AUS Lenovo Bios Update, Release Date: 1/16/2014 <br />
# Use of efibootmgr: see just below<br />
# UEFI V.2.3.1 <br />
# I did not try to create entries with bcfg<br />
# Filesystem of UEFI System Partition? FAT32.<br />
<br />
Notes:<br />
The main problem of this computer is that the entries created by efibootmgr sometimes disappear after the next reboot.<br />
Example after the reboot:<br />
<br />
Boot0000* rEFInd Boot Manager Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)<br />
Boot0001* debian HD(1,800,f3800,b500458e-3e0e-4299-bc41-48424508bced)File(\EFI\debian\grubx64.efi)<br />
<br />
In this case after I installed the debian entry, a part of the entry for '''rEFInd''' disappeared.<br />
A step by step boot configuration with refind is available here: https://gist.github.com/EmmanuelKasper/9590327<br />
<br />
<br />
=== Intel DZ77GA-70K ===<br />
# System OEM/Vendor (like Dell, HP, Lenovo etc.) and Model (like ThinkPad x121e etc.) - all info needed <br />
#* Intel DZ77GA-70K<br />
# Processor with the model number (full info like Intel Core i7 xxxx 1.8 GHz - for eg.)<br />
#* Intel Core i7 3770K<br />
# Chipset info (Intel P67 or H67 etc.)<br />
#* Z77<br />
# Motherboard with full model number - required if desktop, optional for laptop<br />
#* Intel DZ77GA-70K<br />
# BIOS/UEFI vendor - AMI Aptio, Phoenix SecureCore Tiano, Insyde H2O etc. (very important) with updated month/year (will be shown as copyright year in some firmwares)<br />
#* (from hardinfo, under a bios boot)<br />
-BIOS-<br />
Date : 07/13/2012<br />
Vendor : Intel Corp. (www.intel.com)<br />
Version : GAZ7711H.86A.0049.2012.0713.1518<br />
-Board-<br />
Name : DZ77GA-70K<br />
Vendor : Intel Corporation (www.intel.com)<br />
# Were you able to create a working entry in UEFI Boot menu using efibootmgr? Any specific issues like black screen or something like http://forum-en.msi.com/index.php?topic=153411.0 ?<br />
#* No. Linux cannot boot through uefi on this motherboard, with this bios revision.<br />
# If you were able to launch the UEFI Shell in ways other than using {{ic|(USB)/efi/boot/bootx64.efi}} or Archboot, how?<br />
#* No, however bootx64.efi works, archboot does not.<br />
# Output of UEFI Shell "ver" command.<br />
UEFI Interactive Shell v2.0<br />
Copyright 2009-2011 Intel(r) Corporation. All rights reserved. Beta build 1.0<br />
UEFI v2.31 (American Megatrends, 0x0004028D)<br />
# If efibootmgr did not work for you and you were able to launch UEFI Shell, did you use bcfg command to create UEFI Boot Menu entry? Did bcfg created boot entry work for you?<br />
#* booting through bcfg produced the same results as booting from the shell, didn't work.<br />
# Filesystem of UEFI System Partition? FAT32 or FAT16? (Mostly it should be FAT32 but some firmwares have problems with it, which is a violation of UEFI Spec.)<br />
#* Both FAT32 and FAT16 do not work.<br />
# Any graphics/video card issues that occur in UEFI boot alone and not in BIOS boot? Like Nvidia closed-source driver's lack of Kernel Mode Setting etc.<br />
#* Kernel hangs after attempting to boot, no graphics output after changing to the kernel. Graphics output before that is fine.<br />
<br />
==== Additional notes ====<br />
More info at [https://bbs.archlinux.org/viewtopic.php?id=146990 archlinux forums] and [http://unix.stackexchange.com/questions/45312/how-can-i-tell-if-i-have-a-bug-with-my-kernel-or-with-my-bios-firmware stack overflow]. Similar problems with [http://comments.gmane.org/gmane.linux.redhat.fedora.devel/167170 a different motherboard]. Seems to be a buggy uefi implementation by intel.<br />
<br />
mihanson on '''2013-07-21''': tried with latest BIOS, version 0066, and the results are the same as the above. No go in UEFI mode on the Intel DZ77GA-70K.<br />
----<br />
<br />
=== Asus M5A99X EVO ===<br />
# System OEM/Vendor<br />
#* Asus M5A99X EVO<br />
# Processor with the model number<br />
#* AMD FX(tm)-8150 Eight-Core Processor<br />
# Chipset info<br />
#* AMD 990X/SB950<br />
# BIOS/UEFI vendor<br />
Vendor: American Megatrends Inc.<br />
Version: 0901<br />
Release Date: 12/02/2011<br />
# Were you able to create a working entry in UEFI Boot menu using efibootmgr?<br />
#* Yes<br />
# If you were able to launch the UEFI Shell in ways other than using {{ic|(USB)/efi/boot/bootx64.efi}} <br />
#* Yes, option in the Exit menu of the UEFI BIOS "Launch UEFI from system partition"<br />
# Output of UEFI Shell "ver" command.<br />
#* To be updated<br />
# Filesystem of UEFI System Partition? FAT32 or FAT16? <br />
#* FAT32<br />
# Any graphics/video card issues that occur in UEFI boot alone and not in BIOS boot? Like Nvidia closed-source driver's lack of Kernel Mode Setting etc.<br />
#* No<br />
<br />
----<br />
<br />
=== HP EliteBook 840 G1 ===<br />
See [[HP_EliteBook_840_G1]] for details.<br />
<br />
=== Lenovo Thinkpad Edge E430 3254-DAQ ===<br />
<br />
The below information was added by user [[User:The.ridikulus.rat]] .<br />
<br />
==== System Info ====<br />
<br />
# [[Lenovo_ThinkPad_Edge_E430|Lenovo Thinkpad Edge E430]] 3254-DAQ (India)<br />
# Intel Core i5 3210M 2.50 GHz (3rd Gen aka Ivy Bridge), 4 GB DDR3 RAM<br />
# Intel HM77 Express Chipset<br />
# UEFI Firmware Vendor : Phoenix SecureCore Tiano<br />
# UEFI/BIOS Version : [http://support.lenovo.com/en_IN/downloads/detail.page?DocID=DS033265 H0ET91WW] (2.51)<br />
# Embedded Controller Version : H0HT91WW (2.51)<br />
# UEFI Specification/Revision : 2.31 (ie. 2.3.1)<br />
# Lenovo UEFI/BIOS Build Date : 01-APR-2013<br />
# External Ports: 3 USB 3.0, 1 USB 2.0, 1 VGA, 1 HDMI, 1 RJ45 Ethernet/LAN port (Realtek), 1 ExpressCard 34 port, 1 3.5mm Headphones jack<br />
# 1 Tray-Load CD/DVD Writer <br />
# Switchable Graphics : Intel HD Graphics 4000 and Nvidia GeForce 610M (1GB Dedicated RAM)<br />
# WiFi / WLAN Card : Intel Centrino Wireless-N 2230 (B/G/N + Bluetooth 4.0)<br />
<br />
==== Observations ====<br />
<br />
# UEFI Secure Boot support is present in firmware, but I have currently disabled it. System came pre-installed with Windows 7 Pro x64 in BIOS-MBR mode, with BIOS version 1.14 (which did not include UEFI Secure Boot).<br />
# After BIOS update, all boot entries got erased and I had to recreate them using efibootmgr.<br />
# Using a 1 GiB FAT32 UEFISYS partition (/dev/sda1) mounted at /boot/efi (i.e. separate from /boot). Kernel and initramfs files synced during update using [[UEFI_Bootloaders#Sync_EFISTUB_Kernel_in_UEFISYS_partition_using_Systemd]].<br />
# No issues with efibootmgr for creating entries for rEFInd and GRUB 2.x . But unable to create direct EFISTUB entries as described at [[UEFI_Bootloaders#Using_efibootmgr_entry]] (echo'ed kernel parameters are truncated by efibootmgr).<br />
# Currently using rEFInd (textonly mode) as main boot manager (1st in boot menu) with grub-efi-x86_64 (2nd in boot menu) and grub-bios installed as fallback. rEFInd is first in boot menu (installed at {{ic|<UEFISYS>/EFI/refind/refindx64.efi}}). No need for {{ic|/EFI/Microsoft/Boot/bootmgfw.efi}} hack. Dual-booting Windows 8 Pro x64 UEFI-GPT (chainloaded from rEFInd/GRUB) works without any issues. Windows boot files are stored in same UEFISYS partition.<br />
# Both UEFI Shell v2 and v1 work, launched from rEFInd or grub-efi-x86_64. No option in the firmware setup/menu to directly launch the shell. <br />
# Currently using only intel and nouveau drivers. Haven't yet tried nvidia binary drivers and bumblebee graphics switching support. Kernel Mode Setting enabled.<br />
# grub-bios works if the firmware is changed to boot "Legacy only" without any boot/active flag in 0xEE Protective MBR partition entry.<br />
# Gummiboot v8 works fine without any errors.<br />
# Using only PARTUUID in /etc/fstab and in bootloader config files.<br />
<br />
==== Important Info ====<br />
<br />
I didn't use Archiso or Archboot to install the system. I transferred the Arch installation from my old Sony Vaio laptop to my new Thinkpad E430 using an external USB HDD and rsync from within SystemRescueCD, after manually creating the partitions using GParted, and then manually setup fstab and rEFInd. After that I rebooted into Arch and installed grub-efi-x86_64 and grub-bios.<br />
<br />
======From WonderWoofy======<br />
<br />
On an E430-3254(CTO) I had the same issues as the.ridikulus.rat with efibootmgr and truncated kerl command line parameters. This usually lead to the inability of the kernel to find the initramfs. What I ended up doing is putting the kernel and intramfs in the root of the ESP, and from there the efibootmgr entries worked nicely. This does lead to an ESP that is not organized in the recommended way though.<br />
<br />
Also, I did actually install via Archboot, and all worked fine. I have actually installed twice on this machine, once to a Momentus XT and once to a Samsung 830. The first time I used a CD, and therefore selected the "UEFI First" preference in the bios. This supposedly will try UEFI (\EFI\boot\bootx64.efi) first, and if that fails it will look to the MBR. Unfortunately, it did not honor this setting for the optical drive, and I had to turn off legacy bios mode entirely to get it to boot in UEFI from the CD. Interestingly, this "UEFI First" setting works just fine for interal drives. USB flash drives are a whole different story though, and more information can be found [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Create_UEFI_bootable_USB_from_ISO here].<br />
----<br />
<br />
=== System76 Galago UltraPro ===<br />
<br />
==== System Info ====<br />
<br />
* System76 Galago UltraPro (Clevo W740SU)<br />
* intel core i7 4750HQ 2.0GHz<br />
* intel HM87 Chipset<br />
* Original firmware version unknown, but from American Megatrends Inc.<br />
* Boot in UEFI mode only possible by starting an UEFI shell via the BIOS setup ({{ic|$esp/shellx64.efi}})<br />
* UEFI menu entries could be created by using efibootmgr, but without them being shown in the bootup menu<br />
* ESP filesystem: FAT32<br />
* '''Note:''' UEFI boot is not officially supported by System76<br />
<br />
==== Fix ====<br />
<br />
* Download the Clevo W740SU firmware from [http://repo.palkeo.com/clevo-mirror/W740SU/].<br />
* Flash it using any FreeDOS live medium<br />
* The new firmware is from American Megatrends Inc. V.4.6.5 08/13/2013<br />
* The new firmware doesn't support mixed BIOS and UEFI support, so you have to manually switch if you want to boot from a medium that doesn't support UEFI.<br />
----<br />
<br />
=== Intel Atom System-on-Chip ===<br />
<br />
Intel Atom System-on-Chip (SoC) is the Intel's answer to ARM SoC, primarily targeting Smartphones and Tablets (not regular Desktop and Notebook PCs).<br />
<br />
{{Note|This section was written based on information available online, not based on experience by an actual user of any Intel Atom SoC system.}}<br />
<br />
{{Note|Intel Atom SoC systems that ship with Windows 8/8.1 32-bit provide 32-bit UEFI-only firmware with no BIOS compatibility option (no CSM). In UEFI terms these systems are called Class 3 systems (this term is not specific to 32-bit), ie. UEFI-only with no BIOS CSM. These Atom SoC systems are therefore called as 32-bit UEFI Class 3 systems, and these can be booted only using a 32-bit UEFI bootable USB, which is not provided by default in [[Archiso]] (official install iso) and [[Archboot]]. These systems also come with UEFI Secure Boot enabled by default, but the firmware setup provides option(s) to disable Secure Boot as mandated by Microsoft for x86 systems.}}<br />
<br />
'''Related Links:'''<br />
* [[Wikipedia:Atom (system on chip)]]<br />
<br />
==== MinnowBoard ====<br />
<br />
The MinnowBoard is an Intel Atom SoC based board similar to Raspberry Pi or BeagleBoard. It ships with [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome Tianocore UDK] based 32-bit UEFI-only firmware which does not contain CSM support (no Legacy BIOS boot). The embedded Atom processor is supports only 32-bit, hence it is not possible to replace the 32-bit UEFI in the board with 64-bit (x86_64) UEFI. See below links for more info.<br />
<br />
'''Related Links:'''<br />
* http://www.minnowboard.org/<br />
* http://www.elinux.org/MinnowBoard<br />
* http://uefidk.intel.com/content/minnowboard-uefi-firmware<br />
<br />
==== Intel Atom SoC Clover Trail ====<br />
<br />
Intel Atom SoC Clover Trail processors are 32-bit only, hence they contain only 32-bit UEFI firmware. Officially Intel has stated that Linux will not be supported in Clover Trail tablets. Apart from this, Intel has not released the Clover Trail power-management and (PowerVR based) graphics code for Linux. Hence these systems may not work reliably with Linux.<br />
<br />
'''Related Links:'''<br />
* http://download.lenovo.com/luc/dml/Tablet2_Imaging_considerations.pdf<br />
* http://arstechnica.com/information-technology/2012/09/intel-declares-clover-trail-atom-processor-a-no-linux-zone/<br />
<br />
==== Intel Atom SoC Bay Trail ====<br />
<br />
Intel Atom SoC Bay Trail processors actually support 64-bit, but these tablets ship with only Windows 8/8.1 32-bit (not 64-bit) because of a feature called '''Connected Standby''' (also called '''InstantGo''') which is mandated by Microsoft to be enabled, but currently supported only by Windows 8/8.1 32-bit version (not 64-bit, as of October 2013). '''Connected Standby''' requirements (by Microsoft) include tablets to support only UEFI boot (hence no BIOS CSM) and UEFI bitness to match the OS bitness (hence 32-bit UEFI for sake of Win 8/8.1 32-bit). With only 32-bit UEFI and lack of BIOS compatibility, even Windows XP/Vista/7 32-bit (no UEFI support) and 64-bit (cannot boot in 32-bit UEFI) cannot be installed in these systems. These systems are truly locked to Windows 8/8.1 32-bit (UEFI mode). <br />
<br />
In these systems it should (theoretically) be possible to install 64-bit Linux provided the kernel is instructed to not access EFI runtime code using the '''noefi''' kernel parameter, due to the kernel/UEFI bitness mismatch. Unlike Clover Trail, Intel has stated that Bay Trail will support Android (which is based on Linux), and its graphics is based on Intel HD graphics (not PowerVR). Therefore, Bay Trail systems may work better with Linux compared to Clover Trail.<br />
<br />
'''Related Links:'''<br />
* [[Wikipedia:Connected Standby]]<br />
* http://www.pcworld.com/article/2048599/windows-81-tablets-with-64bit-atom-chips-not-coming-until-q1.html</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=317287Dual boot with Windows2014-05-31T00:02:31Z<p>The.ridikulus.rat: Fix info about windows 8 32-bit UEFI support</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Getting and installing Arch]]<br />
[[ja:Windows and Arch Dual Boot]]<br />
[[ru:Windows and Arch Dual Boot]]<br />
[[sk:Windows and Arch Dual Boot]]<br />
[[zh-cn:Windows and Arch Dual Boot]]<br />
This is a simple article detailing different methods of Arch/Windows coexistence.<br />
<br />
== Important information ==<br />
<br />
=== Windows UEFI vs BIOS limitations ===<br />
<br />
Microsoft imposes limitations on which firmware boot mode and partitioning style can be supported based on the version of Windows used:<br />
<br />
* '''Windows XP''' both '''x86 32-bit''' and '''x86_64''' (also called x64) (RTM and all Service Packs) versions do not support booting in UEFI mode (IA32 or x86_64) from any disk (MBR or GPT) OR in BIOS mode from GPT disk. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' or '''7''' '''x86 32-bit''' (RTM and all Service Packs) versions support booting in BIOS mode from MBR/msdos disks only, not from GPT disks. They do not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista RTM x86_64''' (only RTM) version support booting in BIOS mode from MBR/msdos disks only, not from GPT disks. It does not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. It supports only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' (SP1 and above, not RTM) and '''Windows 7''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 (x86 32-bit) UEFI boot from GPT/MBR disk, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
* '''Windows 8/8.1 x86 32-bit''' support booting in IA32 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support x86_64 UEFI boot from GPT/MBR disk, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk. On market, the only systems known to ship with IA32 (U)EFI are some old Intel Macs (pre-2010 models?) and Intel Atom System-on-Chip (Clover trail and Bay Trail) Windows Tablets. in which it boots ONLY in IA32 UEFI mode and ONLY from GPT disk.<br />
* '''Windows 8/8.1''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
<br />
In case of pre-installed Systems:<br />
<br />
* All systems pre-installed with Windows XP, Vista or 7 32-bit, irrespective of Service Pack level, bitness, edition (SKU)or presence of UEFI support in firmware, boot in BIOS-MBR mode by default.<br />
* MOST of the systems pre-installed with Windows 7 x86_64, irrespective of Service Pack level, bitness or edition (SKU), boot in BIOS-MBR mode by default. Very few recent systems pre-installed with Windows 7 are known to boot in x86_64 UEFI-GPT mode by default.<br />
* ALL systems pre-installed with Windows 8/8.1 boot in UEFI-GPT mode. The firmware bitness matches the bitness of Windows, ie. x86_64 Windows 8/8.1 boot in x86_64 UEFI mode and 32-bit Windows 8/8.1 boot in IA32 UEFI mode.<br />
<br />
The best way to detect the boot mode of Windows is to do the following (info from [http://www.eightforums.com/tutorials/29504-bios-mode-see-if-windows-boot-uefi-legacy-mode.html here]):<br />
<br />
* Boot into Windows<br />
* Press Win key and 'R' to start the Run dialog<br />
* In the Run dialog type "msinfo32" and press Enter<br />
* In the '''System Information''' windows, select '''System Summary''' on the left and check the value of '''BIOS mode''' item on the right<br />
* If the value is '''UEFI''', Windows boots in UEFI-GPT mode. If the value is '''Legacy''', Windows boots in BIOS-MBR mode.<br />
<br />
In general, Windows forces type of partitioning depending on the firmware mode used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR (also called '''msdos''' style partitioning) disk. This is a limitation enforced by Windows installer, and as of April 2014 there is no officially (Microsoft) supported way of installing Windows in UEFI-MBR or BIOS-GPT configuration Thus Windows only supports either UEFI-GPT boot or BIOS-MBR configuration.<br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on which bootloader is used and/or how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since installation procedure of bootloader depends on the firmware type and disk partitioning configuration. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, ie. either go for UEFI-GPT boot or BIOS-MBR boot. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Install media limitations ===<br />
<br />
Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) provide only IA32 UEFI firmware WITHOUT Legacy BIOS (CSM) support (unlike most of the x86_64 UEFI systems), due to Microsoft Connected Standby Guidelines for OEMs. Due to lack of Legacy BIOS support in these systems, and the lack of 32-bit UEFI boot in Arch Official Install ISO or the Archboot iso (as of April 2014), these install media cannot boot in Atom SoC tablets pre-installed with Windows 8/8.1 32-bit.<br />
<br />
=== Bootloader UEFI vs BIOS limitations ===<br />
<br />
Most of the linux bootloaders installed for one firmware type cannot launch or chainload bootloaders of other firmware type. That is, if Arch is installed in UEFI-GPT or UEFI-MBR mode in one disk and Windows is installed in BIOS-MBR mode in another disk, the UEFI bootloader used by Arch cannot chainload the BIOS installed Windows in the other disk. Similarly if Arch is installed in BIOS-MBR or BIOS-GPT mode in one disk and Windows is installed in UEFI-GPT in another disk , the BIOS bootloader used by Arch cannot chainload UEFI installed Windows in the other disk. <br />
<br />
The only exceptions to this are grub(2) in Apple Macs in which EFI installed grub(2) can boot BIOS installed OS via '''appleloader''' command (does not work in non-Apple systems), and rEFInd which technically supports booting legacy BIOS OS from UEFI systems, but [http://rodsbooks.com/refind/using.html#legacy does not always work in non-Apple UEFI systems] as per its author Rod Smith. <br />
<br />
However if Arch is installed in BIOS-GPT in one disk and Windows is installed in BIOS-MBR mode in another disk, then the BIOS bootloader used by Arch CAN boot the Windows in the other disk, if the bootloader itself has the ability to chainload from another disk. <br />
<br />
{{Note|If Arch and Windows are dual-booting from same disk, then Arch SHOULD follow the same firmware boot mode and partitioning combination used by the installed Windows in the disk.}}<br />
<br />
=== UEFI Secure Boot ===<br />
<br />
All pre-installed Windows 8/8.1 systems by default boot in UEFI-GPT mode and have UEFI Secure Boot enabled by default (which can be manually disabled by the user) and Legacy BIOS support (CSM) disabled by default (which can be manually enabled by the user, if the firmware supports it) in the firmware. This is mandated by Microsoft for all OEM pre-installed systems.<br />
<br />
Arch Linux install media currently supports Secure Boot but it requires some manual steps by the user to [[UEFI#Secure_Boot|setup the HashTool while booting]]. There it is advisable to disable UEFI Secure Boot in the firmware setup before attempting to boot Arch Linux. Windows 8/8.1 SHOULD continue to boot fine even if Secure boot is disabled. <br />
<br />
The only issue with regards to disabling UEFI Secure Boot support is that it requires physical access to the system to disable secure boot option in the firmware setup, as Microsoft has explicitly forbidden presence of any method to remotely or programmatically (from within OS) disable secure boot in all Windows 8/8.1 pre-installed systems<br />
<br />
=== Fast Start-Up ===<br />
<br />
Fast Start-Up is a feature in Windows 8 that hibernates the computer rather than actually shutting it down to speed up boot times. Your system can lose data if Windows hibernates and you dual boot into another OS and make changes to files. Even if you don't intend to share filesystems, the EFI System Partition is likely to be damaged on an EFI system. Therefore, you should disable Fast Startup, as described [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html here], before you install Linux on any computer that uses Windows 8.<br />
<br />
{{Pkg|ntfs-3g}} added a [http://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/559270a8f67c77a7ce51246c23d2b2837bcff0c9/ safe-guard] to prevent read-write mounting of hibernated disks, but the NTFS driver within the Linux kernel has no such safeguard.<br />
<br />
=== Windows filenames limitations ===<br />
<br />
Windows is limited to filepaths being shorter than [http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx 260 characters].<br />
<br />
Windows also puts [http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conventions certain characters off limits] in filenames for reasons that run all the way back to DOS:<br />
<br />
* < (less than)<br />
* > (greater than)<br />
* : (colon)<br />
* " (double quote)<br />
* / (forward slash)<br />
* \ (backslash)<br />
* | (vertical bar or pipe)<br />
* ? (question mark)<br />
* * (asterisk)<br />
<br />
These are limitations of Windows and not NTFS: any other OS using the NTFS partition will be fine. Windows will fail to detect these files and running {{ic|chkdsk}} will most likely cause them to be deleted. This can lead to potential data-loss.<br />
<br />
'''NTFS-3G''' applies Windows restrictions to new file names through the [http://www.tuxera.com/community/ntfs-3g-manual/#4 windows_filenames] option (see [[fstab]]).<br />
<br />
== Installation ==<br />
<br />
The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create additional partitions for Linux while leaving the existing Windows partitions untouched.<br />
<br />
=== BIOS systems ===<br />
<br />
==== Using a Linux boot loader ====<br />
<br />
You may use [[GRUB#Dual-booting|GRUB]] or [[Syslinux#Chainloading|Syslinux]].<br />
<br />
==== Using Windows boot loader ====<br />
<br />
With this setup the Windows bootloader loads GRUB which then boots Arch. <br />
<br />
===== Windows Vista/7/8/8.1 boot loader =====<br />
<br />
The following section contains excerpts from http://www.iceflatline.com/2009/09/how-to-dual-boot-windows-7-and-linux-using-bcdedit/.<br />
<br />
The remainder of the setup is similar to a typical installation. Some documents state that the partition being loaded by the Windows boot loader must be a primary partition but I have used this without problem on an extended partition.<br />
<br />
* When installing the GRUB boot loader, install it on your {{ic|/boot}} partition rather than the MBR. {{Note|For instance, my {{ic|/boot}} partition is {{ic|/dev/sda5}}. So I installed GRUB at {{ic|/dev/sda5}} instead of {{ic|/dev/sda}}. For help on doing this, see [[GRUB#Install to partition or partitionless disk]]}}<br />
<br />
* Under Linux make a copy of the boot info by typing the following at the command shell:<br />
<br />
my_windows_part=/dev/sda3<br />
my_boot_part=/dev/sda5<br />
mkdir /media/win<br />
mount $my_windows_part /media/win<br />
dd if=$my_boot_part of=/media/win/linux.bin bs=512 count=1<br />
<br />
* Boot to Windows and open up and you should be able to see the FAT32 partition. Copy the linux.bin file to {{ic|C:\}}. Now run '''cmd''' with administrator privileges (navigate to ''Start > All Programs > Accessories'', right-click on ''Command Prompt'' and select ''Run as administrator''):<br />
<br />
bcdedit /create /d “Linux” /application BOOTSECTOR<br />
<br />
* BCDEdit will return an alphanumeric identifier for this entry that I will refer to as {ID} in the remaining steps. You’ll need to replace {ID} by the actual returned identifier. An example of {ID} is {d7294d4e-9837-11de-99ac-f3f3a79e3e93}. <br />
<br />
bcdedit /set {ID} device partition=c:<br />
bcdedit /set {ID} path \linux.bin<br />
bcdedit /displayorder {ID} /addlast<br />
bcdedit /timeout 30<br />
<br />
Reboot and enjoy. In my case I'm using the Windows boot loader so that I can map my Dell Precision M4500's second power button to boot Linux instead of Windows.<br />
<br />
===== Windows 2000/XP boot loader =====<br />
<br />
For information on this method see http://www.geocities.com/epark/linux/grub-w2k-HOWTO.html. I do not believe there are any distinct advantages of this method over the Linux boot loader; you will still need a {{ic|/boot}} partition, and this one is arguably more difficult to set up.<br />
<br />
=== UEFI systems ===<br />
<br />
Both [[Gummiboot]] and [[rEFInd]] autodetect '''Windows Boot Manager''' {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} and show it in their boot menu, so there is no manual config required.<br />
<br />
For [[GRUB]](2) follow [[GRUB#Windows_Installed_in_UEFI-GPT_Mode_menu_entry]].<br />
<br />
Syslinux (as of version 6.02 and 6.03-pre9) and ELILO do not support chainloading other EFI applications, so they cannot be used to chainload {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} .<br />
<br />
Computers that come with newer versions of Windows often have [[UEFI#Secure_Boot|secure boot]] enabled. You will need to take extra steps to either disable secure boot or to make your installation media compatible with secure boot.<br />
<br />
== Time standard ==<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC, following [[Time#UTC in Windows]]. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to ''localtime''.<br />
<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable any time-related services, like [[Network Time Protocol daemon|NTPd]] . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=140049 Booting Windows from a desktop shortcut]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=311521GRUB2014-04-23T00:23:27Z<p>The.ridikulus.rat: /* GRUB Standalone */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of boot sectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partiton (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath}/grub.cfg should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
{{Warning|Since package version 1:2.02.beta2-1 (2014-01-10) grub-mkconfig generates ''weird'' configuration files. The generated {{ic|grub.cfg}} contains duplicated boot-entries which are sometimes missing the initramfs, furthermore self-compiled kernels are hidden in a submenu. ({{bug|38455}})}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
{{Note|The example assumes that the ISO is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Redundant menu entries ===<br />
For new installations of GRUB it is possible that multiple redundant menu entries will be generated. This is because both the upstream default {{ic|/etc/grub.d/10_linux}} script and the Arch specific {{ic|/etc/grub.d/10_archlinux}} script are creating menu entries when the grub-mkconfig command is run. To correct this behaviour disable the 10_linux script and then run the grub-mkconfig command again.<br />
# chmod -x /etc/grub.d/10_linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=311426Unified Extensible Firmware Interface2014-04-22T00:26:13Z<p>The.ridikulus.rat: Few informative 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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== Differences between BIOS and UEFI ==<br />
<br />
See [[Arch boot process#Firmware_types]] for more details.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/BOOT/BOOTX64.EFI}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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 />
=== Secure Boot ===<br />
For an overview about Secure Boot in Linux see http://www.rodsbooks.com/efi-bootloaders/secureboot.html. This section focuses on how to set up Secure Boot in Arch Linux. For the time being, this section is limited to explain the procedure of booting the archiso with Secure Boot enabled.<br />
Booting the archiso with Secure Boot enabled is possible since the efi applications ''PreLoader.efi'' and ''HashTool.efi'' have been added to it. A message will show up that says ''Failed to Start loader... I will now execute HashTool.'' To use HashTool for enrolling the hash of ''loader.efi'' and ''vmlinuz.efi'', follow these steps.<br />
* Select {{ic|OK}}<br />
* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}<br />
The archiso boots, and you are presented with a shell prompt, automatically logged in as root. To check if the archiso was booted with SecureBoot, use this command:<br />
<br />
$ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data<br />
<br />
If yes, this command returns 1. The characters denoted by 1234 differ from machine to machine. To help with this, you can use tab completion or list the efi variables.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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}}<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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<br />
<br />
=== Windows changes boot order ===<br />
In some motherboards (confirmed in ASRock Z77 Extreme4) Windows 8 changes the boot order in the NVRAM everytime is booted. This can be fixed making the Windows Boot Manager to load another loader instead of booting Windows.<br />
Run this command in a Administrator mode console in Windows:<br />
bcdedit /set {bootmgr} path \EFI\boot_app_dir\boot_app.efi<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the label of the USB disk e.g. {{ic|ARCH_201404}}):<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ 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 />
* [[Wikipedia:EFI System partition]]<br />
* [http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/ The EFI System Partition and the Default Boot Behavior]<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>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=310766Unified Extensible Firmware Interface2014-04-18T00:48:49Z<p>The.ridikulus.rat: /* Linux Kernel Config options for UEFI */</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== Differences between BIOS and UEFI ==<br />
<br />
See [[Arch boot process#Firmware_types]] for more details.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/BOOT/BOOTX64.EFI}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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 />
=== Secure Boot ===<br />
For an overview about Secure Boot in Linux see http://www.rodsbooks.com/efi-bootloaders/secureboot.html. This section focuses on how to set up Secure Boot in Arch Linux. For the time being, this section is limited to explain the procedure of booting the archiso with Secure Boot enabled.<br />
Booting the archiso with Secure Boot enabled is possible since the efi applications ''PreLoader.efi'' and ''HashTool.efi'' have been added to it. A message will show up that says ''Failed to Start loader... I will now execute HashTool.'' To use HashTool for enrolling the hash of ''loader.efi'' and ''vmlinuz.efi'', follow these steps.<br />
* Select {{ic|OK}}<br />
* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}<br />
The archiso boots, and you are presented with a shell prompt, automatically logged in as root. To check if the archiso was booted with SecureBoot, use this command:<br />
<br />
$ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data<br />
<br />
If yes, this command returns 1. The characters denoted by 1234 differ from machine to machine. To help with this, you can use tab completion or list the efi variables.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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}}<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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<br />
<br />
=== Windows changes boot order ===<br />
In some motherboards (confirmed in ASRock Z77 Extreme4) Windows 8 changes the boot order in the NVRAM everytime is booted. This can be fixed making the Windows Boot Manager to load another loader instead of booting Windows.<br />
Run this command in a Administrator mode console in Windows:<br />
bcdedit /set {bootmgr} path \EFI\boot_app_dir\boot_app.efi<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=310360Dual boot with Windows2014-04-14T01:14:23Z<p>The.ridikulus.rat: /* Windows UEFI vs BIOS limitations */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Getting and installing Arch]]<br />
[[ja:Windows and Arch Dual Boot]]<br />
[[ru:Windows and Arch Dual Boot]]<br />
[[sk:Windows and Arch Dual Boot]]<br />
[[zh-cn:Windows and Arch Dual Boot]]<br />
This is a simple article detailing different methods of Arch/Windows coexistence.<br />
<br />
== Important information ==<br />
<br />
=== Windows UEFI vs BIOS limitations ===<br />
<br />
Microsoft imposes limitations on which firmware boot mode and partitioning style can be supported based on the version of Windows used:<br />
<br />
* '''Windows XP''' both '''32-bit''' and '''x86_64''' (also called x64) versions do not support booting in UEFI mode (IA32 or x86_64) from any disk (MBR or GPT) OR in BIOS mode from GPT disk. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' or '''7''' '''32-bit''' (RTM and all Service Packs) versions support booting in BIOS mode from MBR/msdos disks only, not from GPT disks. They do not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' (SP1 and above, not RTM) and '''Windows 7''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 (x86 32-bit) UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
* '''Windows 8/8.1''' '''32-bit''' in general support only BIOS boot and only from MBR/msdos disk (similar to Windows 7 32-bit), EXCEPT Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) in which it boots ONLY in IA32 UEFI mode and ONLY from GPT disk. '''In all non-Atom SoC systems, Windows 8/8.1 32-bit supports only BIOS boot and only from MBR/msdos disk'''. No x86_64 UEFI boot support.<br />
* '''Windows 8/8.1''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
<br />
In case of pre-installed Systems:<br />
<br />
* All systems pre-installed with Windows XP, Vista or 7 32-bit, irrespective of Service Pack level, bitness, edition (SKU)or presence of UEFI support in firmware, boot in BIOS-MBR mode by default.<br />
* MOST of the systems pre-installed with Windows 7 x86_64, irrespective of Service Pack level, bitness or edition (SKU), boot in BIOS-MBR mode by default. Very few recent systems pre-installed with Windows 7 are known to boot in x86_64 UEFI-GPT mode by default.<br />
* ALL systems pre-installed with Windows 8/8.1 boot in UEFI-GPT mode. The firmware bitness matches the bitness of Windows, ie. x86_64 Windows 8/8.1 boot in x86_64 UEFI mode and 32-bit Windows 8/8.1 boot in IA32 UEFI mode.<br />
<br />
The best way to detect the boot mode of Windows is to do the following (info from [http://www.eightforums.com/tutorials/29504-bios-mode-see-if-windows-boot-uefi-legacy-mode.html here]):<br />
<br />
* Boot into Windows<br />
* Press Win key and 'R' to start the Run dialog<br />
* In the Run dialog type "msinfo32" and press Enter<br />
* In the '''System Information''' windows, select '''System Summary''' on the left and check the value of '''BIOS mode''' item on the right<br />
* If the value is '''UEFI''', Windows boots in UEFI-GPT mode. If the value is '''Legacy''', Windows boots in BIOS-MBR mode.<br />
<br />
In general, Windows forces type of partitioning depending on the firmware mode used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR (also called '''msdos''' style partitioning) disk. This is a limitation enforced by Windows installer, and as of April 2014 there is no officially (Microsoft) supported way of installing Windows in UEFI-MBR or BIOS-GPT configuration Thus Windows only supports either UEFI-GPT boot or BIOS-MBR configuration.<br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on which bootloader is used and/or how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since installation procedure of bootloader depends on the firmware type and disk partitioning configuration. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, ie. either go for UEFI-GPT boot or BIOS-MBR boot. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Install media limitations ===<br />
<br />
Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) provide only IA32 UEFI firmware WITHOUT Legacy BIOS (CSM) support (unlike most of the x86_64 UEFI systems), due to Microsoft Connected Standby Guidelines for OEMs. Due to lack of Legacy BIOS support in these systems, and the lack of 32-bit UEFI boot in Arch Official Install ISO or the Archboot iso (as of April 2014), these install media cannot boot in Atom SoC tablets pre-installed with Windows 8/8.1 32-bit.<br />
<br />
=== Bootloader UEFI vs BIOS limitations ===<br />
<br />
Most of the linux bootloaders installed for one firmware type cannot launch or chainload bootloaders of other firmware type. That is, if Arch is installed in UEFI-GPT or UEFI-MBR mode in one disk and Windows is installed in BIOS-MBR mode in another disk, the UEFI bootloader used by Arch cannot chainload the BIOS installed Windows in the other disk. Similarly if Arch is installed in BIOS-MBR or BIOS-GPT mode in one disk and Windows is installed in UEFI-GPT in another disk , the BIOS bootloader used by Arch cannot chainload UEFI installed Windows in the other disk. <br />
<br />
The only exceptions to this are grub(2) in Apple Macs in which EFI installed grub(2) can boot BIOS installed OS via '''appleloader''' command (does not work in non-Apple systems), and rEFInd which technically supports booting legacy BIOS OS from UEFI systems, but [http://rodsbooks.com/refind/using.html#legacy does not always work in non-Apple UEFI systems] as per its author Rod Smith. <br />
<br />
However if Arch is installed in BIOS-GPT in one disk and Windows is installed in BIOS-MBR mode in another disk, then the BIOS bootloader used by Arch CAN boot the Windows in the other disk, if the bootloader itself has the ability to chainload from another disk. <br />
<br />
{{Note|If Arch and Windows are dual-booting from same disk, then Arch SHOULD follow the same firmware boot mode and partitioning combination used by the installed Windows in the disk.}}<br />
<br />
=== UEFI Secure Boot ===<br />
<br />
All pre-installed Windows 8/8.1 systems by default boot in UEFI-GPT mode and have UEFI Secure Boot enabled by default (which can be manually disabled by the user) and Legacy BIOS support (CSM) disabled by default (which can be manually enabled by the user, if the firmware supports it) in the firmware. This is mandated by Microsoft for all OEM pre-installed systems.<br />
<br />
Arch Linux install media currently supports Secure Boot but it requires some manual steps by the user to [[UEFI#Secure_Boot|setup the HashTool while booting]]. There it is advisable to disable UEFI Secure Boot in the firmware setup before attempting to boot Arch Linux. Windows 8/8.1 SHOULD continue to boot fine even if Secure boot is disabled. <br />
<br />
The only issue with regards to disabling UEFI Secure Boot support is that it requires physical access to the system to disable secure boot option in the firmware setup, as Microsoft has explicitly forbidden presence of any method to remotely or programmatically (from within OS) disable secure boot in all Windows 8/8.1 pre-installed systems<br />
<br />
=== Fast Start-Up ===<br />
<br />
Fast Start-Up is a feature in Windows 8 that hibernates the computer rather than actually shutting it down to speed up boot times. Your system can lose data if Windows hibernates and you dual boot into another OS and make changes to files. Even if you don't intend to share filesystems, the EFI System Partition is likely to be damaged on an EFI system. Therefore, you should disable Fast Startup, as described [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html here], before you install Linux on any computer that uses Windows 8.<br />
<br />
[http://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/559270a8f67c77a7ce51246c23d2b2837bcff0c9/ NTFS-3G added a safe-guard] to prevent read-write mounting of hibernated disks, but the NTFS driver within the Linux kernel has no such safeguard.<br />
<br />
=== Windows filenames limitations ===<br />
<br />
Windows is limited to filepaths being shorter than [http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx 260 characters].<br />
<br />
Windows also puts [http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conventions certain characters off limits] in filenames for reasons that run all the way back to DOS:<br />
<br />
* < (less than)<br />
* > (greater than)<br />
* : (colon)<br />
* " (double quote)<br />
* / (forward slash)<br />
* \ (backslash)<br />
* | (vertical bar or pipe)<br />
* ? (question mark)<br />
* * (asterisk)<br />
<br />
These are limitations of Windows and not NTFS: any other OS using the NTFS partition will be fine. Windows will fail to detect these files and running {{ic|chkdsk}} will most likely cause them to be deleted. This can lead to potential data-loss.<br />
<br />
== Installation ==<br />
<br />
The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create additional partitions for Linux while leaving the existing Windows partitions untouched.<br />
<br />
=== BIOS systems ===<br />
<br />
==== Using a Linux boot loader ====<br />
<br />
You may use [[GRUB#Dual-booting|GRUB]] or [[Syslinux#Chainloading|Syslinux]].<br />
<br />
==== Using Windows boot loader ====<br />
<br />
With this setup the Windows bootloader loads GRUB which then boots Arch. <br />
<br />
===== Windows Vista/7/8/8.1 boot loader =====<br />
<br />
The following section contains excerpts from http://www.iceflatline.com/2009/09/how-to-dual-boot-windows-7-and-linux-using-bcdedit/.<br />
<br />
The remainder of the setup is similar to a typical installation. Some documents state that the partition being loaded by the Windows boot loader must be a primary partition but I have used this without problem on an extended partition.<br />
<br />
* When installing the GRUB boot loader, install it on your {{ic|/boot}} partition rather than the MBR. {{Note|For instance, my {{ic|/boot}} partition is {{ic|/dev/sda5}}. So I installed GRUB at {{ic|/dev/sda5}} instead of {{ic|/dev/sda}}. For help on doing this, see [[GRUB#Install to partition or partitionless disk]]}}<br />
<br />
* Under Linux make a copy of the boot info by typing the following at the command shell:<br />
<br />
my_windows_part=/dev/sda3<br />
my_boot_part=/dev/sda5<br />
mkdir /media/win<br />
mount $my_windows_part /media/win<br />
dd if=$my_boot_part of=/media/win/linux.bin bs=512 count=1<br />
<br />
* Boot to Windows and open up and you should be able to see the FAT32 partition. Copy the linux.bin file to {{ic|C:\}}. Now run '''cmd''' with administrator privileges (navigate to ''Start > All Programs > Accessories'', right-click on ''Command Prompt'' and select ''Run as administrator''):<br />
<br />
bcdedit /create /d “Linux” /application BOOTSECTOR<br />
<br />
* BCDEdit will return an alphanumeric identifier for this entry that I will refer to as {ID} in the remaining steps. You’ll need to replace {ID} by the actual returned identifier. An example of {ID} is {d7294d4e-9837-11de-99ac-f3f3a79e3e93}. <br />
<br />
bcdedit /set {ID} device partition=c:<br />
bcdedit /set {ID} path \linux.bin<br />
bcdedit /displayorder {ID} /addlast<br />
bcdedit /timeout 30<br />
<br />
Reboot and enjoy. In my case I'm using the Windows boot loader so that I can map my Dell Precision M4500's second power button to boot Linux instead of Windows.<br />
<br />
===== Windows 2000/XP boot loader =====<br />
<br />
For information on this method see http://www.geocities.com/epark/linux/grub-w2k-HOWTO.html. I do not believe there are any distinct advantages of this method over the Linux boot loader; you will still need a {{ic|/boot}} partition, and this one is arguably more difficult to set up.<br />
<br />
=== UEFI systems ===<br />
<br />
Both [[Gummiboot]] and [[rEFInd]] autodetect '''Windows Boot Manager''' {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} and show it in their boot menu, so there is no manual config required.<br />
<br />
For [[GRUB]](2) follow [[GRUB#Windows_Installed_in_UEFI-GPT_Mode_menu_entry]].<br />
<br />
Syslinux (as of version 6.02 and 6.03-pre9) and ELILO do not support chainloading other EFI applications, so they cannot be used to chainload {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} .<br />
<br />
Computers that come with newer versions of Windows often have [[UEFI#Secure_Boot|secure boot]] enabled. You will need to take extra steps to either disable secure boot or to make your installation media compatible with secure boot.<br />
<br />
== Time standard ==<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC, following [[Time#UTC in Windows]]. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to ''localtime''.<br />
<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable any time-related services, like [[Network Time Protocol daemon|NTPd]] . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=140049 Booting Windows from a desktop shortcut]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=310359Dual boot with Windows2014-04-14T01:14:04Z<p>The.ridikulus.rat: Add link to msinfo32 uefi or bios detection info</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Getting and installing Arch]]<br />
[[ja:Windows and Arch Dual Boot]]<br />
[[ru:Windows and Arch Dual Boot]]<br />
[[sk:Windows and Arch Dual Boot]]<br />
[[zh-cn:Windows and Arch Dual Boot]]<br />
This is a simple article detailing different methods of Arch/Windows coexistence.<br />
<br />
== Important information ==<br />
<br />
=== Windows UEFI vs BIOS limitations ===<br />
<br />
Microsoft imposes limitations on which firmware boot mode and partitioning style can be supported based on the version of Windows used:<br />
<br />
* '''Windows XP''' both '''32-bit''' and '''x86_64''' (also called x64) versions do not support booting in UEFI mode (IA32 or x86_64) from any disk (MBR or GPT) OR in BIOS mode from GPT disk. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' or '''7''' '''32-bit''' (RTM and all Service Packs) versions support booting in BIOS mode from MBR/msdos disks only, not from GPT disks. They do not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' (SP1 and above, not RTM) and '''Windows 7''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 (x86 32-bit) UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
* '''Windows 8/8.1''' '''32-bit''' in general support only BIOS boot and only from MBR/msdos disk (similar to Windows 7 32-bit), EXCEPT Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) in which it boots ONLY in IA32 UEFI mode and ONLY from GPT disk. '''In all non-Atom SoC systems, Windows 8/8.1 32-bit supports only BIOS boot and only from MBR/msdos disk'''. No x86_64 UEFI boot support.<br />
* '''Windows 8/8.1''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
<br />
In case of pre-installed Systems:<br />
<br />
* All systems pre-installed with Windows XP, Vista or 7 32-bit, irrespective of Service Pack level, bitness, edition (SKU)or presence of UEFI support in firmware, boot in BIOS-MBR mode by default.<br />
* MOST of the systems pre-installed with Windows 7 x86_64, irrespective of Service Pack level, bitness or edition (SKU), boot in BIOS-MBR mode by default. Very few recent systems pre-installed with Windows 7 are known to boot in x86_64 UEFI-GPT mode by default.<br />
* ALL systems pre-installed with Windows 8/8.1 boot in UEFI-GPT mode. The firmware bitness matches the bitness of Windows, ie. x86_64 Windows 8/8.1 boot in x86_64 UEFI mode and 32-bit Windows 8/8.1 boot in IA32 UEFI mode.<br />
<br />
The best way to detect the boot mode of Windows is to do the following (info from [http://www.eightforums.com/tutorials/29504-bios-mode-see-if-windows-boot-uefi-legacy-mode.html here]:<br />
<br />
* Boot into Windows<br />
* Press Win key and 'R' to start the Run dialog<br />
* In the Run dialog type "msinfo32" and press Enter<br />
* In the '''System Information''' windows, select '''System Summary''' on the left and check the value of '''BIOS mode''' item on the right<br />
* If the value is '''UEFI''', Windows boots in UEFI-GPT mode. If the value is '''Legacy''', Windows boots in BIOS-MBR mode.<br />
<br />
In general, Windows forces type of partitioning depending on the firmware mode used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR (also called '''msdos''' style partitioning) disk. This is a limitation enforced by Windows installer, and as of April 2014 there is no officially (Microsoft) supported way of installing Windows in UEFI-MBR or BIOS-GPT configuration Thus Windows only supports either UEFI-GPT boot or BIOS-MBR configuration.<br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on which bootloader is used and/or how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since installation procedure of bootloader depends on the firmware type and disk partitioning configuration. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, ie. either go for UEFI-GPT boot or BIOS-MBR boot. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Install media limitations ===<br />
<br />
Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) provide only IA32 UEFI firmware WITHOUT Legacy BIOS (CSM) support (unlike most of the x86_64 UEFI systems), due to Microsoft Connected Standby Guidelines for OEMs. Due to lack of Legacy BIOS support in these systems, and the lack of 32-bit UEFI boot in Arch Official Install ISO or the Archboot iso (as of April 2014), these install media cannot boot in Atom SoC tablets pre-installed with Windows 8/8.1 32-bit.<br />
<br />
=== Bootloader UEFI vs BIOS limitations ===<br />
<br />
Most of the linux bootloaders installed for one firmware type cannot launch or chainload bootloaders of other firmware type. That is, if Arch is installed in UEFI-GPT or UEFI-MBR mode in one disk and Windows is installed in BIOS-MBR mode in another disk, the UEFI bootloader used by Arch cannot chainload the BIOS installed Windows in the other disk. Similarly if Arch is installed in BIOS-MBR or BIOS-GPT mode in one disk and Windows is installed in UEFI-GPT in another disk , the BIOS bootloader used by Arch cannot chainload UEFI installed Windows in the other disk. <br />
<br />
The only exceptions to this are grub(2) in Apple Macs in which EFI installed grub(2) can boot BIOS installed OS via '''appleloader''' command (does not work in non-Apple systems), and rEFInd which technically supports booting legacy BIOS OS from UEFI systems, but [http://rodsbooks.com/refind/using.html#legacy does not always work in non-Apple UEFI systems] as per its author Rod Smith. <br />
<br />
However if Arch is installed in BIOS-GPT in one disk and Windows is installed in BIOS-MBR mode in another disk, then the BIOS bootloader used by Arch CAN boot the Windows in the other disk, if the bootloader itself has the ability to chainload from another disk. <br />
<br />
{{Note|If Arch and Windows are dual-booting from same disk, then Arch SHOULD follow the same firmware boot mode and partitioning combination used by the installed Windows in the disk.}}<br />
<br />
=== UEFI Secure Boot ===<br />
<br />
All pre-installed Windows 8/8.1 systems by default boot in UEFI-GPT mode and have UEFI Secure Boot enabled by default (which can be manually disabled by the user) and Legacy BIOS support (CSM) disabled by default (which can be manually enabled by the user, if the firmware supports it) in the firmware. This is mandated by Microsoft for all OEM pre-installed systems.<br />
<br />
Arch Linux install media currently supports Secure Boot but it requires some manual steps by the user to [[UEFI#Secure_Boot|setup the HashTool while booting]]. There it is advisable to disable UEFI Secure Boot in the firmware setup before attempting to boot Arch Linux. Windows 8/8.1 SHOULD continue to boot fine even if Secure boot is disabled. <br />
<br />
The only issue with regards to disabling UEFI Secure Boot support is that it requires physical access to the system to disable secure boot option in the firmware setup, as Microsoft has explicitly forbidden presence of any method to remotely or programmatically (from within OS) disable secure boot in all Windows 8/8.1 pre-installed systems<br />
<br />
=== Fast Start-Up ===<br />
<br />
Fast Start-Up is a feature in Windows 8 that hibernates the computer rather than actually shutting it down to speed up boot times. Your system can lose data if Windows hibernates and you dual boot into another OS and make changes to files. Even if you don't intend to share filesystems, the EFI System Partition is likely to be damaged on an EFI system. Therefore, you should disable Fast Startup, as described [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html here], before you install Linux on any computer that uses Windows 8.<br />
<br />
[http://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/559270a8f67c77a7ce51246c23d2b2837bcff0c9/ NTFS-3G added a safe-guard] to prevent read-write mounting of hibernated disks, but the NTFS driver within the Linux kernel has no such safeguard.<br />
<br />
=== Windows filenames limitations ===<br />
<br />
Windows is limited to filepaths being shorter than [http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx 260 characters].<br />
<br />
Windows also puts [http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conventions certain characters off limits] in filenames for reasons that run all the way back to DOS:<br />
<br />
* < (less than)<br />
* > (greater than)<br />
* : (colon)<br />
* " (double quote)<br />
* / (forward slash)<br />
* \ (backslash)<br />
* | (vertical bar or pipe)<br />
* ? (question mark)<br />
* * (asterisk)<br />
<br />
These are limitations of Windows and not NTFS: any other OS using the NTFS partition will be fine. Windows will fail to detect these files and running {{ic|chkdsk}} will most likely cause them to be deleted. This can lead to potential data-loss.<br />
<br />
== Installation ==<br />
<br />
The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create additional partitions for Linux while leaving the existing Windows partitions untouched.<br />
<br />
=== BIOS systems ===<br />
<br />
==== Using a Linux boot loader ====<br />
<br />
You may use [[GRUB#Dual-booting|GRUB]] or [[Syslinux#Chainloading|Syslinux]].<br />
<br />
==== Using Windows boot loader ====<br />
<br />
With this setup the Windows bootloader loads GRUB which then boots Arch. <br />
<br />
===== Windows Vista/7/8/8.1 boot loader =====<br />
<br />
The following section contains excerpts from http://www.iceflatline.com/2009/09/how-to-dual-boot-windows-7-and-linux-using-bcdedit/.<br />
<br />
The remainder of the setup is similar to a typical installation. Some documents state that the partition being loaded by the Windows boot loader must be a primary partition but I have used this without problem on an extended partition.<br />
<br />
* When installing the GRUB boot loader, install it on your {{ic|/boot}} partition rather than the MBR. {{Note|For instance, my {{ic|/boot}} partition is {{ic|/dev/sda5}}. So I installed GRUB at {{ic|/dev/sda5}} instead of {{ic|/dev/sda}}. For help on doing this, see [[GRUB#Install to partition or partitionless disk]]}}<br />
<br />
* Under Linux make a copy of the boot info by typing the following at the command shell:<br />
<br />
my_windows_part=/dev/sda3<br />
my_boot_part=/dev/sda5<br />
mkdir /media/win<br />
mount $my_windows_part /media/win<br />
dd if=$my_boot_part of=/media/win/linux.bin bs=512 count=1<br />
<br />
* Boot to Windows and open up and you should be able to see the FAT32 partition. Copy the linux.bin file to {{ic|C:\}}. Now run '''cmd''' with administrator privileges (navigate to ''Start > All Programs > Accessories'', right-click on ''Command Prompt'' and select ''Run as administrator''):<br />
<br />
bcdedit /create /d “Linux” /application BOOTSECTOR<br />
<br />
* BCDEdit will return an alphanumeric identifier for this entry that I will refer to as {ID} in the remaining steps. You’ll need to replace {ID} by the actual returned identifier. An example of {ID} is {d7294d4e-9837-11de-99ac-f3f3a79e3e93}. <br />
<br />
bcdedit /set {ID} device partition=c:<br />
bcdedit /set {ID} path \linux.bin<br />
bcdedit /displayorder {ID} /addlast<br />
bcdedit /timeout 30<br />
<br />
Reboot and enjoy. In my case I'm using the Windows boot loader so that I can map my Dell Precision M4500's second power button to boot Linux instead of Windows.<br />
<br />
===== Windows 2000/XP boot loader =====<br />
<br />
For information on this method see http://www.geocities.com/epark/linux/grub-w2k-HOWTO.html. I do not believe there are any distinct advantages of this method over the Linux boot loader; you will still need a {{ic|/boot}} partition, and this one is arguably more difficult to set up.<br />
<br />
=== UEFI systems ===<br />
<br />
Both [[Gummiboot]] and [[rEFInd]] autodetect '''Windows Boot Manager''' {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} and show it in their boot menu, so there is no manual config required.<br />
<br />
For [[GRUB]](2) follow [[GRUB#Windows_Installed_in_UEFI-GPT_Mode_menu_entry]].<br />
<br />
Syslinux (as of version 6.02 and 6.03-pre9) and ELILO do not support chainloading other EFI applications, so they cannot be used to chainload {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} .<br />
<br />
Computers that come with newer versions of Windows often have [[UEFI#Secure_Boot|secure boot]] enabled. You will need to take extra steps to either disable secure boot or to make your installation media compatible with secure boot.<br />
<br />
== Time standard ==<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC, following [[Time#UTC in Windows]]. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to ''localtime''.<br />
<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable any time-related services, like [[Network Time Protocol daemon|NTPd]] . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=140049 Booting Windows from a desktop shortcut]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=310358GRUB2014-04-14T01:08:22Z<p>The.ridikulus.rat: /* Dual-booting */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of boot sectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partiton (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
{{Note|Use {{AUR|grub-git}} package for standalone GRUB EFI image as the {{Pkg|grub}} package does not contain various grub-mkstandalone specific fixes (specifically {{ic|${cmdpath} }} support, which is necessary).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
{{Warning|Since package version 1:2.02.beta2-1 (2014-01-10) grub-mkconfig generates ''weird'' configuration files. The generated {{ic|grub.cfg}} contains duplicated boot-entries which are sometimes missing the initramfs, furthermore self-compiled kernels are hidden in a submenu. ({{bug|38455}})}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
{{Note|The example assumes that the ISO is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Redundant menu entries ===<br />
For new installations of GRUB it is possible that multiple redundant menu entries will be generated. This is because both the upstream default {{ic|/etc/grub.d/10_linux}} script and the Arch specific {{ic|/etc/grub.d/10_archlinux}} script are creating menu entries when the grub-mkconfig command is run. To correct this behaviour disable the 10_linux script and then run the grub-mkconfig command again.<br />
# chmod -x /etc/grub.d/10_linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=310357GRUB2014-04-14T00:58:52Z<p>The.ridikulus.rat: /* Windows installed in UEFI-GPT Mode menu entry */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of boot sectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partiton (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
{{Note|Use {{AUR|grub-git}} package for standalone GRUB EFI image as the {{Pkg|grub}} package does not contain various grub-mkstandalone specific fixes (specifically {{ic|${cmdpath} }} support, which is necessary).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
{{Warning|Since package version 1:2.02.beta2-1 (2014-01-10) grub-mkconfig generates ''weird'' configuration files. The generated {{ic|grub.cfg}} contains duplicated boot-entries which are sometimes missing the initramfs, furthermore self-compiled kernels are hidden in a submenu. ({{bug|38455}})}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$uuid}} are obtained with the following two commands. {{ic|$uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|bootmgr}}, not your "real" Windows partition (usually C:). When showing all UUIDs with {{ic|blkid}}, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
{{Note|The example assumes that the ISO is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Redundant menu entries ===<br />
For new installations of GRUB it is possible that multiple redundant menu entries will be generated. This is because both the upstream default {{ic|/etc/grub.d/10_linux}} script and the Arch specific {{ic|/etc/grub.d/10_archlinux}} script are creating menu entries when the grub-mkconfig command is run. To correct this behaviour disable the 10_linux script and then run the grub-mkconfig command again.<br />
# chmod -x /etc/grub.d/10_linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=310356GRUB2014-04-14T00:57:13Z<p>The.ridikulus.rat: Added note about windows bios chainload menuentries not working in uefi grub</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of boot sectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partiton (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
{{Note|Use {{AUR|grub-git}} package for standalone GRUB EFI image as the {{Pkg|grub}} package does not contain various grub-mkstandalone specific fixes (specifically {{ic|${cmdpath} }} support, which is necessary).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
{{Warning|Since package version 1:2.02.beta2-1 (2014-01-10) grub-mkconfig generates ''weird'' configuration files. The generated {{ic|grub.cfg}} contains duplicated boot-entries which are sometimes missing the initramfs, furthermore self-compiled kernels are hidden in a submenu. ({{bug|38455}})}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI systems and only if the Windows bitness matches the grub(2) uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2).}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$uuid}} are obtained with the following two commands. {{ic|$uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|bootmgr}}, not your "real" Windows partition (usually C:). When showing all UUIDs with {{ic|blkid}}, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
{{Note|The example assumes that the ISO is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Redundant menu entries ===<br />
For new installations of GRUB it is possible that multiple redundant menu entries will be generated. This is because both the upstream default {{ic|/etc/grub.d/10_linux}} script and the Arch specific {{ic|/etc/grub.d/10_archlinux}} script are creating menu entries when the grub-mkconfig command is run. To correct this behaviour disable the 10_linux script and then run the grub-mkconfig command again.<br />
# chmod -x /etc/grub.d/10_linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=310354GRUB2014-04-14T00:53:53Z<p>The.ridikulus.rat: /* Windows installed in UEFI-GPT Mode menu entry */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of boot sectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partiton (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
{{Note|Use {{AUR|grub-git}} package for standalone GRUB EFI image as the {{Pkg|grub}} package does not contain various grub-mkstandalone specific fixes (specifically {{ic|${cmdpath} }} support, which is necessary).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
{{Warning|Since package version 1:2.02.beta2-1 (2014-01-10) grub-mkconfig generates ''weird'' configuration files. The generated {{ic|grub.cfg}} contains duplicated boot-entries which are sometimes missing the initramfs, furthermore self-compiled kernels are hidden in a submenu. ({{bug|38455}})}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI systems and only if the Windows bitness matches the grub(2) uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2).}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$uuid}} are obtained with the following two commands. {{ic|$uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|bootmgr}}, not your "real" Windows partition (usually C:). When showing all UUIDs with {{ic|blkid}}, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
For Windows Vista/7/8:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
{{Note|The example assumes that the ISO is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Redundant menu entries ===<br />
For new installations of GRUB it is possible that multiple redundant menu entries will be generated. This is because both the upstream default {{ic|/etc/grub.d/10_linux}} script and the Arch specific {{ic|/etc/grub.d/10_archlinux}} script are creating menu entries when the grub-mkconfig command is run. To correct this behaviour disable the 10_linux script and then run the grub-mkconfig command again.<br />
# chmod -x /etc/grub.d/10_linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=310353GRUB2014-04-14T00:53:13Z<p>The.ridikulus.rat: /* Windows installed in UEFI-GPT Mode menu entry */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of boot sectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partiton (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
{{Note|Use {{AUR|grub-git}} package for standalone GRUB EFI image as the {{Pkg|grub}} package does not contain various grub-mkstandalone specific fixes (specifically {{ic|${cmdpath} }} support, which is necessary).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
{{Warning|Since package version 1:2.02.beta2-1 (2014-01-10) grub-mkconfig generates ''weird'' configuration files. The generated {{ic|grub.cfg}} contains duplicated boot-entries which are sometimes missing the initramfs, furthermore self-compiled kernels are hidden in a submenu. ({{bug|38455}})}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI systems and only if the Windows bitness matches the grub(2) uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2).}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 x86_64 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$uuid}} are obtained with the following two commands. {{ic|$uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|bootmgr}}, not your "real" Windows partition (usually C:). When showing all UUIDs with {{ic|blkid}}, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
For Windows Vista/7/8:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
{{Note|The example assumes that the ISO is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Redundant menu entries ===<br />
For new installations of GRUB it is possible that multiple redundant menu entries will be generated. This is because both the upstream default {{ic|/etc/grub.d/10_linux}} script and the Arch specific {{ic|/etc/grub.d/10_archlinux}} script are creating menu entries when the grub-mkconfig command is run. To correct this behaviour disable the 10_linux script and then run the grub-mkconfig command again.<br />
# chmod -x /etc/grub.d/10_linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=310352GRUB2014-04-14T00:52:23Z<p>The.ridikulus.rat: Added Note on Windows UEFI chainloading not working in bios grub</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of boot sectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partiton (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
{{Note|Use {{AUR|grub-git}} package for standalone GRUB EFI image as the {{Pkg|grub}} package does not contain various grub-mkstandalone specific fixes (specifically {{ic|${cmdpath} }} support, which is necessary).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
{{Warning|Since package version 1:2.02.beta2-1 (2014-01-10) grub-mkconfig generates ''weird'' configuration files. The generated {{ic|grub.cfg}} contains duplicated boot-entries which are sometimes missing the initramfs, furthermore self-compiled kernels are hidden in a submenu. ({{bug|38455}})}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI systems and only if the Windows bitness matches the grub(2) uefi bitness. It WILL NOT WORK in BIOS installed grub(2).}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 x86_64 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$uuid}} are obtained with the following two commands. {{ic|$uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|bootmgr}}, not your "real" Windows partition (usually C:). When showing all UUIDs with {{ic|blkid}}, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
For Windows Vista/7/8:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
{{Note|The example assumes that the ISO is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Redundant menu entries ===<br />
For new installations of GRUB it is possible that multiple redundant menu entries will be generated. This is because both the upstream default {{ic|/etc/grub.d/10_linux}} script and the Arch specific {{ic|/etc/grub.d/10_archlinux}} script are creating menu entries when the grub-mkconfig command is run. To correct this behaviour disable the 10_linux script and then run the grub-mkconfig command again.<br />
# chmod -x /etc/grub.d/10_linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=310351Dual boot with Windows2014-04-14T00:49:58Z<p>The.ridikulus.rat: Added info on lack of mixed BIOS-UEFI chainloading in linux bootloaders</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Getting and installing Arch]]<br />
[[ja:Windows and Arch Dual Boot]]<br />
[[ru:Windows and Arch Dual Boot]]<br />
[[sk:Windows and Arch Dual Boot]]<br />
[[zh-cn:Windows and Arch Dual Boot]]<br />
This is a simple article detailing different methods of Arch/Windows coexistence.<br />
<br />
== Important information ==<br />
<br />
=== Windows UEFI vs BIOS limitations ===<br />
<br />
Microsoft imposes limitations on which firmware boot mode and partitioning style can be supported based on the version of Windows used:<br />
<br />
* '''Windows XP''' both '''32-bit''' and '''x86_64''' (also called x64) versions do not support booting in UEFI mode (IA32 or x86_64) from any disk (MBR or GPT) OR in BIOS mode from GPT disk. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' or '''7''' '''32-bit''' (RTM and all Service Packs) versions support booting in BIOS mode from MBR/msdos disks only, not from GPT disks. They do not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' (SP1 and above, not RTM) and '''Windows 7''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 (x86 32-bit) UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
* '''Windows 8/8.1''' '''32-bit''' in general support only BIOS boot and only from MBR/msdos disk (similar to Windows 7 32-bit), EXCEPT Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) in which it boots ONLY in IA32 UEFI mode and ONLY from GPT disk. '''In all non-Atom SoC systems, Windows 8/8.1 32-bit supports only BIOS boot and only from MBR/msdos disk'''. No x86_64 UEFI boot support.<br />
* '''Windows 8/8.1''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
<br />
In case of pre-installed Systems:<br />
<br />
* All systems pre-installed with Windows XP, Vista or 7 32-bit, irrespective of Service Pack level, bitness, edition (SKU)or presence of UEFI support in firmware, boot in BIOS-MBR mode by default.<br />
* MOST of the systems pre-installed with Windows 7 x86_64, irrespective of Service Pack level, bitness or edition (SKU), boot in BIOS-MBR mode by default. Very few recent systems pre-installed with Windows 7 are known to boot in x86_64 UEFI-GPT mode by default.<br />
* ALL systems pre-installed with Windows 8/8.1 boot in UEFI-GPT mode. The firmware bitness matches the bitness of Windows, ie. x86_64 Windows 8/8.1 boot in x86_64 UEFI mode and 32-bit Windows 8/8.1 boot in IA32 UEFI mode.<br />
<br />
The best way to detect the boot mode of Windows is to do the following:<br />
<br />
* Boot into Windows<br />
* Press Win key and 'R' to start the Run dialog<br />
* In the Run dialog type "msinfo32" and press Enter<br />
* In the '''System Information''' windows, select '''System Summary''' on the left and check the value of '''BIOS mode''' item on the right<br />
* If the value is '''UEFI''', Windows boots in UEFI-GPT mode. If the value is '''Legacy''', Windows boots in BIOS-MBR mode.<br />
<br />
In general, Windows forces type of partitioning depending on the firmware mode used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR (also called '''msdos''' style partitioning) disk. This is a limitation enforced by Windows installer, and as of April 2014 there is no officially (Microsoft) supported way of installing Windows in UEFI-MBR or BIOS-GPT configuration Thus Windows only supports either UEFI-GPT boot or BIOS-MBR configuration.<br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on which bootloader is used and/or how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since installation procedure of bootloader depends on the firmware type and disk partitioning configuration. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, ie. either go for UEFI-GPT boot or BIOS-MBR boot. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Install media limitations ===<br />
<br />
Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) provide only IA32 UEFI firmware WITHOUT Legacy BIOS (CSM) support (unlike most of the x86_64 UEFI systems), due to Microsoft Connected Standby Guidelines for OEMs. Due to lack of Legacy BIOS support in these systems, and the lack of 32-bit UEFI boot in Arch Official Install ISO or the Archboot iso (as of April 2014), these install media cannot boot in Atom SoC tablets pre-installed with Windows 8/8.1 32-bit.<br />
<br />
=== Bootloader UEFI vs BIOS limitations ===<br />
<br />
Most of the linux bootloaders installed for one firmware type cannot launch or chainload bootloaders of other firmware type. That is, if Arch is installed in UEFI-GPT or UEFI-MBR mode in one disk and Windows is installed in BIOS-MBR mode in another disk, the UEFI bootloader used by Arch cannot chainload the BIOS installed Windows in the other disk. Similarly if Arch is installed in BIOS-MBR or BIOS-GPT mode in one disk and Windows is installed in UEFI-GPT in another disk , the BIOS bootloader used by Arch cannot chainload UEFI installed Windows in the other disk. <br />
<br />
The only exceptions to this are grub(2) in Apple Macs in which EFI installed grub(2) can boot BIOS installed OS via '''appleloader''' command (does not work in non-Apple systems), and rEFInd which technically supports booting legacy BIOS OS from UEFI systems, but [http://rodsbooks.com/refind/using.html#legacy does not always work in non-Apple UEFI systems] as per its author Rod Smith. <br />
<br />
However if Arch is installed in BIOS-GPT in one disk and Windows is installed in BIOS-MBR mode in another disk, then the BIOS bootloader used by Arch CAN boot the Windows in the other disk, if the bootloader itself has the ability to chainload from another disk. <br />
<br />
{{Note|If Arch and Windows are dual-booting from same disk, then Arch SHOULD follow the same firmware boot mode and partitioning combination used by the installed Windows in the disk.}}<br />
<br />
=== UEFI Secure Boot ===<br />
<br />
All pre-installed Windows 8/8.1 systems by default boot in UEFI-GPT mode and have UEFI Secure Boot enabled by default (which can be manually disabled by the user) and Legacy BIOS support (CSM) disabled by default (which can be manually enabled by the user, if the firmware supports it) in the firmware. This is mandated by Microsoft for all OEM pre-installed systems.<br />
<br />
Arch Linux install media currently supports Secure Boot but it requires some manual steps by the user to [[UEFI#Secure_Boot|setup the HashTool while booting]]. There it is advisable to disable UEFI Secure Boot in the firmware setup before attempting to boot Arch Linux. Windows 8/8.1 SHOULD continue to boot fine even if Secure boot is disabled. <br />
<br />
The only issue with regards to disabling UEFI Secure Boot support is that it requires physical access to the system to disable secure boot option in the firmware setup, as Microsoft has explicitly forbidden presence of any method to remotely or programmatically (from within OS) disable secure boot in all Windows 8/8.1 pre-installed systems<br />
<br />
=== Fast Start-Up ===<br />
<br />
Fast Start-Up is a feature in Windows 8 that hibernates the computer rather than actually shutting it down to speed up boot times. Your system can lose data if Windows hibernates and you dual boot into another OS and make changes to files. Even if you don't intend to share filesystems, the EFI System Partition is likely to be damaged on an EFI system. Therefore, you should disable Fast Startup, as described [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html here], before you install Linux on any computer that uses Windows 8.<br />
<br />
[http://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/559270a8f67c77a7ce51246c23d2b2837bcff0c9/ NTFS-3G added a safe-guard] to prevent read-write mounting of hibernated disks, but the NTFS driver within the Linux kernel has no such safeguard.<br />
<br />
=== Windows filenames limitations ===<br />
<br />
Windows is limited to filepaths being shorter than [http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx 260 characters].<br />
<br />
Windows also puts [http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conventions certain characters off limits] in filenames for reasons that run all the way back to DOS:<br />
<br />
* < (less than)<br />
* > (greater than)<br />
* : (colon)<br />
* " (double quote)<br />
* / (forward slash)<br />
* \ (backslash)<br />
* | (vertical bar or pipe)<br />
* ? (question mark)<br />
* * (asterisk)<br />
<br />
These are limitations of Windows and not NTFS: any other OS using the NTFS partition will be fine. Windows will fail to detect these files and running {{ic|chkdsk}} will most likely cause them to be deleted. This can lead to potential data-loss.<br />
<br />
== Installation ==<br />
<br />
The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create additional partitions for Linux while leaving the existing Windows partitions untouched.<br />
<br />
=== BIOS systems ===<br />
<br />
==== Using a Linux boot loader ====<br />
<br />
You may use [[GRUB#Dual-booting|GRUB]] or [[Syslinux#Chainloading|Syslinux]].<br />
<br />
==== Using Windows boot loader ====<br />
<br />
With this setup the Windows bootloader loads GRUB which then boots Arch. <br />
<br />
===== Windows Vista/7/8/8.1 boot loader =====<br />
<br />
The following section contains excerpts from http://www.iceflatline.com/2009/09/how-to-dual-boot-windows-7-and-linux-using-bcdedit/.<br />
<br />
The remainder of the setup is similar to a typical installation. Some documents state that the partition being loaded by the Windows boot loader must be a primary partition but I have used this without problem on an extended partition.<br />
<br />
* When installing the GRUB boot loader, install it on your {{ic|/boot}} partition rather than the MBR. {{Note|For instance, my {{ic|/boot}} partition is {{ic|/dev/sda5}}. So I installed GRUB at {{ic|/dev/sda5}} instead of {{ic|/dev/sda}}. For help on doing this, see [[GRUB#Install to partition or partitionless disk]]}}<br />
<br />
* Under Linux make a copy of the boot info by typing the following at the command shell:<br />
<br />
my_windows_part=/dev/sda3<br />
my_boot_part=/dev/sda5<br />
mkdir /media/win<br />
mount $my_windows_part /media/win<br />
dd if=$my_boot_part of=/media/win/linux.bin bs=512 count=1<br />
<br />
* Boot to Windows and open up and you should be able to see the FAT32 partition. Copy the linux.bin file to {{ic|C:\}}. Now run '''cmd''' with administrator privileges (navigate to ''Start > All Programs > Accessories'', right-click on ''Command Prompt'' and select ''Run as administrator''):<br />
<br />
bcdedit /create /d “Linux” /application BOOTSECTOR<br />
<br />
* BCDEdit will return an alphanumeric identifier for this entry that I will refer to as {ID} in the remaining steps. You’ll need to replace {ID} by the actual returned identifier. An example of {ID} is {d7294d4e-9837-11de-99ac-f3f3a79e3e93}. <br />
<br />
bcdedit /set {ID} device partition=c:<br />
bcdedit /set {ID} path \linux.bin<br />
bcdedit /displayorder {ID} /addlast<br />
bcdedit /timeout 30<br />
<br />
Reboot and enjoy. In my case I'm using the Windows boot loader so that I can map my Dell Precision M4500's second power button to boot Linux instead of Windows.<br />
<br />
===== Windows 2000/XP boot loader =====<br />
<br />
For information on this method see http://www.geocities.com/epark/linux/grub-w2k-HOWTO.html. I do not believe there are any distinct advantages of this method over the Linux boot loader; you will still need a {{ic|/boot}} partition, and this one is arguably more difficult to set up.<br />
<br />
=== UEFI systems ===<br />
<br />
Both [[Gummiboot]] and [[rEFInd]] autodetect '''Windows Boot Manager''' {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} and show it in their boot menu, so there is no manual config required.<br />
<br />
For [[GRUB]](2) follow [[GRUB#Windows_Installed_in_UEFI-GPT_Mode_menu_entry]].<br />
<br />
Syslinux (as of version 6.02 and 6.03-pre9) and ELILO do not support chainloading other EFI applications, so they cannot be used to chainload {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} .<br />
<br />
Computers that come with newer versions of Windows often have [[UEFI#Secure_Boot|secure boot]] enabled. You will need to take extra steps to either disable secure boot or to make your installation media compatible with secure boot.<br />
<br />
== Time standard ==<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC, following [[Time#UTC in Windows]]. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to ''localtime''.<br />
<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable any time-related services, like [[Network Time Protocol daemon|NTPd]] . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=140049 Booting Windows from a desktop shortcut]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=310350Dual boot with Windows2014-04-14T00:16:18Z<p>The.ridikulus.rat: Better organize Windows BIOS vs UEFI info</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Getting and installing Arch]]<br />
[[ja:Windows and Arch Dual Boot]]<br />
[[ru:Windows and Arch Dual Boot]]<br />
[[sk:Windows and Arch Dual Boot]]<br />
[[zh-cn:Windows and Arch Dual Boot]]<br />
This is a simple article detailing different methods of Arch/Windows coexistence.<br />
<br />
== Important information ==<br />
<br />
=== Windows UEFI vs BIOS limitations ===<br />
<br />
Microsoft imposes limitations on which firmware boot mode and partitioning style can be supported based on the version of Windows used:<br />
<br />
* '''Windows XP''' both '''32-bit''' and '''x86_64''' (also called x64) versions do not support booting in UEFI mode (IA32 or x86_64) from any disk (MBR or GPT) OR in BIOS mode from GPT disk. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' or '''7''' '''32-bit''' (RTM and all Service Packs) versions support booting in BIOS mode from MBR/msdos disks only, not from GPT disks. They do not support x86_64 UEFI or IA32 (x86 32-bit) UEFI boot. They support only BIOS boot and only from MBR/msdos disk.<br />
* '''Windows Vista''' (SP1 and above, not RTM) and '''Windows 7''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 (x86 32-bit) UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
* '''Windows 8/8.1''' '''32-bit''' in general support only BIOS boot and only from MBR/msdos disk (similar to Windows 7 32-bit), EXCEPT Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) in which it boots ONLY in IA32 UEFI mode and ONLY from GPT disk. '''In all non-Atom SoC systems, Windows 8/8.1 32-bit supports only BIOS boot and only from MBR/msdos disk'''. No x86_64 UEFI boot support.<br />
* '''Windows 8/8.1''' '''x86_64''' versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 UEFI boot, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.<br />
<br />
In case of pre-installed Systems:<br />
<br />
* All systems pre-installed with Windows XP, Vista or 7 32-bit, irrespective of Service Pack level, bitness, edition (SKU)or presence of UEFI support in firmware, boot in BIOS-MBR mode by default.<br />
* MOST of the systems pre-installed with Windows 7 x86_64, irrespective of Service Pack level, bitness or edition (SKU), boot in BIOS-MBR mode by default. Very few recent systems pre-installed with Windows 7 are known to boot in x86_64 UEFI-GPT mode by default.<br />
* ALL systems pre-installed with Windows 8/8.1 boot in UEFI-GPT mode. The firmware bitness matches the bitness of Windows, ie. x86_64 Windows 8/8.1 boot in x86_64 UEFI mode and 32-bit Windows 8/8.1 boot in IA32 UEFI mode.<br />
<br />
The best way to detect the boot mode of Windows is to do the following:<br />
<br />
* Boot into Windows<br />
* Press Win key and 'R' to start the Run dialog<br />
* In the Run dialog type "msinfo32" and press Enter<br />
* In the '''System Information''' windows, select '''System Summary''' on the left and check the value of '''BIOS mode''' item on the right<br />
* If the value is '''UEFI''', Windows boots in UEFI-GPT mode. If the value is '''Legacy''', Windows boots in BIOS-MBR mode.<br />
<br />
In general, Windows forces type of partitioning depending on the firmware mode used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR (also called '''msdos''' style partitioning) disk. This is a limitation enforced by Windows installer, and as of April 2014 there is no officially (Microsoft) supported way of installing Windows in UEFI-MBR or BIOS-GPT configuration Thus Windows only supports either UEFI-GPT boot or BIOS-MBR configuration.<br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on which bootloader is used and/or how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since installation procedure of bootloader depends on the firmware type and disk partitioning configuration. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, ie. either go for UEFI-GPT boot or BIOS-MBR boot. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) provide only IA32 UEFI firmware WITHOUT Legacy BIOS (CSM) support (unlike most of the x86_64 UEFI systems), due to Microsoft Connected Standby Guidelines for OEMs. Due to lack of Legacy BIOS support in these systems, and the lack of 32-bit UEFI boot in Arch Official Install ISO or the Archboot iso (as of April 2014), these install media cannot boot in Atom SoC tablets pre-installed with Windows 8/8.1 32-bit.<br />
<br />
=== UEFI Secure Boot ===<br />
<br />
All pre-installed Windows 8/8.1 systems by default boot in UEFI-GPT mode and have UEFI Secure Boot enabled by default and Legacy BIOS support (CSM) disabled (which can be enabled by the user, if the feature exists) by default in the firmware . This is mandated by Microsoft for all OEM pre-installed systems. <br />
<br />
Arch Linux install media currently supports Secure Boot but it requires some manual steps by the user to [[UEFI#Secure_Boot|setup the HashTool while booting]]. There it is advisable to disable UEFI Secure Boot in the firmware setup before attempting to boot Arch Linux. Windows 8/8.1 SHOULD continue to boot fine even if Secure boot is disabled.<br />
<br />
=== Fast Start-Up ===<br />
<br />
Fast Start-Up is a feature in Windows 8 that hibernates the computer rather than actually shutting it down to speed up boot times. Your system can lose data if Windows hibernates and you dual boot into another OS and make changes to files. Even if you don't intend to share filesystems, the EFI System Partition is likely to be damaged on an EFI system. Therefore, you should disable Fast Startup, as described [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html here], before you install Linux on any computer that uses Windows 8.<br />
<br />
[http://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/559270a8f67c77a7ce51246c23d2b2837bcff0c9/ NTFS-3G added a safe-guard] to prevent read-write mounting of hibernated disks, but the NTFS driver within the Linux kernel has no such safeguard.<br />
<br />
=== Windows filenames limitations ===<br />
<br />
Windows is limited to filepaths being shorter than [http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx 260 characters].<br />
<br />
Windows also puts [http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conventions certain characters off limits] in filenames for reasons that run all the way back to DOS:<br />
<br />
* < (less than)<br />
* > (greater than)<br />
* : (colon)<br />
* " (double quote)<br />
* / (forward slash)<br />
* \ (backslash)<br />
* | (vertical bar or pipe)<br />
* ? (question mark)<br />
* * (asterisk)<br />
<br />
These are limitations of Windows and not NTFS: any other OS using the NTFS partition will be fine. Windows will fail to detect these files and running {{ic|chkdsk}} will most likely cause them to be deleted. This can lead to potential data-loss.<br />
<br />
== Installation ==<br />
<br />
The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create additional partitions for Linux while leaving the existing Windows partitions untouched.<br />
<br />
=== BIOS systems ===<br />
<br />
==== Using a Linux boot loader ====<br />
<br />
You may use [[GRUB#Dual-booting|GRUB]] or [[Syslinux#Chainloading|Syslinux]].<br />
<br />
==== Using Windows boot loader ====<br />
<br />
With this setup the Windows bootloader loads GRUB which then boots Arch. <br />
<br />
===== Windows Vista/7/8/8.1 boot loader =====<br />
<br />
The following section contains excerpts from http://www.iceflatline.com/2009/09/how-to-dual-boot-windows-7-and-linux-using-bcdedit/.<br />
<br />
The remainder of the setup is similar to a typical installation. Some documents state that the partition being loaded by the Windows boot loader must be a primary partition but I have used this without problem on an extended partition.<br />
<br />
* When installing the GRUB boot loader, install it on your {{ic|/boot}} partition rather than the MBR. {{Note|For instance, my {{ic|/boot}} partition is {{ic|/dev/sda5}}. So I installed GRUB at {{ic|/dev/sda5}} instead of {{ic|/dev/sda}}. For help on doing this, see [[GRUB#Install to partition or partitionless disk]]}}<br />
<br />
* Under Linux make a copy of the boot info by typing the following at the command shell:<br />
<br />
my_windows_part=/dev/sda3<br />
my_boot_part=/dev/sda5<br />
mkdir /media/win<br />
mount $my_windows_part /media/win<br />
dd if=$my_boot_part of=/media/win/linux.bin bs=512 count=1<br />
<br />
* Boot to Windows and open up and you should be able to see the FAT32 partition. Copy the linux.bin file to {{ic|C:\}}. Now run '''cmd''' with administrator privileges (navigate to ''Start > All Programs > Accessories'', right-click on ''Command Prompt'' and select ''Run as administrator''):<br />
<br />
bcdedit /create /d “Linux” /application BOOTSECTOR<br />
<br />
* BCDEdit will return an alphanumeric identifier for this entry that I will refer to as {ID} in the remaining steps. You’ll need to replace {ID} by the actual returned identifier. An example of {ID} is {d7294d4e-9837-11de-99ac-f3f3a79e3e93}. <br />
<br />
bcdedit /set {ID} device partition=c:<br />
bcdedit /set {ID} path \linux.bin<br />
bcdedit /displayorder {ID} /addlast<br />
bcdedit /timeout 30<br />
<br />
Reboot and enjoy. In my case I'm using the Windows boot loader so that I can map my Dell Precision M4500's second power button to boot Linux instead of Windows.<br />
<br />
===== Windows 2000/XP boot loader =====<br />
<br />
For information on this method see http://www.geocities.com/epark/linux/grub-w2k-HOWTO.html. I do not believe there are any distinct advantages of this method over the Linux boot loader; you will still need a {{ic|/boot}} partition, and this one is arguably more difficult to set up.<br />
<br />
=== UEFI systems ===<br />
<br />
Both [[Gummiboot]] and [[rEFInd]] autodetect '''Windows Boot Manager''' {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} and show it in their boot menu, so there is no manual config required.<br />
<br />
For [[GRUB]](2) follow [[GRUB#Windows_Installed_in_UEFI-GPT_Mode_menu_entry]].<br />
<br />
Syslinux (as of version 6.02 and 6.03-pre9) and ELILO do not support chainloading other EFI applications, so they cannot be used to chainload {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} .<br />
<br />
Computers that come with newer versions of Windows often have [[UEFI#Secure_Boot|secure boot]] enabled. You will need to take extra steps to either disable secure boot or to make your installation media compatible with secure boot.<br />
<br />
== Time standard ==<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC, following [[Time#UTC in Windows]]. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to ''localtime''.<br />
<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable any time-related services, like [[Network Time Protocol daemon|NTPd]] . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=140049 Booting Windows from a desktop shortcut]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Dual_boot_with_Windows&diff=310230Dual boot with Windows2014-04-12T21:22:21Z<p>The.ridikulus.rat: Move UEFI vs BIOS dual-boot info from UEFI article</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Getting and installing Arch]]<br />
[[ja:Windows and Arch Dual Boot]]<br />
[[ru:Windows and Arch Dual Boot]]<br />
[[sk:Windows and Arch Dual Boot]]<br />
[[zh-cn:Windows and Arch Dual Boot]]<br />
This is a simple article detailing different methods of Arch/Windows coexistence.<br />
<br />
== Important Info ==<br />
<br />
=== UEFI vs BIOS ===<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. 32-bit Windows 8 supports booting using IA32 UEFI firmware only in Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail). User installed 32-bit Windows 8/8.1 supports only BIOS-MBR config.<br />
<br />
Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR (also called '''msdos''' style partitioning) disk. This is a limitation enforced by Windows installer, and as of April 2014 there is no officially (Microsoft) supported way of installing Windows in UEFI-MBR or BIOS-GPT configuration Thus Windows only supports either UEFI-GPT boot or BIOS-MBR configuration. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on which bootloader is used and/or how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since installation procedure of bootloader depends on the firmware type and disk partitioning configuration. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, ie. either go for UEFI-GPT boot or BIOS-MBR boot. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
OEM pre-installed 64-bit Windows 8/8.1 systems (factory installed config) always boot in UEFI-GPT config with UEFI Secure Boot enabled (which can be disabled manually by the user) and Legacy BIOS support (CSM) disabled (which can be enabled by the user, if the feature exists) by default in firmware . This is mandated by Microsoft for all OEM pre-installed systems. <br />
<br />
As of April 2014 32-bit OEM preinstalled Windows 8/8.1 are allowed by Microsoft only in Intel Atom System-on-Chip Tablets (Clover trail and Bay Trail) tablets and these system do not include Legacy BIOS support (CSM) in the firmware (due to Microsoft COnnected Standby Guidelines for OEMs) with UEFI Secure Boot enabled by default (but can be manually disabled by user). Due to lack of Legacy BIOS support in these systems, and the lack of 32-bit UEFI boot in Arch Official Install ISO or the Archboot iso (as of April 2014), these install media cannot boot in Atom SoC tablets pre-installed with Windows 8/8.1 32-bit.<br />
<br />
All OEM pre-installed 32-bit Windows Vista/7 systems boot in BIOS-MBR config by default. All OEM pre-install 64-bit Windows Vista and most (but not all) OEM pre-installed 64-bit Windows 7 systems boot in BIOS-MBR config by default.<br />
<br />
=== UEFI Secure Boot ===<br />
<br />
As mentioned in [[#UEFI vs BIOS]] section, OEM pre-installed Windows 8/8.1 have UEFI Secure Boot enabled by default. Arch Linux install media currently supports Secure Boot but it requires some manual steps by the user to [[UEFI#Secure_Boot|setup the HashTool while booting]]. There it is advisable to disable UEFI Secure Boot in the firmware setup before attempting to boot Arch Linux. Windows 8/8.1 SHOULD continue to boot fine even if Secure boot is disabled.<br />
<br />
=== Fast Start-Up ===<br />
<br />
Fast Start-Up is a feature in Windows 8 that hibernates the computer rather than actually shutting it down to speed up boot times. Your system can lose data if Windows hibernates and you dual boot into another OS and make changes to files. Even if you don't intend to share filesystems, the EFI System Partition is likely to be damaged on an EFI system. Therefore, you should disable Fast Startup, as described [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html here], before you install Linux on any computer that uses Windows 8.<br />
<br />
[http://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/559270a8f67c77a7ce51246c23d2b2837bcff0c9/ NTFS-3G added a safe-guard] to prevent read-write mounting of hibernated disks, but the NTFS driver within the Linux kernel has no such safeguard.<br />
<br />
=== Windows Filenames Limitations ===<br />
<br />
Windows is limited to filepaths being shorter than [http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx 260 characters].<br />
<br />
Windows also puts [http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#naming_conventions certain characters off limits] in filenames for reasons that run all the way back to DOS:<br />
<br />
* < (less than)<br />
* > (greater than)<br />
* : (colon)<br />
* " (double quote)<br />
* / (forward slash)<br />
* \ (backslash)<br />
* | (vertical bar or pipe)<br />
* ? (question mark)<br />
* * (asterisk)<br />
<br />
These are limitations of Windows and not NTFS: any other OS using the NTFS partition will be fine. Windows will fail to detect these files and running {{ic|chkdsk}} will most likely cause them to be deleted. This can lead to potential data-loss.<br />
<br />
== Installation ==<br />
<br />
The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create additional partitions for Linux while leaving the existing Windows partitions untouched.<br />
<br />
=== BIOS Systems ===<br />
<br />
==== Using a Linux boot loader ====<br />
<br />
You may use [[GRUB#Dual-booting|GRUB]] or [[Syslinux#Chainloading|Syslinux]].<br />
<br />
==== Using Windows boot loader ====<br />
<br />
With this setup the Windows bootloader loads GRUB which then boots Arch. <br />
<br />
===== Windows Vista/7/8/8.1 boot loader =====<br />
<br />
The following section contains excerpts from http://www.iceflatline.com/2009/09/how-to-dual-boot-windows-7-and-linux-using-bcdedit/.<br />
<br />
The remainder of the setup is similar to a typical installation. Some documents state that the partition being loaded by the Windows boot loader must be a primary partition but I have used this without problem on an extended partition.<br />
<br />
* When installing the GRUB boot loader, install it on your {{ic|/boot}} partition rather than the MBR. {{Note|For instance, my {{ic|/boot}} partition is {{ic|/dev/sda5}}. So I installed GRUB at {{ic|/dev/sda5}} instead of {{ic|/dev/sda}}. For help on doing this, see [[GRUB#Install to partition or partitionless disk]]}}<br />
<br />
* Under Linux make a copy of the boot info by typing the following at the command shell:<br />
<br />
my_windows_part=/dev/sda3<br />
my_boot_part=/dev/sda5<br />
mkdir /media/win<br />
mount $my_windows_part /media/win<br />
dd if=$my_boot_part of=/media/win/linux.bin bs=512 count=1<br />
<br />
* Boot to Windows and open up and you should be able to see the FAT32 partition. Copy the linux.bin file to {{ic|C:\}}. Now run '''cmd''' with administrator privileges (navigate to ''Start > All Programs > Accessories'', right-click on ''Command Prompt'' and select ''Run as administrator''):<br />
<br />
bcdedit /create /d “Linux” /application BOOTSECTOR<br />
<br />
* BCDEdit will return an alphanumeric identifier for this entry that I will refer to as {ID} in the remaining steps. You’ll need to replace {ID} by the actual returned identifier. An example of {ID} is {d7294d4e-9837-11de-99ac-f3f3a79e3e93}. <br />
<br />
bcdedit /set {ID} device partition=c:<br />
bcdedit /set {ID} path \linux.bin<br />
bcdedit /displayorder {ID} /addlast<br />
bcdedit /timeout 30<br />
<br />
Reboot and enjoy. In my case I'm using the Windows boot loader so that I can map my Dell Precision M4500's second power button to boot Linux instead of Windows.<br />
<br />
===== Windows 2000/XP boot loader =====<br />
<br />
For information on this method see http://www.geocities.com/epark/linux/grub-w2k-HOWTO.html. I do not believe there are any distinct advantages of this method over the Linux boot loader; you will still need a {{ic|/boot}} partition, and this one is arguably more difficult to set up.<br />
<br />
=== UEFI Systems ===<br />
<br />
Both [[Gummiboot]] and [[rEFInd]] autodetect '''Windows Boot Manager''' {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} and show it in their boot menu, so there is no manual config required.<br />
<br />
For [[GRUB]](2) follow [[GRUB#Windows_Installed_in_UEFI-GPT_Mode_menu_entry]].<br />
<br />
Syslinux (as of version 6.02 and 6.03-pre9) and ELILO do not support chainloading other EFI applications, so they cannot be used to chainload {{ic|\EFI\Microsoft\Boot\bootmgfw.efi}} .<br />
<br />
Computers that come with newer versions of Windows often have [[UEFI#Secure_Boot|secure boot]] enabled. You will need to take extra steps to either disable secure boot or to make your installation media compatible with secure boot.<br />
<br />
== Time standard ==<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC, following [[Time#UTC in Windows]]. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to ''localtime''.<br />
<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable any time-related services, like [[Network Time Protocol daemon|NTPd]] . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please do not ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=140049 Booting Windows from a desktop shortcut]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=310229Unified Extensible Firmware Interface2014-04-12T21:17:49Z<p>The.ridikulus.rat: Move Booting Windows info to WIndows and Arch dual-boot article</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== Differences between BIOS and UEFI ==<br />
<br />
See [[Arch boot process#Firmware_types]] for more details.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/BOOT/BOOTX64.EFI}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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 />
=== Secure Boot ===<br />
For an overview about Secure Boot in Linux see http://www.rodsbooks.com/efi-bootloaders/secureboot.html. This section focuses on how to set up Secure Boot in Arch Linux. For the time being, this section is limited to explain the procedure of booting the archiso with Secure Boot enabled.<br />
Booting the archiso with Secure Boot enabled is possible since the efi applications ''PreLoader.efi'' and ''HashTool.efi'' have been added to it. A message will show up that says ''Failed to Start loader... I will now execute HashTool.'' To use HashTool for enrolling the hash of ''loader.efi'' and ''vmlinuz.efi'', follow these steps.<br />
* Select {{ic|OK}}<br />
* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}<br />
The archiso boots, and you are presented with a shell prompt, automatically logged in as root. To check if the archiso was booted with SecureBoot, use this command:<br />
<br />
$ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data<br />
<br />
If yes, this command returns 1. The characters denoted by 1234 differ from machine to machine. To help with this, you can use tab completion or list the efi variables.<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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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}}<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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=310228Unified Extensible Firmware Interface2014-04-12T20:44:11Z<p>The.ridikulus.rat: new 'upstream' efibootmgr supports efivarfs</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== Differences between BIOS and UEFI ==<br />
See [[Arch boot process#Firmware_types]] for more details.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases.<br />
<br />
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk has to use MBR. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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 />
=== Secure Boot ===<br />
For an overview about Secure Boot in Linux see http://www.rodsbooks.com/efi-bootloaders/secureboot.html. This section focuses on how to set up Secure Boot in Arch Linux. For the time being, this section is limited to explain the procedure of booting the archiso with Secure Boot enabled.<br />
Booting the archiso with Secure Boot enabled is possible since the efi applications ''PreLoader.efi'' and ''HashTool.efi'' have been added to it. A message will show up that says ''Failed to Start loader... I will now execute HashTool.'' To use HashTool for enrolling the hash of ''loader.efi'' and ''vmlinuz.efi'', follow these steps.<br />
* Select {{ic|OK}}<br />
* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}<br />
The archiso boots, and you are presented with a shell prompt, automatically logged in as root. To check if the archiso was booted with SecureBoot, use this command:<br />
<br />
$ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data<br />
<br />
If yes, this command returns 1. The characters denoted by 1234 differ from machine to machine. To help with this, you can use tab completion or list the efi variables.<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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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}}<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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=295098Unified Extensible Firmware Interface2014-01-30T22:43:01Z<p>The.ridikulus.rat: Add link to AdamW's blog post on how uefi boot works</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== Differences between BIOS and UEFI ==<br />
See [[Arch_Boot_Process#Firmware_types]] for more details.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases.<br />
<br />
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk has to use MBR. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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 />
=== Secure Boot ===<br />
For an overview about Secure Boot in Linux see http://www.rodsbooks.com/efi-bootloaders/secureboot.html. This section focuses on how to set up Secure Boot in Arch Linux. For the time being, this section is limited to explain the procedure of booting the archiso with Secure Boot enabled.<br />
Booting the archiso with Secure Boot enabled is possible since the efi applications ''PreLoader.efi'' and ''HashTool.efi'' have been added to it. A message will show up that says ''Failed to Start loader... I will now execute HashTool.'' To use HashTool for enrolling the hash of ''loader.efi'' and ''vmlinuz.efi'', follow these steps.<br />
* Select {{ic|OK}}<br />
* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}<br />
The archiso boots, and you are presented with a shell prompt, automatically logged in as root. To check if the archiso was booted with SecureBoot, use this command:<br />
<br />
$ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data<br />
<br />
If yes, this command returns 1. The characters denoted by 1234 differ from machine to machine. To help with this, you can use tab completion or list the efi variables.<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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 vathpela's efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings. Upstream (http://linux.dell.com/git/efibootmgr.git) efibootmgr code does not support efivarfs. A fork of efibootmgr by Fedora's Peter Jones (vathpela) supports both efivarfs and sysfs-efivars. It is currently used in official core/{{Pkg|efibootmgr}} pkg and AUR pkg {{AUR|efibootmgr-pjones-git}} - https://github.com/vathpela/efibootmgr/tree/libefivars<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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), modifyiang 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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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}}<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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=293885User:The.ridikulus.rat2014-01-22T06:31:49Z<p>The.ridikulus.rat: </p>
<hr />
<div>Hi, This is Keshav Amburay. In some places my name will be listed as "Keshav Padram Amburay", where "Padram" is my unofficial middle-name. <br />
<br />
I am native of Chennai, Tamil Nadu, India but I currently reside in Indiana, USA. My native language is Tamil but I am proficient in English.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulus_rat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/The.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/the-ridikulus-rat GitHub], [https://bitbucket.org/the_ridikulus_rat Bitbucket] and [https://gitorious.org/~the-ridikulus-rat Gitorious]. I also co-maintain [[Archboot]] installer code.<br />
<br />
For my system info please refer to [[HCL/Firmwares/UEFI#Lenovo_Thinkpad_Edge_E430_3254-DAQ]].<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=293655User:The.ridikulus.rat2014-01-20T03:35:22Z<p>The.ridikulus.rat: </p>
<hr />
<div>Hi, This is Keshav Amburay. In some places my name will be listed as "Keshav Padram Amburay", where "Padram" is my unofficial middle-name. I am native of Chennai, Tamil Nadu, India but I currently reside in Indiana, USA. My native language is Tamil but I am proficient in English.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulus_rat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/The.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/the-ridikulus-rat GitHub], [https://bitbucket.org/the_ridikulus_rat Bitbucket] and [https://gitorious.org/~the-ridikulus-rat Gitorious]. I also co-maintain [[Archboot]] installer code.<br />
<br />
For my system info please refer to [[HCL/Firmwares/UEFI#Lenovo_Thinkpad_Edge_E430_3254-DAQ]].<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=293654User:The.ridikulus.rat2014-01-20T03:35:13Z<p>The.ridikulus.rat: </p>
<hr />
<div>Hi, This is Keshav Amburay. In some places my name will be listed as "Keshav Padram Amburay", where "Padram" is my unofficial middle-name. I am native of Chennai, Tamil Nadu, India but I currently reside in Indiana, USA. My native language is Tamil but I am proficient in English.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulus_rat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/The.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/the-ridikulus-rat GitHub], [https://bitbucket.org/the_ridikulus_rat Bitbucket] and [https://gitorious.org/~the-ridikulus-rat Gitorious]. I also co-maintain [[Archboot]] installer code.<br />
<br />
For my system info please refer to [[HCL/Firmwares/UEFI#Lenovo_Thinkpad_Edge_E430_3254-DAQ]].<br />
<br />
[https://bbs.archlinux.org/profile.php?id=52902 Arch Linux Forum]]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User:The.ridikulus.rat&diff=293652User:The.ridikulus.rat2014-01-20T03:29:15Z<p>The.ridikulus.rat: Some info about me.</p>
<hr />
<div>= Keshav Amburay =<br />
<br />
Hi, This is Keshav Amburay. I am native of Chennai, Tamil Nadu, India but I currently reside in Indiana, USA. My native language is Tamil but I am proficient in English.<br />
<br />
I am generally interested in Boot Loaders. I maintain various boot loaders in [https://aur.archlinux.org/packages/?SeB=m&K=ridikulus_rat AUR] and have contributed and edited various wiki pages, notably those related to [[UEFI] and [[GPT]]. For my wiki contributions please refer [[Special:Contributions/The.ridikulus.rat]].<br />
<br />
I also maintain few git repos at [https://github.com/the-ridikulus-rat GitHub], [https://bitbucket.org/the_ridikulus_rat Bitbucket] and [https://gitorious.org/~the-ridikulus-rat Gitorious]. I also co-maintain [[Archboot]] installer code.<br />
<br />
For my system info please refer to [[HCL/Firmwares/UEFI#Lenovo_Thinkpad_Edge_E430_3254-DAQ]].</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=293643Unified Extensible Firmware Interface2014-01-20T01:46:52Z<p>The.ridikulus.rat: efibootmgr upstream is now pjones aka vathpela's repo</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== Differences between BIOS and UEFI ==<br />
See [[Arch_Boot_Process#Firmware_types]] for more details.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases.<br />
<br />
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk has to use MBR. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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 />
=== Secure Boot ===<br />
For an overview about Secure Boot in Linux see http://www.rodsbooks.com/efi-bootloaders/secureboot.html. This section focuses on how to set up Secure Boot in Arch Linux. For the time being, this section is limited to explain the procedure of booting the archiso with Secure Boot enabled.<br />
Booting the archiso with Secure Boot enabled is possible since the efi applications ''PreLoader.efi'' and ''HashTool.efi'' have been added to it. A message will show up that says ''Failed to Start loader... I will now execute HashTool.'' To use HashTool for enrolling the hash of ''loader.efi'' and ''vmlinuz.efi'', follow these steps.<br />
* Select {{ic|OK}}<br />
* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}<br />
The archiso boots, and you are presented with a shell prompt, automatically logged in as root. To check if the archiso was booted with SecureBoot, use this command:<br />
<br />
$ od -An -t u1 /sys/firmware/efi/vars/SecureBoot-1234abcde-5678-/data<br />
<br />
If yes, this command returns 1. The characters denoted by 1234 differ from machine to machine. To help with this, you can use tab completion or list the efi variables.<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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 vathpela's efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings. Upstream (http://linux.dell.com/git/efibootmgr.git) efibootmgr code does not support efivarfs. A fork of efibootmgr by Fedora's Peter Jones (vathpela) supports both efivarfs and sysfs-efivars. It is currently used in official core/{{Pkg|efibootmgr}} pkg and AUR pkg {{AUR|efibootmgr-pjones-git}} - https://github.com/vathpela/efibootmgr/tree/libefivars<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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), modifyiang 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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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}}<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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=288973GRUB2013-12-17T06:38:52Z<p>The.ridikulus.rat: /* Out of memory/Syntax error running grub-mkconfig */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|Arch Boot Process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
<br />
[https://www.gnu.org/software/grub/ GRUB] - not to be confused with [[GRUB Legacy]] - is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} filesystem) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported filesystem.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
<br />
==== BIOS systems ====<br />
<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of bootsectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no filesystem. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
<br />
An EFI System Partition (ESP) is needed on every disc you wan to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Archlinux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it /dev/sda.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat filesystem and the 'boot' flag enabled. On it, there should be a folder called "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
<br />
{{Note|If you are performing an [[Installation Guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
Before installing, make sure the correct UUIDs of your disks are inserted into {{ic| grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
==== Install boot files ====<br />
<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To setup {{ic|grub}} in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that {{ic|grub}} relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix dir {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the filesystem in the partition is being altered (files copied, deleted etc.). For more info see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using chattr command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if {{ic|grub}} is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
===== Generate core.img alone =====<br />
<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any {{ic|grub}} bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
<br />
===== Recommended method =====<br />
<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[Beginners' Guide#GRUB]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
<br />
{{Note|Use {{Aur|grub-git}} pkg for standalone GRUB EFI image as the {{Pkg|grub}} pkg does not contain various grub-mkstandalone specific fixes (specifically {{ic|${cmdpath} }} support, which is necessary).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows"<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside grub env it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same dir as the EFI file (inside grub env it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any dir inside the EFI System Partition (as long as they are in the same dir), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path for BIOS systems is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* For EFI systems, if GRUB was installed with the {{ic|1=--boot-directory=$esp/EFI}} option set, the {{ic|grub.cfg}} file must be placed in the same directory as {{ic|grubx64.efi}}. Otherwise, the {{ic|grub.cfg}} file goes in {{ic|/boot/grub/}}, just like in BIOS systems.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for eg: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
<br />
==== Disable framebuffer ====<br />
<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via filesystem UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant filesystem is resized or recreated. Remember this when modifying partitions & filesystems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} folder.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
'''/etc/grub.d/40_custom''':<br />
<br />
{{bc|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|<nowiki>drivemap -s hd0 hd2</nowiki>}}<br />
<br />
===== Windows Installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 x86_64 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$uuid}} are obtained with the following two commands. {{ic|$uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|bootmgr}}, not your "real" Windows partition (usually C:). When showing all UUIDs with blkid, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS filesystem of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
For Windows Vista/7/8:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
<br />
{{Note|The example assumes that the iso is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
<br />
It is possible to use labels, human-readable strings attached to filesystems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
<br />
grub> <br />
<br />
The GRUB's command shell environemnt can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Normal loading ====<br />
<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|kcm-grub2|This Kcm module manages the most common settings of GRUB|http://kde-apps.org/content/show.php?content&#61;137886|{{AUR|kcm-grub2}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod (hdX,Y)/boot/grub/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}} and {{ic|insmod (hdX,Y)/grub/linux.mod}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Intel BIOS not booting GPT ===<br />
<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
=== Enable debug messages ===<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Out of memory/Syntax error running grub-mkconfig ===<br />
<br />
Add {{ic|1=GRUB_DISABLE_SUBMENU=y}} in {{ic|/etc/default/grub}} and regenerate {{ic|grub.cfg}}.<br />
<br />
== See also ==<br />
<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=285179USB flash installation medium2013-11-29T08:35:29Z<p>The.ridikulus.rat: Use /arch/boot/syslinux as used by Archiso</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:USB Installation Media]]<br />
[[bg:USB Installation Media]]<br />
[[de:Installation von einem USB-Stick]]<br />
[[es:USB Installation Media]]<br />
[[it:USB Installation Media]]<br />
[[ja:USB Installation Media]]<br />
[[ro:Instalare prin USB]]<br />
[[ru:USB Installation Media]]<br />
[[tr:USB_ile_kurulum]]<br />
[[zh-CN:USB Installation Media]]<br />
[[zh-TW:USB Installation Media]]<br />
{{Article summary start}}<br />
{{Article summary text|Mutiplatform instructions on creating a bootable USB stick which can be used for installing Arch Linux, system maintenance or for recovery purposes.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|CD Burning}}<br />
{{Article summary end}}<br />
This page discusses various methods on how to create a Arch Linux Installer USB drive (also referred to as ''"flash drive", "USB stick", "USB key"'', etc) for booting in BIOS and UEFI systems. The result will be a LiveUSB (LiveCD-like) system that, because of the nature of [[Wikipedia:SquashFS|SquashFS]], will discard all changes once the computer shuts down.<br />
<br />
If you would like to run a full install of Arch Linux from a USB drive (i.e. with persistent settings), see [[Installing Arch Linux on a USB key]]. If you would like to use your bootable Arch Linux USB stick as a rescue USB, see [[Change Root]].<br />
<br />
== BIOS and UEFI Bootable USB ==<br />
<br />
=== Recommended Method ===<br />
<br />
==== In GNU/Linux ====<br />
<br />
This method is slightly more complicated than writing the image directly with {{ic|dd}}, but it does keep the drive usable for data storage. Before you begin, make sure that your USB device is formatted as either FAT32. Also, make sure that you have the latest ''syslinux'' package (version 6.02 or newer) installed<br />
<br />
* [[Beginners_Guide#Prepare_the_storage_drive|First create a MBR (msdos) partition table with at least one partition, in the USB]] (it is fine to use an already partitioned USB).<br />
<br />
* Mount the ISO image:<br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2013.10.01-dual.iso /mnt/iso<br />
<br />
* Then create a FAT32 filesystem in the partition on the USB (unmount before, if necessary).<br />
<br />
* Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
# mount /dev/sd'''X'''1 /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}<br />
<br />
* Adjust the configuration files (necessary only for [[Archiso]], not needed for [[Archboot]] iso):<br />
<br />
{{Warning|Failure to label the drive "{{ic|ARCH_2013XX}}" (with the appropriate release month) or to use an [[UUID]] (to re-label it to whatever you like) '''will''' get you the infamous "30 seconds" error.}}<br />
<br />
Here is how you can replace the {{ic|1=archisolabel=ARCH_2013XX}} part with your equivalent of {{ic|1=archiso'''device'''=/dev/disk/by-uuid/47FA-4071}} for both config files at the same time, using a single command:<br />
<br />
{{Note|Adjust {{ic|/dev/sd'''X'''1}} before running it, else it will become blank (since drive {{ic|sd'''X'''}} does not exist).}}<br />
<br />
$ sed -i "s|label=ARCH_.*|device=/dev/disk/by-uuid/$(blkid -o value -s UUID /dev/sd'''X'''1)|" archiso_sys{32,64}.cfg<br />
<br />
* Install Syslinux to the USB by following [[Syslinux#Manual_install]]. Overwrite the existing syslinux modules ({{ic|*.c32}} files) present in the USB (from the ISO) with the ones from the Syslinux pkg to avoid version mismatch related boot failure.<br />
<br />
* Mark the USB partition as active by following [[Syslinux#MBR_partition_table]]<br />
<br />
==== In Windows ====<br />
<br />
{{Note|<br />
* Do not use any '''Bootable USB Creator utility''' for creating the UEFI bootable USB. Do not use ''dd for Windows'' to dd the ISO to the USB drive.<br />
<br />
* In the below commands '''X:''' is assumed to be the USB flash drive in Windows.<br />
<br />
* Windows used backward slash {{ic|\}} as path-separator, so the same is used in the below commands.<br />
<br />
* All commands should be run in Windows command prompt '''as administrator'''.<br />
<br />
* {{ic|>}} denotes the Windows command prompt.<br />
}}<br />
<br />
* Partition and format the USB drive using [http://rufus.akeo.ie/ Rufus USB partitioner]. Select partition scheme option as '''MBR for BIOS and UEFI''' and File system as '''FAT32'''. Uncheck "Create a bootable disk using ISO image" and "Create extended label and icon files" options. Use <br />
<br />
* Change the '''Volume Label''' of the USB flash drive {{ic|X:}} to match the LABEL mentioned in {{ic|1=archisolabel=}} part in {{ic|<ISO>\loader\entries\archiso-x86_64.conf}}. This step is required for Official ISO ([[Archiso]]) but not required for [[Archboot]].<br />
<br />
* Extract the ISO (similar to extracting ZIP archive) to the USB flash drive (using [http://7-zip.org/ 7-Zip]. <br />
<br />
* Download latest official syslinux 6.xx binaries (zip file) from https://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract it.<br />
<br />
* Run the following command (in Windows cmd prompt, as admin):<br />
<br />
{{Note|Use {{ic|X:\boot\syslinux\}} for Archboot iso.}}<br />
<br />
> cd bios\<br />
> for /r %Y in (*.c32) do copy "%Y" "X:\arch\boot\syslinux\" /y<br />
> copy mbr\*.bin X:\arch\boot\syslinux\ /y<br />
<br />
* Install Syslinux to the USB by running (use {{ic|win64\syslinux64.exe}} for x64 Windows):<br />
<br />
{{Note|Use {{ic|/arch/boot/syslinux}} for Archboot iso.}}<br />
<br />
> cd bios\<br />
> win32\syslinux.exe -d /arch/boot/syslinux -i -a -m X:<br />
<br />
{{Note|<br />
* The above step install Syslinux {{ic|ldlinux.sys}} to the USB partition VBR, sets the partition as active/boot in the MBR partition table and write the MBR boot code to the 1st 400-byte boot code region of the USB.<br />
<br />
* The {{ic|-d}} switch expects path with forward slash path-separator like in *unix systems.<br />
}}<br />
<br />
=== Using dd ===<br />
<br />
{{Warning|This will irrevocably destroy all data on {{ic|/dev/sd'''x'''}}.}}<br />
<br />
==== In GNU/Linux ====<br />
<br />
{{Tip|Check that the USB flash installation media is '''not''' mounted with {{ic|lsblk}}.}}<br />
<br />
{{Note|Use {{ic|/dev/sd'''x'''}} instead of {{ic|/dev/sd'''x1'''}}.}}<br />
<br />
# dd bs=4M if=/path/to/archlinux.iso of=/dev/sd'''x''' && sync<br />
<br />
==== In Windows ====<br />
<br />
===== Using Cygwin =====<br />
<br />
Make sure your [http://www.cygwin.com/ Cygwin] installation contains the {{ic|dd}} package.<br />
<br />
{{Tip|If you do not want to install Cygwin, you can download {{ic|dd}} for Windows from [http://www.chrysocome.net/dd here]. See the next section for more information.}}<br />
<br />
Place your image file in your home directory:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]: bs=4M<br />
<br />
where image.iso is the path to the iso image file within the {{ic|cygwin}} directory and {{ic|\\.\['''x''']}}: is your USB flash drive where '''x''' is the windows designated letter, e.g. {{ic|\\.\d:}}.<br />
<br />
On Cygwin 6.0 find out the correct partition with:<br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
{{Warning|This will irrevocably delete all files on your USB flash drive, so make sure you do not have any important files on the stick before doing this.}}<br />
<br />
dd if=image.iso of=/dev/sdb bs=4M<br />
<br />
===== dd for Windows =====<br />
<br />
{{Note|Some users have an "isolinux.bin missing or corrupt" problem when booting the media with this method.}}<br />
<br />
A GPL licensed dd version for Windows is available at http://www.chrysocome.net/dd. The advantage of this over Cygwin is a smaller download. Use it as shown in instructions for Cygwin above.<br />
<br />
To begin, download the latest version of dd for Windows. Once downloaded, extract the archive's contents into Downloads or elsewhere.<br />
<br />
Now, launch your {{ic|command prompt}} as an administrator. Next, change directory ({{ic|cd}}) into the Downloads directory.<br />
<br />
If your Arch Linux ISO is elsewhere you may need to state the full path, for convenience you may wish to put the Arch Linux ISO into the same folder as the dd executable. The basic format of the command will look like this.<br />
<br />
{{bc|<nowiki>dd if=archlinux-2013-XX-xx-dual.iso of=\\.\x: bs=4m</nowiki>}}<br />
{{Warning|This command will replace the drive's contents and its formatting with the ISO's. You will likely be unable to recover its contents in the event of an accidental copy. Be absolutely sure that you are directing dd to the correct drive before executing!}}<br />
Simply replace the various null spots (indicated by an "x") with the correct date and correct drive letter.<br />
<br />
Here is a complete example.<br />
{{bc|<nowiki>dd if=ISOs\archlinux-2013.08.01-dual.iso of=\\.\d: bs=4M</nowiki>}}<br />
<br />
==== In Mac OS X ====<br />
<br />
To be able to use {{ic|dd}} on your USB device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and in {{ic|Terminal.app}} run:<br />
<br />
$ diskutil list<br />
<br />
Figure out what your USB device is called with {{ic|mount}} or {{ic|<nowiki>sudo dmesg | tail</nowiki>}} (e.g. {{ic|/dev/disk1}}) and unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1):<br />
<br />
$ diskutil unmountDisk /dev/disk1<br />
<br />
Now we can continue in accordance with the instructions above (but use {{ic|1=bs=8192}} if you are using the OS X {{ic|dd}}, the number comes from {{ic|1024*8}}).<br />
<br />
{{hc|<nowiki>dd if=image.iso of=/dev/disk1 bs=8192</nowiki>|<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
}}<br />
<br />
It is probably a good idea to eject your drive before physical removal at this point:<br />
<br />
$ diskutil eject /dev/disk1<br />
<br />
==== How to restore the USB drive ====<br />
<br />
Because the ISO image is a hybrid which can either be burned to a disc or directly written to a USB drive, it does not include a standard partition table.<br />
<br />
After you install Arch Linux and you are done with the USB drive, you should zero out its first 512 bytes ''(meaning the boot code from the MBR and the non-standard partition table)'' if you want to restore it to full capacity:<br />
<br />
# dd count=1 bs=512 if=/dev/zero of=/dev/sd'''x''' && sync<br />
<br />
Then create a new partition table (e.g. "msdos") and filesystem (e.g. EXT4, FAT32) using {{Pkg|gparted}}, or from a terminal:<br />
<br />
* For EXT2/3/4 (adjust accordingly), it would be:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.ext4 /dev/sd'''x1'''<br />
# e2label /dev/sd'''x1''' USB_STICK<br />
<br />
* For FAT32, install the {{Pkg|dosfstools}} package and run:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.vfat -F32 /dev/sd'''x1'''<br />
# dosfslabel /dev/sd'''x1''' USB_STICK<br />
<br />
<br />
== Other Methods for BIOS systems ==<br />
{{Out of date|Can someone verify these work/are even needed to be mentioned?|section=Other Methods for BIOS systems}}<br />
=== In GNU/Linux ===<br />
<br />
==== Using UNetbootin ====<br />
<br />
UNetbootin can be used on any Linux distribution or Windows to copy your iso to a USB device. However, Unetbootin overwrites syslinux.cfg, so it creates a USB device that does not boot properly. For this reason, '''Unetbootin is not recommended''' -- please use {{ic|dd}} or one of the other methods discussed in this topic.<br />
{{Warning|UNetbootin writes over the default {{ic|syslinux.cfg}}; this must be restored before the USB device will boot properly.}}<br />
<br />
Edit {{ic|syslinux.cfg}}:<br />
<br />
{{hc|sysconfig.cfg|2=<br />
default menu.c32<br />
prompt 0<br />
menu title Archlinux Installer<br />
timeout 100<br />
<br />
label unetbootindefault<br />
menu label Archlinux_x86_64<br />
kernel /arch/boot/x86_64/vmlinuz<br />
append initrd=/arch/boot/x86_64/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
<br />
label ubnentry0<br />
menu label Archlinux_i686<br />
kernel /arch/boot/i686/vmlinuz<br />
append initrd=/arch/boot/i686/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
}}<br />
<br />
In {{ic|/dev/sd'''x1'''}} you must replace '''x''' with the first free letter after the last letter in use on the system where you are installing Arch Linux (e.g. if you have two hard drives, use {{ic|c}}.). You can make this change during the first phase of boot by pressing {{ic|Tab}} when the menu is shown.<br />
<br />
=== In Windows ===<br />
<br />
==== Win32 Disk Imager ====<br />
<br />
{{Warning|This will destroy all information on your USB flash drive!}}<br />
First, download the program from [http://sourceforge.net/projects/win32diskimager/ here]. Next, extract the archive and run the executable. Now, select the Arch Linux ISO under the {{ic|Image File}} section and the USB flash device letter (for example, [D:\]) under the {{ic|Device}} section. Finally, click {{ic|Write}} when ready.<br />
{{Tip|By default, the Win32 Disk Imager's file-browser assumes disk image files end with a {{ic|.img}} extension. However, you can simply change the {{ic|Files of type}} drop-down list to {{ic|*.*}} and continue on to selecting your Arch Linux ISO.}}<br />
{{Note|After installation, you may need to restore the USB flash drive following a process as outlined [[USB_Installation_Media#How_to_restore_the_USB_drive|here]].}}<br />
<br />
==== USBWriter for Windows ====<br />
<br />
Download the program from http://sourceforge.net/projects/usbwriter/ and run it. Select the arch image file, the target USB stick, and click on the {{ic|write}} button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
==== The Flashnul way ====<br />
<br />
[http://shounen.ru/soft/flashnul/ flashnul] is an utility to verify the functionality and maintenance of Flash-Memory (USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash etc).<br />
<br />
From a command prompt, invoke flashnul with {{ic|-p}}, and determine which device index is your USB drive, e.g.:<br />
<br />
{{hc|C:\>flashnul -p|<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
}}<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, {{ic|-L}}, and the path to your image, e.g:<br />
<br />
C:\>flashnul '''E:''' -L ''path\to\arch.iso''<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
{{Note|Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64.}}<br />
<br />
==== Loading the installation media from RAM ====<br />
<br />
This method uses [[Syslinux]] and a [[Ramdisk]] ([http://www.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) to load the entire Arch Linux ISO image into RAM. Since this will be running entirely from system memory, you will need to make sure the system you will be installing this on has an adequate amount. A minimum amount of RAM between 500 MB and 1 GB should suffice for a MEMDISK based, Arch Linux install.<br />
<br />
For more information on Arch Linux system requirements as well as those for MEMDISK see the [[Beginners' Guide]] and [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries here].<br />
{{Tip|Once the installer has completed loading you can simply remove the USB stick and even use it on a different machine to start the process all over again. Utilizing MEMDISK also allows booting and installing Arch Linux to and from the same USB flash drive.}}<br />
<br />
===== Preparing the USB flash drive =====<br />
<br />
Begin by formatting the USB flash drive as '''FAT32'''. Then create the following folders on the newly formatted drive.<br />
* {{ic|Boot}}<br />
** {{ic|Boot/ISOs}}<br />
** {{ic|Boot/Settings}}<br />
<br />
===== Copy the needed files to the USB flash drive =====<br />
<br />
Next copy the ISO that you would like to boot to the {{ic|Boot/ISOs}} folder. After that, extract from the following files from the latest release of {{pkg|syslinux}} from [http://www.kernel.org/pub/linux/utils/boot/syslinux/ here] and copy them into the following folders.<br />
* {{ic|./win32/syslinux.exe}} to the Desktop or Downloads folder on your system.<br />
* {{ic|./memdisk/memdisk}} to the {{ic|Settings}} folder on your USB flash drive.<br />
<br />
===== Create the configuration file =====<br />
<br />
After copying the needed files, navigate to the USB flash drive, /boot/Settings and create a {{ic|syslinux.cfg}} file.<br />
{{Warning|On the {{ic|INITRD}} line, be sure to use the name of the ISO file that you copied to your {{ic|ISOs}} folder!}}<br />
{{hc|/Boot/Settings/syslinux.cfg|2=<br />
DEFAULT arch_iso<br />
<br />
LABEL arch_iso<br />
MENU LABEL Arch Setup<br />
LINUX memdisk<br />
INITRD /Boot/ISOs/archlinux-2013.08.01-dual.iso<br />
APPEND iso}}<br />
For more information on Syslinux see the [[Syslinux|Arch Wiki article]].<br />
<br />
===== Final steps =====<br />
<br />
Finally, create a {{ic|*.bat}} file where {{ic|syslinux.exe}} is located and run it ("Run as administrator" if you are on Vista or Windows 7):<br />
{{hc|C:\Documents and Settings\username\Desktop\install.bat|<br />
@echo off<br />
syslinux.exe -m -a -d /Boot/Settings X:}}<br />
<br />
==== Universal USB Installer ====<br />
<br />
The Windows tool [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/] can be used to quickly create a Live USB media with multiple Installers of many Linux distros. Once created, Installers can be added or removed without reformatting the USB drive.<br />
<br />
== Troubleshooting ==<br />
<br />
* For the [[#Loading the installation media from RAM|MEMDISK Method]], if you get the famous "30 seconds" error trying to boot the i686 version, press the {{ic|Tab}} key over the {{ic|Boot Arch Linux (i686)}} entry and add {{ic|vmalloc&#61;448M}} at the end. For reference: ''If your image is bigger than 128MiB and you have a 32-bit OS, then you have to increase the maximum memory usage of vmalloc''. [http://www.syslinux.org/wiki/index.php/MEMDISK#-_memdiskfind_in_combination_with_phram_and_mtdblock]<br />
<br />
* If you get the "30 seconds" error due to the {{ic|/dev/disk/by-label/ARCH_XXXXXX}} not mounting, try renaming your USB media to {{ic|ARCH_XXXXXX}} (e.g. {{ic|ARCH_201302}}).<br />
<br />
== See Also ==<br />
<br />
* [http://www.gentoo.org/doc/en/liveusb.xml Gentoo liveusb document]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=285178USB flash installation medium2013-11-29T08:29:47Z<p>The.ridikulus.rat: Undo revision 285083 by Graysky (talk)</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:USB Installation Media]]<br />
[[bg:USB Installation Media]]<br />
[[de:Installation von einem USB-Stick]]<br />
[[es:USB Installation Media]]<br />
[[it:USB Installation Media]]<br />
[[ja:USB Installation Media]]<br />
[[ro:Instalare prin USB]]<br />
[[ru:USB Installation Media]]<br />
[[tr:USB_ile_kurulum]]<br />
[[zh-CN:USB Installation Media]]<br />
[[zh-TW:USB Installation Media]]<br />
{{Article summary start}}<br />
{{Article summary text|Mutiplatform instructions on creating a bootable USB stick which can be used for installing Arch Linux, system maintenance or for recovery purposes.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|CD Burning}}<br />
{{Article summary end}}<br />
This page discusses various methods on how to create a Arch Linux Installer USB drive (also referred to as ''"flash drive", "USB stick", "USB key"'', etc) for booting in BIOS and UEFI systems. The result will be a LiveUSB (LiveCD-like) system that, because of the nature of [[Wikipedia:SquashFS|SquashFS]], will discard all changes once the computer shuts down.<br />
<br />
If you would like to run a full install of Arch Linux from a USB drive (i.e. with persistent settings), see [[Installing Arch Linux on a USB key]]. If you would like to use your bootable Arch Linux USB stick as a rescue USB, see [[Change Root]].<br />
<br />
== BIOS and UEFI Bootable USB ==<br />
<br />
=== Recommended Method ===<br />
<br />
==== In GNU/Linux ====<br />
<br />
This method is slightly more complicated than writing the image directly with {{ic|dd}}, but it does keep the drive usable for data storage. Before you begin, make sure that your USB device is formatted as either FAT32. Also, make sure that you have the latest ''syslinux'' package (version 6.02 or newer) installed<br />
<br />
* [[Beginners_Guide#Prepare_the_storage_drive|First create a MBR (msdos) partition table with at least one partition, in the USB]] (it is fine to use an already partitioned USB).<br />
<br />
* Mount the ISO image:<br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2013.10.01-dual.iso /mnt/iso<br />
<br />
* Then create a FAT32 filesystem in the partition on the USB (unmount before, if necessary).<br />
<br />
* Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
# mount /dev/sd'''X'''1 /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}<br />
<br />
* Adjust the configuration files (necessary only for [[Archiso]], not needed for [[Archboot]] iso):<br />
<br />
{{Warning|Failure to label the drive "{{ic|ARCH_2013XX}}" (with the appropriate release month) or to use an [[UUID]] (to re-label it to whatever you like) '''will''' get you the infamous "30 seconds" error.}}<br />
<br />
Here is how you can replace the {{ic|1=archisolabel=ARCH_2013XX}} part with your equivalent of {{ic|1=archiso'''device'''=/dev/disk/by-uuid/47FA-4071}} for both config files at the same time, using a single command:<br />
<br />
{{Note|Adjust {{ic|/dev/sd'''X'''1}} before running it, else it will become blank (since drive {{ic|sd'''X'''}} does not exist).}}<br />
<br />
$ sed -i "s|label=ARCH_.*|device=/dev/disk/by-uuid/$(blkid -o value -s UUID /dev/sd'''X'''1)|" archiso_sys{32,64}.cfg<br />
<br />
* Install Syslinux to the USB by following [[Syslinux#Manual_install]]. Overwrite the existing syslinux modules ({{ic|*.c32}} files) present in the USB (from the ISO) with the ones from the Syslinux pkg to avoid version mismatch related boot failure.<br />
<br />
* Mark the USB partition as active by following [[Syslinux#MBR_partition_table]]<br />
<br />
==== In Windows ====<br />
<br />
{{Note|<br />
* Do not use any '''Bootable USB Creator utility''' for creating the UEFI bootable USB. Do not use ''dd for Windows'' to dd the ISO to the USB drive.<br />
<br />
* In the below commands '''X:''' is assumed to be the USB flash drive in Windows.<br />
<br />
* Windows used backward slash {{ic|\}} as path-separator, so the same is used in the below commands.<br />
<br />
* All commands should be run in Windows command prompt '''as administrator'''.<br />
<br />
* {{ic|>}} denotes the Windows command prompt.<br />
}}<br />
<br />
* Partition and format the USB drive using [http://rufus.akeo.ie/ Rufus USB partitioner]. Select partition scheme option as '''MBR for BIOS and UEFI''' and File system as '''FAT32'''. Uncheck "Create a bootable disk using ISO image" and "Create extended label and icon files" options. Use <br />
<br />
* Change the '''Volume Label''' of the USB flash drive {{ic|X:}} to match the LABEL mentioned in {{ic|1=archisolabel=}} part in {{ic|<ISO>\loader\entries\archiso-x86_64.conf}}. This step is required for Official ISO ([[Archiso]]) but not required for [[Archboot]].<br />
<br />
* Extract the ISO (similar to extracting ZIP archive) to the USB flash drive (using [http://7-zip.org/ 7-Zip]. <br />
<br />
* Download latest official syslinux 6.xx binaries (zip file) from https://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract it.<br />
<br />
* Run the following command (in Windows cmd prompt, as admin) <br />
<br />
> cd bios\<br />
> for /r %Y in (*.c32) do copy "%Y" "X:\boot\syslinux\" /y<br />
> copy mbr\*.bin X:\boot\syslinux\ /y<br />
<br />
* Install Syslinux to the USB by running (use {{ic|win64\syslinux64.exe}} for x64 Windows):<br />
<br />
> cd bios\<br />
> win32\syslinux.exe -d /boot/syslinux -i -a -m X:<br />
<br />
{{Note|<br />
* The above step install Syslinux {{ic|ldlinux.sys}} to the USB partition VBR, sets the partition as active/boot in the MBR partition table and write the MBR boot code to the 1st 400-byte boot code region of the USB.<br />
<br />
* The {{ic|-d}} switch expects path with forward slash path-separator like in *unix systems.<br />
}}<br />
<br />
=== Using dd ===<br />
<br />
{{Warning|This will irrevocably destroy all data on {{ic|/dev/sd'''x'''}}.}}<br />
<br />
==== In GNU/Linux ====<br />
<br />
{{Tip|Check that the USB flash installation media is '''not''' mounted with {{ic|lsblk}}.}}<br />
<br />
{{Note|Use {{ic|/dev/sd'''x'''}} instead of {{ic|/dev/sd'''x1'''}}.}}<br />
<br />
# dd bs=4M if=/path/to/archlinux.iso of=/dev/sd'''x''' && sync<br />
<br />
==== In Windows ====<br />
<br />
===== Using Cygwin =====<br />
<br />
Make sure your [http://www.cygwin.com/ Cygwin] installation contains the {{ic|dd}} package.<br />
<br />
{{Tip|If you do not want to install Cygwin, you can download {{ic|dd}} for Windows from [http://www.chrysocome.net/dd here]. See the next section for more information.}}<br />
<br />
Place your image file in your home directory:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]: bs=4M<br />
<br />
where image.iso is the path to the iso image file within the {{ic|cygwin}} directory and {{ic|\\.\['''x''']}}: is your USB flash drive where '''x''' is the windows designated letter, e.g. {{ic|\\.\d:}}.<br />
<br />
On Cygwin 6.0 find out the correct partition with:<br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
{{Warning|This will irrevocably delete all files on your USB flash drive, so make sure you do not have any important files on the stick before doing this.}}<br />
<br />
dd if=image.iso of=/dev/sdb bs=4M<br />
<br />
===== dd for Windows =====<br />
<br />
{{Note|Some users have an "isolinux.bin missing or corrupt" problem when booting the media with this method.}}<br />
<br />
A GPL licensed dd version for Windows is available at http://www.chrysocome.net/dd. The advantage of this over Cygwin is a smaller download. Use it as shown in instructions for Cygwin above.<br />
<br />
To begin, download the latest version of dd for Windows. Once downloaded, extract the archive's contents into Downloads or elsewhere.<br />
<br />
Now, launch your {{ic|command prompt}} as an administrator. Next, change directory ({{ic|cd}}) into the Downloads directory.<br />
<br />
If your Arch Linux ISO is elsewhere you may need to state the full path, for convenience you may wish to put the Arch Linux ISO into the same folder as the dd executable. The basic format of the command will look like this.<br />
<br />
{{bc|<nowiki>dd if=archlinux-2013-XX-xx-dual.iso of=\\.\x: bs=4m</nowiki>}}<br />
{{Warning|This command will replace the drive's contents and its formatting with the ISO's. You will likely be unable to recover its contents in the event of an accidental copy. Be absolutely sure that you are directing dd to the correct drive before executing!}}<br />
Simply replace the various null spots (indicated by an "x") with the correct date and correct drive letter.<br />
<br />
Here is a complete example.<br />
{{bc|<nowiki>dd if=ISOs\archlinux-2013.08.01-dual.iso of=\\.\d: bs=4M</nowiki>}}<br />
<br />
==== In Mac OS X ====<br />
<br />
To be able to use {{ic|dd}} on your USB device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and in {{ic|Terminal.app}} run:<br />
<br />
$ diskutil list<br />
<br />
Figure out what your USB device is called with {{ic|mount}} or {{ic|<nowiki>sudo dmesg | tail</nowiki>}} (e.g. {{ic|/dev/disk1}}) and unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1):<br />
<br />
$ diskutil unmountDisk /dev/disk1<br />
<br />
Now we can continue in accordance with the instructions above (but use {{ic|1=bs=8192}} if you are using the OS X {{ic|dd}}, the number comes from {{ic|1024*8}}).<br />
<br />
{{hc|<nowiki>dd if=image.iso of=/dev/disk1 bs=8192</nowiki>|<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
}}<br />
<br />
It is probably a good idea to eject your drive before physical removal at this point:<br />
<br />
$ diskutil eject /dev/disk1<br />
<br />
==== How to restore the USB drive ====<br />
<br />
Because the ISO image is a hybrid which can either be burned to a disc or directly written to a USB drive, it does not include a standard partition table.<br />
<br />
After you install Arch Linux and you are done with the USB drive, you should zero out its first 512 bytes ''(meaning the boot code from the MBR and the non-standard partition table)'' if you want to restore it to full capacity:<br />
<br />
# dd count=1 bs=512 if=/dev/zero of=/dev/sd'''x''' && sync<br />
<br />
Then create a new partition table (e.g. "msdos") and filesystem (e.g. EXT4, FAT32) using {{Pkg|gparted}}, or from a terminal:<br />
<br />
* For EXT2/3/4 (adjust accordingly), it would be:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.ext4 /dev/sd'''x1'''<br />
# e2label /dev/sd'''x1''' USB_STICK<br />
<br />
* For FAT32, install the {{Pkg|dosfstools}} package and run:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.vfat -F32 /dev/sd'''x1'''<br />
# dosfslabel /dev/sd'''x1''' USB_STICK<br />
<br />
<br />
== Other Methods for BIOS systems ==<br />
{{Out of date|Can someone verify these work/are even needed to be mentioned?|section=Other Methods for BIOS systems}}<br />
=== In GNU/Linux ===<br />
<br />
==== Using UNetbootin ====<br />
<br />
UNetbootin can be used on any Linux distribution or Windows to copy your iso to a USB device. However, Unetbootin overwrites syslinux.cfg, so it creates a USB device that does not boot properly. For this reason, '''Unetbootin is not recommended''' -- please use {{ic|dd}} or one of the other methods discussed in this topic.<br />
{{Warning|UNetbootin writes over the default {{ic|syslinux.cfg}}; this must be restored before the USB device will boot properly.}}<br />
<br />
Edit {{ic|syslinux.cfg}}:<br />
<br />
{{hc|sysconfig.cfg|2=<br />
default menu.c32<br />
prompt 0<br />
menu title Archlinux Installer<br />
timeout 100<br />
<br />
label unetbootindefault<br />
menu label Archlinux_x86_64<br />
kernel /arch/boot/x86_64/vmlinuz<br />
append initrd=/arch/boot/x86_64/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
<br />
label ubnentry0<br />
menu label Archlinux_i686<br />
kernel /arch/boot/i686/vmlinuz<br />
append initrd=/arch/boot/i686/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
}}<br />
<br />
In {{ic|/dev/sd'''x1'''}} you must replace '''x''' with the first free letter after the last letter in use on the system where you are installing Arch Linux (e.g. if you have two hard drives, use {{ic|c}}.). You can make this change during the first phase of boot by pressing {{ic|Tab}} when the menu is shown.<br />
<br />
=== In Windows ===<br />
<br />
==== Win32 Disk Imager ====<br />
<br />
{{Warning|This will destroy all information on your USB flash drive!}}<br />
First, download the program from [http://sourceforge.net/projects/win32diskimager/ here]. Next, extract the archive and run the executable. Now, select the Arch Linux ISO under the {{ic|Image File}} section and the USB flash device letter (for example, [D:\]) under the {{ic|Device}} section. Finally, click {{ic|Write}} when ready.<br />
{{Tip|By default, the Win32 Disk Imager's file-browser assumes disk image files end with a {{ic|.img}} extension. However, you can simply change the {{ic|Files of type}} drop-down list to {{ic|*.*}} and continue on to selecting your Arch Linux ISO.}}<br />
{{Note|After installation, you may need to restore the USB flash drive following a process as outlined [[USB_Installation_Media#How_to_restore_the_USB_drive|here]].}}<br />
<br />
==== USBWriter for Windows ====<br />
<br />
Download the program from http://sourceforge.net/projects/usbwriter/ and run it. Select the arch image file, the target USB stick, and click on the {{ic|write}} button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
==== The Flashnul way ====<br />
<br />
[http://shounen.ru/soft/flashnul/ flashnul] is an utility to verify the functionality and maintenance of Flash-Memory (USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash etc).<br />
<br />
From a command prompt, invoke flashnul with {{ic|-p}}, and determine which device index is your USB drive, e.g.:<br />
<br />
{{hc|C:\>flashnul -p|<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
}}<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, {{ic|-L}}, and the path to your image, e.g:<br />
<br />
C:\>flashnul '''E:''' -L ''path\to\arch.iso''<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
{{Note|Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64.}}<br />
<br />
==== Loading the installation media from RAM ====<br />
<br />
This method uses [[Syslinux]] and a [[Ramdisk]] ([http://www.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) to load the entire Arch Linux ISO image into RAM. Since this will be running entirely from system memory, you will need to make sure the system you will be installing this on has an adequate amount. A minimum amount of RAM between 500 MB and 1 GB should suffice for a MEMDISK based, Arch Linux install.<br />
<br />
For more information on Arch Linux system requirements as well as those for MEMDISK see the [[Beginners' Guide]] and [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries here].<br />
{{Tip|Once the installer has completed loading you can simply remove the USB stick and even use it on a different machine to start the process all over again. Utilizing MEMDISK also allows booting and installing Arch Linux to and from the same USB flash drive.}}<br />
<br />
===== Preparing the USB flash drive =====<br />
<br />
Begin by formatting the USB flash drive as '''FAT32'''. Then create the following folders on the newly formatted drive.<br />
* {{ic|Boot}}<br />
** {{ic|Boot/ISOs}}<br />
** {{ic|Boot/Settings}}<br />
<br />
===== Copy the needed files to the USB flash drive =====<br />
<br />
Next copy the ISO that you would like to boot to the {{ic|Boot/ISOs}} folder. After that, extract from the following files from the latest release of {{pkg|syslinux}} from [http://www.kernel.org/pub/linux/utils/boot/syslinux/ here] and copy them into the following folders.<br />
* {{ic|./win32/syslinux.exe}} to the Desktop or Downloads folder on your system.<br />
* {{ic|./memdisk/memdisk}} to the {{ic|Settings}} folder on your USB flash drive.<br />
<br />
===== Create the configuration file =====<br />
<br />
After copying the needed files, navigate to the USB flash drive, /boot/Settings and create a {{ic|syslinux.cfg}} file.<br />
{{Warning|On the {{ic|INITRD}} line, be sure to use the name of the ISO file that you copied to your {{ic|ISOs}} folder!}}<br />
{{hc|/Boot/Settings/syslinux.cfg|2=<br />
DEFAULT arch_iso<br />
<br />
LABEL arch_iso<br />
MENU LABEL Arch Setup<br />
LINUX memdisk<br />
INITRD /Boot/ISOs/archlinux-2013.08.01-dual.iso<br />
APPEND iso}}<br />
For more information on Syslinux see the [[Syslinux|Arch Wiki article]].<br />
<br />
===== Final steps =====<br />
<br />
Finally, create a {{ic|*.bat}} file where {{ic|syslinux.exe}} is located and run it ("Run as administrator" if you are on Vista or Windows 7):<br />
{{hc|C:\Documents and Settings\username\Desktop\install.bat|<br />
@echo off<br />
syslinux.exe -m -a -d /Boot/Settings X:}}<br />
<br />
==== Universal USB Installer ====<br />
<br />
The Windows tool [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/] can be used to quickly create a Live USB media with multiple Installers of many Linux distros. Once created, Installers can be added or removed without reformatting the USB drive.<br />
<br />
== Troubleshooting ==<br />
<br />
* For the [[#Loading the installation media from RAM|MEMDISK Method]], if you get the famous "30 seconds" error trying to boot the i686 version, press the {{ic|Tab}} key over the {{ic|Boot Arch Linux (i686)}} entry and add {{ic|vmalloc&#61;448M}} at the end. For reference: ''If your image is bigger than 128MiB and you have a 32-bit OS, then you have to increase the maximum memory usage of vmalloc''. [http://www.syslinux.org/wiki/index.php/MEMDISK#-_memdiskfind_in_combination_with_phram_and_mtdblock]<br />
<br />
* If you get the "30 seconds" error due to the {{ic|/dev/disk/by-label/ARCH_XXXXXX}} not mounting, try renaming your USB media to {{ic|ARCH_XXXXXX}} (e.g. {{ic|ARCH_201302}}).<br />
<br />
== See Also ==<br />
<br />
* [http://www.gentoo.org/doc/en/liveusb.xml Gentoo liveusb document]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=284141GRUB2013-11-22T18:24:03Z<p>The.ridikulus.rat: Revamp GRUB STandalone info for latest git related changes</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|Arch Boot Process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
<br />
[https://www.gnu.org/software/grub/ GRUB] - not to be confused with [[GRUB Legacy]] - is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} filesystem) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported filesystem.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
<br />
==== BIOS systems ====<br />
<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of bootsectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no filesystem. The size of 1007 KiB will allow for the following partition to be correctly alligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
<br />
An EFI System Partition (ESP) is needed on every disc you wan to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Archlinux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it /dev/sda.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat filesystem and the 'boot' flag enabled. On it, there should be a folder called "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
<br />
=== BIOS systems ===<br />
<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To setup {{ic|grub}} in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to partition or partitionless disk =====<br />
<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that {{ic|grub}} relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix dir {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the filesystem in the partition is being altered (files copied, deleted etc.). For more info see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using chattr command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if {{ic|grub}} is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
===== Generate core.img alone =====<br />
<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any {{ic|grub}} bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
<br />
===== Recommended method =====<br />
<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to boot using UEFI and not BIOS. If you booted by just copying the ISO file to the USB drive, you have booted using BIOS. You will need to [[Unified Extensible Firmware Interface#Create UEFI bootable USB from ISO|create a UEFI bootable USB device]] and reboot with it or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed.<br />
<br />
===== Alternative method =====<br />
<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[Beginners' Guide#GRUB]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
<br />
{{Note|Use {{Aur|grub-git}} pkg for standalone GRUB EFI image as the {{Pkg|grub}} pkg does not contain various grub-mkstandalone specific fixes (specifically {{ic|${cmdpath} }} support, which is necessary).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows"<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "/boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside grub env it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same dir as the EFI file (inside grub env it is denoted by {{ic|${cmdpath}}}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="/boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any dir inside the EFI System Partition (as long as they are in the same dir), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path for BIOS systems is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* For EFI systems, if GRUB was installed with the {{ic|1=--boot-directory=$esp/EFI}} option set, the {{ic|grub.cfg}} file must be placed in the same directory as {{ic|grubx64.efi}}. Otherwise, the {{ic|grub.cfg}} file goes in {{ic|/boot/grub/}}, just like in BIOS systems.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. It can detect only systems on mounted partitions, so mount them before running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for eg: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
<br />
==== Disable framebuffer ====<br />
<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via filesystem UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant filesystem is resized or recreated. Remember this when modifying partitions & filesystems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} folder.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more infos).<br />
<br />
'''/etc/grub.d/40_custom''':<br />
<br />
{{bc|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|<nowiki>drivemap -s hd0 hd2</nowiki>}}<br />
<br />
===== Windows Installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 x86_64 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$uuid}} are obtained with the following two commands. {{ic|$uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|bootmgr}}, not your "real" Windows partition (usually C:). When showing all UUIDs with blkid, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS filesystem of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
For Windows Vista/7/8:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
<br />
{{Note|The example assumes that the iso is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
<br />
It is possible to use labels, human-readable strings attached to filesystems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
<br />
grub> <br />
<br />
The GRUB's command shell environemnt can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Normal loading ====<br />
<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|kcm-grub2|This Kcm module manages the most common settings of GRUB|http://kde-apps.org/content/show.php?content&#61;137886|{{AUR|kcm-grub2}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod (hdX,Y)/boot/grub/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}} and {{ic|insmod (hdX,Y)/grub/linux.mod}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Intel BIOS not booting GPT ===<br />
<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
=== Enable debug messages ===<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=283953Unified Extensible Firmware Interface2013-11-21T18:20:25Z<p>The.ridikulus.rat: /* Remove UEFI boot support from Optical Media */</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== BIOS ==<br />
<br />
{{Merge|Arch Boot Process|Together with the introduction of [[#UEFI]], merge this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<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. BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order. Since very little can be achieved by a program that fits into the 440-byte boot code area, usually a common boot loader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel. See [[Arch Boot Process]] for more details.<br />
<br />
== UEFI ==<br />
<br />
{{Merge|Arch Boot Process|Together with [[#BIOS]], merge the introduction of this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<br />
<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 />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a UEFI Application corresponding to the EFI firmware bitness/architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use IA32 (32-bit) EFI are older (pre 2008) Apple Macs, some Intel Cloverfield ultrabooks and some older Intel Server boards 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 />
=== Boot Process under UEFI ===<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases.<br />
<br />
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk has to use MBR. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 vathpela's efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings. Upstream (http://linux.dell.com/git/efibootmgr.git) efibootmgr code does not support efivarfs. A fork of efibootmgr by Fedora's Peter Jones (vathpela) supports both efivarfs and sysfs-efivars. It is currently used in official core/{{Pkg|efibootmgr}} pkg and AUR pkg {{AUR|efibootmgr-pjones-git}} - https://github.com/vathpela/efibootmgr/tree/libefivars<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
* Upstream efibootmgr http://linux.dell.com/git/efibootmgr.git does not support efivarfs. However vathpela's efibootmgr supports efivarfs and is currently used in official efibootmgr pkg. sysfs-efivars is also completely disabled in official Arch kernel and it supports only efivarfs. This section is written with the assumtion that you are using only efivarfs and vathpela's efibootmgr.<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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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), modifyiang 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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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}}<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 '''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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User_talk:The.ridikulus.rat&diff=283951User talk:The.ridikulus.rat2013-11-21T18:19:28Z<p>The.ridikulus.rat: /* UEFI Bootable Media */</p>
<hr />
<div>== Question about edit to [[Beginners' Guide]] ==<br />
<br />
Hi,<br />
<br />
I noticed your recent edits in the [[Beginners' Guide]], where you stated that the --target parameter is required. The man page however states that it defaults to the current platform (should be sufficient for beginners). I also just tested this (at least for BIOS), and it seems to work fine without the parameter.<br />
<br />
Can you explain why it is needed?<br />
<br />
Thanks --[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 20:43, 28 August 2013 (UTC)<br />
<br />
AFAIK in the initial release of grub 2.00 grub-install explicitly required the user to provide the --target parameter, but then in some later bzr snapshot grub-install tries to guess the platform. In my experience grub-install defaults to i386-pc (BIOS) target most of the time, even in case of x86_64-efi (UEFI) system. I suggest changing all grub-install commands across the wiki to use --target parameter to remove this confusion. -- [[User:The.ridikulus.rat|Keshav Padram Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 15:21, 29 August 2013 (UTC)<br />
<br />
:Ok, I understand, I thought the 'guessing' was more robust and failure-proof. Thanks for the reply! :) --[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 19:47, 29 August 2013 (UTC)<br />
<br />
----<br />
<br />
<br />
Hi,<br />
<br />
I noticed your recent changes to the Beginner's Guide on the 18th September, particularly around EFISTUB. You have certainly managed to reduce the number of lines on the page which is good.<br />
<br />
However I wanted to confirm that the user really is no longer required to reload the efivars module before chroot ? I read your entry about Jones' new and improved efibootmgr and this should mean that the module reload is no longer required, but has the fork been mainlined into the Arch core repository yet ?<br />
<br />
Also is there a way to simplify the call to efibootmgr especially to be easier for new Archers or at least some way to make it easier. For example : '''"root=''/dev/sdaX''''' may be a little more welcoming than '''"root=PARTUUID=xxxxxxxxxxxxxxxxx"'''.<br />
What do you think ? <br />
Thanks. [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 19:41, 18 September 2013 (UTC)<br />
<br />
<br />
From core/linux-3.11.1-1 onwards efivars module is not even compiled in the kernel https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=ebf4d782ffe29e3b00e93011a493cbedffbd7415 . This is a deliberate change made by the devs http://www.mail-archive.com/arch-dev-public@archlinux.org/msg21788.html . THis chaneg was made only after new efibootmgr moved to core, see 'Upstream URL' in https://www.archlinux.org/packages/core/x86_64/efibootmgr/ .<br />
<br />
Reg /dev/sdaX vs PARTUUID, sdaX is very ambiguous and not recommended even in case of bios boot. IN case of UEFI boot, since we are already using GPT, PARTUUIDs are the best FS-independent unambiguous way of specifying a partition. You can even mention (FS) UUID here but in case of GPT I recommend PARTUUID. Even if they are no Archers, they should not be simply conpy-pasting the commands from this page. They should understand what efibootmgr is, what PARTUUID is etc. and then type the command on their own. My intention is not be more welcoming to newbies. I just don't want them to come back later complaining sdaX is not the partition they want when they make some changes in their system and then it refuses to boot due to using ambiguous sdaX.<br />
-- [[User:The.ridikulus.rat|Keshav Padram Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 04:43, 19 September 2013 (UTC)<br />
<br />
<br />
<br />
Hi Keshav,<br />
<br />
Thanks for the full and prompt reply.<br />
<br />
I am still on a 3.10 series kernel and was unaware of the recent changes that you mentioned. The links were informative and your information has brought me up to date, cheers.<br />
<br />
I take your point about /dev/sdaX being more ambiguous than UUIDs and I agree that no-one should be copy-pasting instructions from the guide into their terminal (I hope no-one actually does that). You are right, it is important that everyone should be trying to understand what they are doing.<br />
<br />
Therefore, what I propose to do is to add a note explaining what the efibootmgr options are and why UUIDs are recommended over the alternative . This will force users to actually read and think about what they are doing and then make an informed, intelligent decision.<br />
<br />
What do you think ?<br />
<br />
-- [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 13:22, 20 September 2013 (UTC)<br />
<br />
== Disabling modesetting ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=Kernel_Mode_Setting&diff=next&oldid=273583 This] really looks like the user should add ''all'' of the parameters. In fact, it does not make sense to add {{ic|1=nouveau.modeset=0}} on a Radeon card. Also note that the {{ic|radeon}} driver/module [[ATI#Kernel mode-setting (KMS)|requires]] modeseting. So I'll have to undo your edit. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:35, 7 October 2013 (UTC)<br />
<br />
== UEFI Bootable Media ==<br />
<br />
Hi,<br />
<br />
just a quick note on your [https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=283870&oldid=283149 recent edit]: the section [[Unified_Extensible_Firmware_Interface#Remove_UEFI_boot_support_from_ISO]] which was left in place refers to "previous section", which was merged into [[USB Flash Installation Media]]. I think it should be merged too, what is your opinion?<br />
<br />
Otherwise I really like your work, keep up!<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:14, 21 November 2013 (UTC)<br />
<br />
I have changed the "Note" to point directly to the [[USB Flash Installation Media#BIOS and UEFI Bootable USB]]. The '''Remove UEFI boot support from ISO''' actually talks about removing CD/DVD UEFI boot support. I changed the title of that section to '''Remove UEFI boot support from Optical Media''' to make it more clear. <br />
<br />
To remove USB UEFI boot, you just have make sure <USB>/EFI/Boot/bootx64.efi (case-insensitive) file does not exist (simply delete or rename it, and the USB no longer supports UEFI boot). Setting up a USB drive to UEFI boot is much more easier and straight-forward compared to setting up a CD/DVD (or actually the ISO) (via the El-torito entry) to UEFI boot.<br />
<br />
-- [[User:The.ridikulus.rat|Keshav Padram Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 18:08, 21 November 2013 (UTC)</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=283949Unified Extensible Firmware Interface2013-11-21T18:16:33Z<p>The.ridikulus.rat: Add note about info being specific to UEFI booting from Optical Media, and remove the warning that has nothing to do with the info in this section</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== BIOS ==<br />
<br />
{{Merge|Arch Boot Process|Together with the introduction of [[#UEFI]], merge this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<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. BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order. Since very little can be achieved by a program that fits into the 440-byte boot code area, usually a common boot loader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel. See [[Arch Boot Process]] for more details.<br />
<br />
== UEFI ==<br />
<br />
{{Merge|Arch Boot Process|Together with [[#BIOS]], merge the introduction of this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<br />
<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 />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a UEFI Application corresponding to the EFI firmware bitness/architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use IA32 (32-bit) EFI are older (pre 2008) Apple Macs, some Intel Cloverfield ultrabooks and some older Intel Server boards 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 />
=== Boot Process under UEFI ===<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases.<br />
<br />
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk has to use MBR. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 vathpela's efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings. Upstream (http://linux.dell.com/git/efibootmgr.git) efibootmgr code does not support efivarfs. A fork of efibootmgr by Fedora's Peter Jones (vathpela) supports both efivarfs and sysfs-efivars. It is currently used in official core/{{Pkg|efibootmgr}} pkg and AUR pkg {{AUR|efibootmgr-pjones-git}} - https://github.com/vathpela/efibootmgr/tree/libefivars<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
* Upstream efibootmgr http://linux.dell.com/git/efibootmgr.git does not support efivarfs. However vathpela's efibootmgr supports efivarfs and is currently used in official efibootmgr pkg. sysfs-efivars is also completely disabled in official Arch kernel and it supports only efivarfs. This section is written with the assumtion that you are using only efivarfs and vathpela's efibootmgr.<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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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), modifyiang 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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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 specifically from a CD/DVD only, 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}}<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 '''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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=User_talk:The.ridikulus.rat&diff=283948User talk:The.ridikulus.rat2013-11-21T18:08:46Z<p>The.ridikulus.rat: /* UEFI Bootable Media */</p>
<hr />
<div>== Question about edit to [[Beginners' Guide]] ==<br />
<br />
Hi,<br />
<br />
I noticed your recent edits in the [[Beginners' Guide]], where you stated that the --target parameter is required. The man page however states that it defaults to the current platform (should be sufficient for beginners). I also just tested this (at least for BIOS), and it seems to work fine without the parameter.<br />
<br />
Can you explain why it is needed?<br />
<br />
Thanks --[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 20:43, 28 August 2013 (UTC)<br />
<br />
AFAIK in the initial release of grub 2.00 grub-install explicitly required the user to provide the --target parameter, but then in some later bzr snapshot grub-install tries to guess the platform. In my experience grub-install defaults to i386-pc (BIOS) target most of the time, even in case of x86_64-efi (UEFI) system. I suggest changing all grub-install commands across the wiki to use --target parameter to remove this confusion. -- [[User:The.ridikulus.rat|Keshav Padram Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 15:21, 29 August 2013 (UTC)<br />
<br />
:Ok, I understand, I thought the 'guessing' was more robust and failure-proof. Thanks for the reply! :) --[[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 19:47, 29 August 2013 (UTC)<br />
<br />
----<br />
<br />
<br />
Hi,<br />
<br />
I noticed your recent changes to the Beginner's Guide on the 18th September, particularly around EFISTUB. You have certainly managed to reduce the number of lines on the page which is good.<br />
<br />
However I wanted to confirm that the user really is no longer required to reload the efivars module before chroot ? I read your entry about Jones' new and improved efibootmgr and this should mean that the module reload is no longer required, but has the fork been mainlined into the Arch core repository yet ?<br />
<br />
Also is there a way to simplify the call to efibootmgr especially to be easier for new Archers or at least some way to make it easier. For example : '''"root=''/dev/sdaX''''' may be a little more welcoming than '''"root=PARTUUID=xxxxxxxxxxxxxxxxx"'''.<br />
What do you think ? <br />
Thanks. [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 19:41, 18 September 2013 (UTC)<br />
<br />
<br />
From core/linux-3.11.1-1 onwards efivars module is not even compiled in the kernel https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=ebf4d782ffe29e3b00e93011a493cbedffbd7415 . This is a deliberate change made by the devs http://www.mail-archive.com/arch-dev-public@archlinux.org/msg21788.html . THis chaneg was made only after new efibootmgr moved to core, see 'Upstream URL' in https://www.archlinux.org/packages/core/x86_64/efibootmgr/ .<br />
<br />
Reg /dev/sdaX vs PARTUUID, sdaX is very ambiguous and not recommended even in case of bios boot. IN case of UEFI boot, since we are already using GPT, PARTUUIDs are the best FS-independent unambiguous way of specifying a partition. You can even mention (FS) UUID here but in case of GPT I recommend PARTUUID. Even if they are no Archers, they should not be simply conpy-pasting the commands from this page. They should understand what efibootmgr is, what PARTUUID is etc. and then type the command on their own. My intention is not be more welcoming to newbies. I just don't want them to come back later complaining sdaX is not the partition they want when they make some changes in their system and then it refuses to boot due to using ambiguous sdaX.<br />
-- [[User:The.ridikulus.rat|Keshav Padram Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 04:43, 19 September 2013 (UTC)<br />
<br />
<br />
<br />
Hi Keshav,<br />
<br />
Thanks for the full and prompt reply.<br />
<br />
I am still on a 3.10 series kernel and was unaware of the recent changes that you mentioned. The links were informative and your information has brought me up to date, cheers.<br />
<br />
I take your point about /dev/sdaX being more ambiguous than UUIDs and I agree that no-one should be copy-pasting instructions from the guide into their terminal (I hope no-one actually does that). You are right, it is important that everyone should be trying to understand what they are doing.<br />
<br />
Therefore, what I propose to do is to add a note explaining what the efibootmgr options are and why UUIDs are recommended over the alternative . This will force users to actually read and think about what they are doing and then make an informed, intelligent decision.<br />
<br />
What do you think ?<br />
<br />
-- [[User:Kal|Kal]] ([[User talk:Kal|talk]]) 13:22, 20 September 2013 (UTC)<br />
<br />
== Disabling modesetting ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=Kernel_Mode_Setting&diff=next&oldid=273583 This] really looks like the user should add ''all'' of the parameters. In fact, it does not make sense to add {{ic|1=nouveau.modeset=0}} on a Radeon card. Also note that the {{ic|radeon}} driver/module [[ATI#Kernel mode-setting (KMS)|requires]] modeseting. So I'll have to undo your edit. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:35, 7 October 2013 (UTC)<br />
<br />
== UEFI Bootable Media ==<br />
<br />
Hi,<br />
<br />
just a quick note on your [https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=283870&oldid=283149 recent edit]: the section [[Unified_Extensible_Firmware_Interface#Remove_UEFI_boot_support_from_ISO]] which was left in place refers to "previous section", which was merged into [[USB Flash Installation Media]]. I think it should be merged too, what is your opinion?<br />
<br />
Otherwise I really like your work, keep up!<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:14, 21 November 2013 (UTC)<br />
<br />
I have changed the "Note" to point directly to the [[USB Flash Installation Media#BIOS and UEFI Bootable USB]]. The '''Remove UEFI boot support from ISO''' actually talks about removing CD/DVD UEFI boot support. I changed the title of that section to '''Remove UEFI CD boot support from ISO'''. <br />
<br />
To remove USB UEFI boot, you just have make sure <USB>/EFI/Boot/bootx64.efi (case-insensitive) file does not exist (simply delete or rename it, and the USB no longer supports UEFI boot). Setting up a USB drive to UEFI boot is much more easier and straight-forward compared to setting up a CD/DVD (or actually the ISO) (via the El-torito entry) to UEFI boot.<br />
<br />
-- [[User:The.ridikulus.rat|Keshav Padram Amburay]] ([[User talk:The.ridikulus.rat|talk]]) 18:08, 21 November 2013 (UTC)</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=283944Unified Extensible Firmware Interface2013-11-21T18:00:25Z<p>The.ridikulus.rat: The instructions are specific to removing UEFI CD/DVD boot support from ISO, not UEFI USB support removal</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== BIOS ==<br />
<br />
{{Merge|Arch Boot Process|Together with the introduction of [[#UEFI]], merge this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<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. BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order. Since very little can be achieved by a program that fits into the 440-byte boot code area, usually a common boot loader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel. See [[Arch Boot Process]] for more details.<br />
<br />
== UEFI ==<br />
<br />
{{Merge|Arch Boot Process|Together with [[#BIOS]], merge the introduction of this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<br />
<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 />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a UEFI Application corresponding to the EFI firmware bitness/architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use IA32 (32-bit) EFI are older (pre 2008) Apple Macs, some Intel Cloverfield ultrabooks and some older Intel Server boards 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 />
=== Boot Process under UEFI ===<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases.<br />
<br />
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk has to use MBR. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 vathpela's efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings. Upstream (http://linux.dell.com/git/efibootmgr.git) efibootmgr code does not support efivarfs. A fork of efibootmgr by Fedora's Peter Jones (vathpela) supports both efivarfs and sysfs-efivars. It is currently used in official core/{{Pkg|efibootmgr}} pkg and AUR pkg {{AUR|efibootmgr-pjones-git}} - https://github.com/vathpela/efibootmgr/tree/libefivars<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
* Upstream efibootmgr http://linux.dell.com/git/efibootmgr.git does not support efivarfs. However vathpela's efibootmgr supports efivarfs and is currently used in official efibootmgr pkg. sysfs-efivars is also completely disabled in official Arch kernel and it supports only efivarfs. This section is written with the assumtion that you are using only efivarfs and vathpela's efibootmgr.<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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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), modifyiang 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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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 CD boot support from ISO ===<br />
<br />
{{Warning|In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using a USB stick as mentioned [[USB Flash Installation Media#BIOS and UEFI Bootable USB|here]].}}<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. Then rebuild the ISO using ''xorriso'' from {{pkg|libisoburn}}:<br />
<br />
{{bc|1=<br />
# mount -o loop ''input_iso'' /mnt/iso<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 like a BAWSE" \<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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=283941Unified Extensible Firmware Interface2013-11-21T17:56:09Z<p>The.ridikulus.rat: /* Remove UEFI boot support from ISO */</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== BIOS ==<br />
<br />
{{Merge|Arch Boot Process|Together with the introduction of [[#UEFI]], merge this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<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. BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order. Since very little can be achieved by a program that fits into the 440-byte boot code area, usually a common boot loader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel. See [[Arch Boot Process]] for more details.<br />
<br />
== UEFI ==<br />
<br />
{{Merge|Arch Boot Process|Together with [[#BIOS]], merge the introduction of this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<br />
<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 />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a UEFI Application corresponding to the EFI firmware bitness/architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use IA32 (32-bit) EFI are older (pre 2008) Apple Macs, some Intel Cloverfield ultrabooks and some older Intel Server boards 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 />
=== Boot Process under UEFI ===<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases.<br />
<br />
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk has to use MBR. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 vathpela's efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings. Upstream (http://linux.dell.com/git/efibootmgr.git) efibootmgr code does not support efivarfs. A fork of efibootmgr by Fedora's Peter Jones (vathpela) supports both efivarfs and sysfs-efivars. It is currently used in official core/{{Pkg|efibootmgr}} pkg and AUR pkg {{AUR|efibootmgr-pjones-git}} - https://github.com/vathpela/efibootmgr/tree/libefivars<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
* Upstream efibootmgr http://linux.dell.com/git/efibootmgr.git does not support efivarfs. However vathpela's efibootmgr supports efivarfs and is currently used in official efibootmgr pkg. sysfs-efivars is also completely disabled in official Arch kernel and it supports only efivarfs. This section is written with the assumtion that you are using only efivarfs and vathpela's efibootmgr.<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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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), modifyiang 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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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 ISO ===<br />
<br />
{{Warning|In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using a USB stick as mentioned [[USB Flash Installation Media#BIOS and UEFI Bootable USB|here]].}}<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. Then rebuild the ISO using ''xorriso'' from {{pkg|libisoburn}}:<br />
<br />
{{bc|1=<br />
# mount -o loop ''input_iso'' /mnt/iso<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 like a BAWSE" \<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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=283881Unified Extensible Firmware Interface2013-11-21T09:43:28Z<p>The.ridikulus.rat: Add info for using grub instead of gummiboot in install isos due to efistub bug</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|GUID Partition Table}}<br />
{{Related articles end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "[[MBR]] boot code" method followed for [[Wikipedia:BIOS|BIOS]] systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0. As of 24 July 2013, UEFI Specification 2.4 (released July 11, 2013) is the most recent version.<br />
<br />
{{Note|<br />
* This page explains '''What is UEFI''' and '''UEFI support in Linux kernel'''. It does not describe setting up UEFI Boot Loaders. For that information see [[Boot Loaders]].<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, these instructions are general and some of them may not work or may be different in Apple Macs. 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.}}<br />
<br />
== BIOS ==<br />
<br />
{{Merge|Arch Boot Process|Together with the introduction of [[#UEFI]], merge this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<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. BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order. Since very little can be achieved by a program that fits into the 440-byte boot code area, usually a common boot loader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel. See [[Arch Boot Process]] for more details.<br />
<br />
== UEFI ==<br />
<br />
{{Merge|Arch Boot Process|Together with [[#BIOS]], merge the introduction of this section into [[Arch Boot Process]]. Leave only note like "See [[Arch Boot Process]] for description of differences between BIOS and UEFI." on this page.}}<br />
<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 />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a UEFI Application corresponding to the EFI firmware bitness/architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use IA32 (32-bit) EFI are older (pre 2008) Apple Macs, some Intel Cloverfield ultrabooks and some older Intel Server boards 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 />
=== Boot Process under UEFI ===<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware then reads its Boot Manager data to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware then launches the UEFI application as defined in the boot entry in the firmware's boot manager.<br />
# The launched UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a boot loader like GRUB) depending on how the UEFI application was configured.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it does not have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<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 Loaders|boot loader]] to load another to switch OSes.<br />
<br />
==== Booting Microsoft Windows ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using x86_64 EFI firmware. Windows forces type of partitioning depending on the firmware used, i.e. if Windows is booted in UEFI mode, it can be installed only to a GPT disk. If the Windows is booted in Legacy BIOS mode, it can be installed only to a MBR disk. This is a limitation enforced by Windows installer. Thus Windows supports either UEFI-GPT boot or BIOS-MBR boot only, not UEFI-MBR or BIOS-GPT boot. <br />
<br />
Such a limitation is not enforced by the Linux kernel, but can depend on how the bootloader is configured. The Windows limitation should be considered if the user wishes to boot Windows and Linux from the same disk, since setting up the bootloader itself depends on the firmware type and disk partitioning used. In case where Windows and Linux dual boot from the same disk, it is advisable to follow the method used by Windows, either go for UEFI-GPT boot or BIOS-MBR boot only, not the other two cases.<br />
<br />
32-bit Windows versions only support BIOS-MBR booting. So, in case of Linux and 32-bit Windows booting from the same disk, the disk has to use MBR. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
=== Detecting UEFI Firmware bitness ===<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 [[HCL/Firmwares/UEFI#Intel_Atom_System-on-Chip|this page]] 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.<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 2 interfaces:<br />
<br />
* '''OLD sysfs-efivars''' interface (CONFIG_EFI_VARS) - populated by {{ic|efivars}} kernel module at {{ic|/sys/firmware/efi/vars}} - 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support (due to the size limitation) and not recommended by kernel upstream anymore. Still supported by kernel upstream but '''completely disabled in Arch's official kernels'''.<br />
<br />
* '''NEW efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface (CONFIG_EFIVAR_FS) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - replacement for the OLD sysfs-efivars interface, has no maximum per-variable size limitation, supports UEFI Secure Boot variables and recommended by kernel upstream. Introduced in kernel 3.8 and NEW {{ic|efivarfs}} module split from OLD {{ic|efivars}} kernel module in kernel 3.10 .<br />
<br />
==== Inconsistency between efivarfs and sysfs-efivars ====<br />
<br />
Enabling both OLD sysfs-efivars and NEW efivarfs can cause data inconsistency issues (see See https://lkml.org/lkml/2013/4/16/473 for more info). Due to this OLD sysfs-efivars is completely disabled in Arch's official kernels (since '''core/{{Pkg|linux}}-3.11''' and '''core/{{Pkg|linux-lts}}-3.10''') and only NEW efivarfs is enabled/supported going forward. All the UEFI Variables related tools and utilities in [[official repositories]] support efivarfs as of 01 October 2013.<br />
<br />
{{Note|As a side-effect of disabling OLD sysfs-efivars, {{ic|efi_pstore}} module is also disabled in the official Arch kernels as EFI pstore functionality in the kernel depends of OLD sysfs-efivars support.}}<br />
<br />
If you have both interfaces enabled, you need to disable one of them, and disable and re-enable the other interface (to refresh the data, to prevent inconsistencies) before accessing the EFI VAR data using any userspace tool:<br />
<br />
To disable sysfs-efivars and refresh efivarfs:<br />
# modprobe -r efivars<br />
<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe efivarfs<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
To disable efivarfs and refresh sysfs-efivars:<br />
# umount /sys/firmware/efi/efivars<br />
# modprobe -r efivarfs<br />
<br />
# modprobe -r efivars<br />
# modprobe efivars<br />
<br />
=== Requirements for UEFI Variables support to work properly ===<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 bitness/arch and EFI processor bitness/arch 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. For sample output see [[#Sample_List_of_UEFI_Variables]].<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 />
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 Variable support to the userspace tools like {{ic|efibootmgr}} etc.:<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both OUTSIDE (BEFORE) and INSIDE '''chroot''', if any.}}<br />
<br />
It is also a good idea to auto-mount {{ic|efivarfs}} during boot via {{ic|/etc/fstab}} as follows:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 0<br />
</nowiki>}}<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 vathpela's efibootmgr) - https://github.com/vathpela/efivar - {{Pkg|efivar}} or {{AUR|efivar-git}}<br />
# '''efibootmgr''' - Tool to manipulate UEFI Firmware Boot Manager Settings. Upstream (http://linux.dell.com/git/efibootmgr.git) efibootmgr code does not support efivarfs. A fork of efibootmgr by Fedora's Peter Jones (vathpela) supports both efivarfs and sysfs-efivars. It is currently used in official core/{{Pkg|efibootmgr}} pkg and AUR pkg {{AUR|efibootmgr-pjones-git}} - https://github.com/vathpela/efibootmgr/tree/libefivars<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 to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - {{AUR|efitools-git}}<br />
# '''Ubuntu's Firmware Test Suite''' - https://wiki.ubuntu.com/FirmwareTestSuite/ - {{AUR|fwts}} (along with {{AUR|fwts-efi-runtime-dkms}}) or {{AUR|fwts-git}}<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|<br />
* Using {{ic|efibootmgr}} in Apple Macs may brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<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 BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI System Partition and manually enter the EFI stub location. (for example {{ic|\EFI\refind\refind_x64.efi}}).<br />
* The below commands use {{Pkg|refind-efi}} boot-loader as example.<br />
* Upstream efibootmgr http://linux.dell.com/git/efibootmgr.git does not support efivarfs. However vathpela's efibootmgr supports efivarfs and is currently used in official efibootmgr pkg. sysfs-efivars is also completely disabled in official Arch kernel and it supports only efivarfs. This section is written with the assumtion that you are using only efivarfs and vathpela's efibootmgr.<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 Variables support to work properly]] 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 />
== EFI System Partition ==<br />
<br />
The EFI System Partition (also called ESP or EFISYS) is a FAT32 formatted physical partition (in the main partition table of the disk, not LVM or software raid etc.) from where the UEFI firmware launches the UEFI bootloader and application. It is a OS independent partition that acts as the storage place for the EFI bootloaders and applications which the firmware launches them. It is mandatory for UEFI boot. It should be marked as '''EF00''' or '''ef00''' type code in gdisk, or '''boot''' flag in case of GNU Parted (only for GPT disk). It is recommended to keep ESP size at 512 MiB although smaller/larger sizes are fine (smaller sizes provided it is higher than the minimum FAT32 FS partition size limit (as mandated by FAT32 specification from Microsoft). For more info visit [[Wikipedia:EFI_System_partition|link]].<br />
<br />
{{Note|<br />
* It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* In GNU Parted, {{ic|boot}} flag (not to be confused with {{ic|legacy_boot}} flag) has different effect in MBR and GPT disk. In MBR disk, it marks the partition as active. In GPT disk, it changes the type code of the partition to {{ic|EFI System Partition}} type. Parted has no flag to mark a partition as ESP in MBR disk (this can be done using fdisk though).<br />
* Microsoft documentation noted the ESP size: For Advanced Format 4K Native drives (4-KB-per-sector) drives, the minimum size is 260 MB, due to a limitation of the FAT32 file format. The minimum partition size of FAT32 drives is calculated as sector size (4KB) x 65527 &#61; 256 MB. Advanced Format 512e drives are not affected by this limitation, because their emulated sector size is 512 bytes. 512 bytes x 65527 &#61; 32 MB, which is less than the 100 MB minimum size for this partition. From: http://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules<br />
* In case of [[EFISTUB]], the kernels and initramfs files should be stored in the EFI System Partition. For sake of simplicity, you can also use the ESP as the {{ic|/boot}} partition itself instead of a separate {{ic|/boot}} partition, for EFISTUB booting.<br />
}}<br />
<br />
=== GPT partitioned disks ===<br />
<br />
* Create a partition with partition type {{ic|ef00}} or {{ic|EF00}} using gdisk (from {{Pkg|gptfdisk}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}} <br />
(or)<br />
* Create a FAT32 partition and in GNU Parted set/activate the {{ic|boot}} flag (not {{ic|legacy_boot}} flag) on that partition<br />
<br />
{{Note|If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}, otherwise the partition may be unreadable by UEFI.}}<br />
<br />
=== MBR partitioned disks ===<br />
<br />
Create a partition with partition type {{ic|0xEF}} using fdisk (from {{Pkg|util-linux}} pkg). Then format that partition as FAT32 using {{ic|mkfs.fat -F32 /dev/<THAT_PARTITION>}}<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), modifyiang 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 />
<br />
* [[AUR]] '''{{AUR|uefi-shell-svn}}''' pkg (recommended) - provides x86_64 Shell in x86_64 system and IA32 Shell in i686 system - compiled directly from latest Tianocore EDK2 SVN source<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi Precompiled x86_64 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi Precompiled x86_64 UEFI Shell v1 binary] (not updated anymore upstream)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi Precompiled IA32 UEFI Shell v2 binary] (may not be up-to-date)<br />
* [https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi Precompiled IA32 UEFI Shell v1 binary] (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. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). 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 />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" PDF document.<br />
<br />
{{Note|<br />
* Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their 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 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 />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example 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 [[HCL/Firmwares/UEFI]] for the main article.<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 ISO ===<br />
<br />
{{Warning|In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using the USB stick instructions in the previous section}}<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 />
Rebuild the ISO using {{ic|xorriso}} from {{pkg|libisoburn}}:<br />
<br />
{{bc|<nowiki><br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "ARCH_201212" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared like a BAWSE" \<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 "~/archiso.iso" "/mnt/iso/"<br />
</nowiki>}}<br />
<br />
Burn {{ic|~/archiso.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 />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a tianocore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU.<br />
<br />
You can build OVMF (with Secure Boot support) from AUR {{AUR|ovmf-svn}} and run it as follows:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -net none -m 1024 -bios /usr/share/ovmf/x86_64/bios.bin <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 harddisk with GPT partitioning and still have a MBR partitioned harddisk in your computer, then it is possible that the UEFI BIOS is starting it's CSM support (for booting MBR partitions) and therefor Windows will not boot. To solve this merge your MBR harddisk to GPT partitioning or disable the SATA port where the MBR harddisk is plugged in or unplug the SATA connector from this harddisk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
Gigabyte Z77X-UD3H rev. 1.1 (UEFI BIOS version F19e)<br />
<br />
- UEFI BIOS option for booting UEFI Only does not pretend the UEFI BIOS from starting CSM<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 [https://bugs.archlinux.org/task/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 />
<br />
* Create USB Flash Installation drive as mentioned in [[USB_Flash_Installation_Media#BIOS_and_UEFI_Bootable_USB|link]]. After that follow the below steps to use GRUB instead of Gummiboot.<br />
<br />
* Backup {{ic|<USB>/EFI/boot/loader.efi}} to {{ic|<USB>/EFI/boot/gummiboot.efi}}<br />
<br />
* [[GRUB#GRUB_Standalone|Create a GRUB standalone image]] and copy it to {{ic|<USB>/EFI/boot/loader.efi}}<br />
<br />
* Create {{ic|<USB>/EFI/boot/grub.cfg}} with the following contents:<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 ARCHISO_XXXXXX<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCHISO_XXXXXX 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 ARCHISO_XXXXXX<br />
chainloader /EFI/shellx64_v2.efi<br />
}<br />
<br />
menuentry "UEFI Shell x86_64 v1" {<br />
search --no-floppy --set=root --label ARCHISO_XXXXXX<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 />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [[Wikipedia:EFI System partition]]<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.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<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://uefidk.intel.com/ Intel UEFI Community Resource Center]<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<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] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot 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 />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<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]<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]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=GRUB&diff=283877GRUB2013-11-21T09:13:49Z<p>The.ridikulus.rat: /* GRUB Standalone */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|Arch Boot Process}}<br />
{{Related|Boot Loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
<br />
[https://www.gnu.org/software/grub/ GRUB] - not to be confused with [[GRUB Legacy]] - is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} filesystem) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported filesystem.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
<br />
==== BIOS systems ====<br />
<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
GRUB in [[GPT|BIOS-GPT]] configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB). This partition is also not required if the system is UEFI based, as no embedding of bootsectors takes place in that case.<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no filesystem. The size of 1007 KiB will allow for the following partition to be correctly alligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
<br />
An EFI System Partition (ESP) is needed on every disc you wan to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Archlinux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it /dev/sda.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat filesystem and the 'boot' flag enabled. On it, there should be a folder called "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
<br />
=== BIOS systems ===<br />
<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
<br />
There are 3 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To setup {{ic|grub}} in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
Continue with [[#Generate config file]]. The GRUB config file is not generated by {{ic|grub-install}} command.<br />
<br />
===== Install to partition or partitionless disk =====<br />
<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that {{ic|grub}} relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix dir {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the filesystem in the partition is being altered (files copied, deleted etc.). For more info see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using chattr command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if {{ic|grub}} is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Continue with [[#Generate config file]]. The GRUB config file is not generated by {{ic|grub-install}} command.<br />
<br />
===== Generate core.img alone =====<br />
<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any {{ic|grub}} bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
<br />
===== Recommended method =====<br />
<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to boot using UEFI and not BIOS. If you booted by just copying the ISO file to the USB drive, you have booted using BIOS. You will need to [[Unified Extensible Firmware Interface#Create UEFI bootable USB from ISO|create a UEFI bootable USB device]] and reboot with it or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed. You may proceed to [[#Configuration|configuration]].<br />
<br />
===== Alternate method =====<br />
<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[Beginners' Guide#GRUB]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
<br />
{{Note|Using {{Aur|grub-git}} pkg is recommended over {{Pkg|grub}} as the latest -git contains some important grub-mkstandalone specific fixes (specifically 'cmdpath' support).}}<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows"<br />
<br />
# mkdir -p /tmp/boot/grub<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/boot/grub/grub.cfg ## use single quotes, ${cmdpath} should be present as it is<br />
# cd /tmp<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" -o "$esp/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg"<br />
<br />
The {{ic|grubx64_standalone.efi}} file expects {{ic|grub.cfg}} to be within its $prefix which is {{ic|(memdisk)/boot/grub}}. Hence we create a simple {{ic|(memdisk)/boot/grub/grub.cfg}} which redirects to {{ic|${cmdpath}/grub.cfg}} (ie. in the same dir as {{ic|grubx64_standalone.efi}}).<br />
<br />
The reason to {{ic|cd}} into {{ic|/tmp}} and to pass the file path as {{ic|boot/grub/grub.cfg}} (notice the lack of a leading slash - {{ic|boot/}} vs. {{ic|/boot/}} ) is because {{ic|dir1/dir2/file}} is included as {{ic|(memdisk)/dir1/dir2/file}} by the {{ic|grub-mkstandalone}} script.<br />
<br />
You need to create a UEFI Boot Manager entry for {{ic|$esp/EFI/arch_grub/grubx64_standalone.efi}} using {{ic|efibootmgr}}. Follow [[UEFI#efibootmgr]].<br />
<br />
{{Note|The {{ic|grubx64_standalone.efi}} looks for {{ic|grub.cfg}} in the same dir as it is located, not in {{ic|/boot/grub}}.}}<br />
<br />
== Generating main configuration file ==<br />
<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Configuration]] section.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path for BIOS systems is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* For EFI systems, if GRUB was installed with the {{ic|1=--boot-directory=$esp/EFI}} option set, the {{ic|grub.cfg}} file must be placed in the same directory as {{ic|grubx64.efi}}. Otherwise, the {{ic|grub.cfg}} file goes in {{ic|/boot/grub/}}, just like in BIOS systems.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. It can detect only systems on mounted partitions, so mount them before running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for eg: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
<br />
==== Disable framebuffer ====<br />
<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via filesystem UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant filesystem is resized or recreated. Remember this when modifying partitions & filesystems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} folder.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
<br />
{{Note|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more infos).<br />
<br />
'''/etc/grub.d/40_custom''':<br />
<br />
{{bc|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader (${root})/EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|<nowiki>drivemap -s hd0 hd2</nowiki>}}<br />
<br />
===== Windows Installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 x86_64 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$uuid}} are obtained with the following two commands. {{ic|$uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|bootmgr}}, not your "real" Windows partition (usually C:). When showing all UUIDs with blkid, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS filesystem of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
For Windows Vista/7/8:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting an ISO directly from GRUB ===<br />
<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
<br />
{{Note|The following examples assume the ISO is in {{ic|/archives}} on {{ic|hd0,6}}.}}<br />
{{Tip|For thumbdrives, use something like {{ic|(hd1,$partition)}} and either {{ic|/dev/sdb'''Y'''}} for the {{ic|img_dev}} parameter or [[Persistent block device naming|a persistent name]], e.g. {{ic|img_dev&#61;/dev/disk/by-label/CORSAIR}}.}}<br />
<br />
===== x86_64 =====<br />
<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
===== i686 =====<br />
<br />
menuentry "Archlinux-2013.05.01-dual.iso" --class iso {<br />
set isofile="/archives/archlinux-2013.05.01-dual.iso"<br />
set partition="6"<br />
loopback loop (hd0,$partition)/$isofile<br />
linux (loop)/arch/boot/i686/vmlinuz archisolabel=ARCH_201305 img_dev=/dev/sda$partition img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/i686/archiso.img<br />
}<br />
<br />
==== Ubuntu ISO ====<br />
<br />
{{Note|The example assumes that the iso is in {{ic|/archives}} on {{ic|hd0,6}}. Users must adjust the location and hdd/partition in the lines below to match their systems.}}<br />
<br />
menuentry "ubuntu-13.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-13.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/archives/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hd0,6)/$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<br />
<br />
=== LVM ===<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
<br />
It is possible to use labels, human-readable strings attached to filesystems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
<br />
{{hc|/etc/grub.d/00_header|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
<br />
grub> <br />
<br />
The GRUB's command shell environemnt can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Normal loading ====<br />
<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|kcm-grub2|This Kcm module manages the most common settings of GRUB|http://kde-apps.org/content/show.php?content&#61;137886|{{AUR|kcm-grub2}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod (hdX,Y)/boot/grub/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}} and {{ic|insmod (hdX,Y)/grub/linux.mod}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Bootloader installation]] for details.<br />
<br />
== Combining the use of UUIDs and basic scripting ==<br />
<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Intel BIOS not booting GPT ===<br />
<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
=== Enable debug messages ===<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=283875USB flash installation medium2013-11-21T08:44:49Z<p>The.ridikulus.rat: Fix Windows syslinux instructions</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:USB Installation Media]]<br />
[[bg:USB Installation Media]]<br />
[[de:Installation von einem USB-Stick]]<br />
[[es:USB Installation Media]]<br />
[[it:USB Installation Media]]<br />
[[ja:USB Installation Media]]<br />
[[ro:Instalare prin USB]]<br />
[[ru:USB Installation Media]]<br />
[[tr:USB_ile_kurulum]]<br />
[[zh-CN:USB Installation Media]]<br />
[[zh-TW:USB Installation Media]]<br />
{{Article summary start}}<br />
{{Article summary text|Mutiplatform instructions on creating a bootable USB stick which can be used for installing Arch Linux, system maintenance or for recovery purposes.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|CD Burning}}<br />
{{Article summary end}}<br />
<br />
This page discusses various methods on how to create a Arch Linux Installer USB drive (also referred to as ''"flash drive", "USB stick", "USB key"'', etc) for booting in BIOS and UEFI systems. The result will be a LiveUSB (LiveCD-like) system) that, because of the nature of [[Wikipedia:SquashFS|SquashFS]], will discard all changes once the computer shuts down.<br />
<br />
If you would like to run a full install of Arch Linux from a USB drive (i.e. with persistent settings), see [[Installing Arch Linux on a USB key]]. If you would like to use your bootable Arch Linux USB stick as a rescue USB, see [[Change Root]].<br />
<br />
== BIOS and UEFI Bootable USB ==<br />
<br />
{{Note|The instructions below are specifically for [[Archiso]]/official media; [[Archboot]] preparation is identical, without the filesystem LABEL/UUID requirement.}}<br />
<br />
=== Recommended Method - in GNU/Linux ===<br />
<br />
This method is slightly more complicated than writing the image directly with {{ic|dd}}, but it does keep the drive usable for data storage. Before you begin, make sure that your USB device is formatted as either FAT32. Also, make sure that you have the latest ''syslinux'' package (version 6.02 or newer) installed<br />
<br />
* [[Beginners_Guide#Prepare_the_storage_drive|First create a MBR (msdos) partition table with at least one partition, in the USB]] (it is fine to use an already partitioned USB).<br />
<br />
* Mount the ISO image:<br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2013.10.01-dual.iso /mnt/iso<br />
<br />
* Then create a FAT32 filesystem in the partition on the USB (unmount before, if necessary).<br />
<br />
* Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
# mount /dev/sd'''X'''1 /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}<br />
<br />
* Adjust the configuration files (necessary only for [[Archiso]], not needed for [[Archboot]] iso):<br />
<br />
{{Warning|Failure to label the drive "{{ic|ARCH_2013XX}}" (with the appropriate release month) or to use an [[UUID]] (to re-label it to whatever you like) '''will''' get you the infamous "30 seconds" error.}}<br />
<br />
Here's how you can replace the {{ic|1=archisolabel=ARCH_2013XX}} part with your equivalent of {{ic|1=archiso'''device'''=/dev/disk/by-uuid/47FA-4071}} for both config files at the same time, using a single command:<br />
<br />
{{Note|Adjust {{ic|/dev/sd'''X'''1}} before running it, else it will become blank (since drive {{ic|sd'''X'''}} doesn't exist).}}<br />
<br />
$ sed -i "s|label=ARCH_.*|device=/dev/disk/by-uuid/$(blkid -o value -s UUID /dev/sd'''X'''1)|" archiso_sys{32,64}.cfg<br />
<br />
* Install Syslinux to the USB by following [[Syslinux#Manual_install]]. Overwrite the existing syslinux modules ({{ic|*.c32}} files) present in the USB (from the ISO) with the ones from the Syslinux pkg to avoid version mismatch related boot failure.<br />
<br />
* Mark the USB partition as active by following [[Syslinux#MBR_partition_table]]<br />
<br />
=== Recommended Method - In Windows ===<br />
<br />
{{Note|<br />
* Do not use any '''Bootable USB Creator utility''' for creating the UEFI bootable USB. Do not use ''dd for Windows'' to dd the ISO to the USB drive.<br />
<br />
* In the below commands '''X:''' is assumed to be the USB flash drive in Windows.<br />
<br />
* Windows used backward slash {{ic|\}} as path-separator, so the same is used in the below commands.<br />
<br />
* All commands should be run in Windows command prompt '''as administrator'''.<br />
<br />
* {{ic|>}} denotes the Windows command prompt.<br />
}}<br />
<br />
* Partition and format the USB drive using [http://rufus.akeo.ie/ Rufus USB partitioner]. Select partition scheme option as '''MBR for BIOS and UEFI''' and File system as '''FAT32'''. Uncheck "Create a bootable disk using ISO image" and "Create extended label and icon files" options. Use <br />
<br />
* Change the '''Volume Label''' of the USB flash drive {{ic|X:}} to match the LABEL mentioned in {{ic|1=archisolabel=}} part in {{ic|<ISO>\loader\entries\archiso-x86_64.conf}}. This step is required for Official ISO ([[Archiso]]) but not required for [[Archboot]].<br />
<br />
* Extract the ISO (similar to extracting ZIP archive) to the USB flash drive (using [http://7-zip.org/ 7-Zip]. <br />
<br />
* Download latest official syslinux 6.xx binaries (zip file) from https://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract it.<br />
<br />
* Run the following command (in Windows cmd prompt, as admin) <br />
<br />
> cd bios\<br />
> for /r %Y in (*.c32) do copy "%Y" "X:\boot\syslinux\" /y<br />
> copy mbr\*.bin X:\boot\syslinux\ /y<br />
<br />
* Install Syslinux to the USB by running (use {{ic|win64/syslinux64.exe}} for x64 Windows):<br />
<br />
> cd bios\<br />
> win32/syslinux.exe -d /boot/syslinux -i -a -m X:<br />
<br />
{{Note|<br />
* The above step install Syslinux {{ic|ldlinux.sys}} to the USB partition VBR, sets the partition as active/boot in the MBR partition table and write the MBR boot code to the 1st 400-byte boot code region of the USB.<br />
<br />
* The {{ic|-d}} switch expects path with forward slash path-separator like in *unix systems.<br />
}}<br />
<br />
== BIOS-only USB using dd ==<br />
<br />
{{Warning|This will irrevocably destroy all data on {{ic|/dev/sd'''x'''}}.}}<br />
<br />
=== In GNU/Linux ===<br />
<br />
{{Tip|Check that the USB flash installation media is '''not''' mounted with {{ic|lsblk}}.}}<br />
<br />
{{Note|Use {{ic|/dev/sd'''x'''}} instead of {{ic|/dev/sd'''x1'''}}.}}<br />
<br />
# dd bs=4M if=/path/to/archlinux.iso of=/dev/sd'''x''' && sync<br />
<br />
=== In Windows ===<br />
<br />
==== Using Cygwin ====<br />
<br />
Make sure your [http://www.cygwin.com/ Cygwin] installation contains the {{ic|dd}} package.<br />
<br />
{{Tip|If you do not want to install Cygwin, you can download {{ic|dd}} for Windows from [http://www.chrysocome.net/dd here]. See the next section for more information.}}<br />
<br />
Place your image file in your home directory:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]: bs=4M<br />
<br />
where image.iso is the path to the iso image file within the {{ic|cygwin}} directory and {{ic|\\.\['''x''']}}: is your USB flash drive where '''x''' is the windows designated letter, e.g. {{ic|\\.\d:}}.<br />
<br />
On Cygwin 6.0 find out the correct partition with:<br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
{{Warning|This will irrevocably delete all files on your USB flash drive, so make sure you do not have any important files on the stick before doing this.}}<br />
<br />
dd if=image.iso of=/dev/sdb bs=4M<br />
<br />
==== dd for Windows ====<br />
<br />
{{Note|Some users have an "isolinux.bin missing or corrupt" problem when booting the media with this method.}}<br />
<br />
A GPL licensed dd version for Windows is available at http://www.chrysocome.net/dd. The advantage of this over Cygwin is a smaller download. Use it as shown in instructions for Cygwin above.<br />
<br />
To begin, download the latest version of dd for Windows. Once downloaded, extract the archive's contents into Downloads or elsewhere.<br />
<br />
Now, launch your {{ic|command prompt}} as an administrator. Next, change directory ({{ic|cd}}) into the Downloads directory.<br />
<br />
If your Arch Linux ISO is elsewhere you may need to state the full path, for convenience you may wish to put the Arch Linux ISO into the same folder as the dd executable. The basic format of the command will look like this.<br />
<br />
{{bc|<nowiki>dd if=archlinux-2013-XX-xx-dual.iso of=\\.\x: bs=4m</nowiki>}}<br />
{{Warning|This command will replace the drive's contents and its formatting with the ISO's. You will likely be unable to recover its contents in the event of an accidental copy. Be absolutely sure that you are directing dd to the correct drive before executing!}}<br />
Simply replace the various null spots (indicated by an "x") with the correct date and correct drive letter.<br />
<br />
Here is a complete example.<br />
{{bc|<nowiki>dd if=ISOs\archlinux-2013.08.01-dual.iso of=\\.\d: bs=4M</nowiki>}}<br />
<br />
=== In Mac OS X ===<br />
<br />
To be able to use {{ic|dd}} on your USB device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and in {{ic|Terminal.app}} run:<br />
<br />
$ diskutil list<br />
<br />
Figure out what your USB device is called with {{ic|mount}} or {{ic|<nowiki>sudo dmesg | tail</nowiki>}} (e.g. {{ic|/dev/disk1}}) and unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1):<br />
<br />
$ diskutil unmountDisk /dev/disk1<br />
<br />
Now we can continue in accordance with the instructions above (but use {{ic|1=bs=8192}} if you are using the OS X {{ic|dd}}, the number comes from {{ic|1024*8}}).<br />
<br />
{{hc|<nowiki>dd if=image.iso of=/dev/disk1 bs=8192</nowiki>|<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
}}<br />
<br />
It is probably a good idea to eject your drive before physical removal at this point:<br />
<br />
$ diskutil eject /dev/disk1<br />
<br />
=== How to restore the USB drive ===<br />
<br />
Because the ISO image is a hybrid which can either be burned to a disc or directly written to a USB drive, it doesn't include a standard partition table.<br />
<br />
After you install Arch Linux and you're done with the USB drive, you should zero out its first 512 bytes ''(meaning the boot code from the MBR and the non-standard partition table)'' if you want to restore it to full capacity:<br />
<br />
# dd count=1 bs=512 if=/dev/zero of=/dev/sd'''x''' && sync<br />
<br />
Then create a new partition table (e.g. "msdos") and filesystem (e.g. EXT4, FAT32) using {{Pkg|gparted}}, or from a terminal:<br />
<br />
* For EXT2/3/4 (adjust accordingly), it would be:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.ext4 /dev/sd'''x1'''<br />
# e2label /dev/sd'''x1''' USB_STICK<br />
<br />
* For FAT32, install the {{Pkg|dosfstools}} package and run:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.vfat -F32 /dev/sd'''x1'''<br />
# dosfslabel /dev/sd'''x1''' USB_STICK<br />
<br />
== Other Methods for BIOS systems ==<br />
<br />
=== In GNU/Linux ===<br />
<br />
==== Using UNetbootin ==== <br />
<br />
UNetbootin can be used on any Linux distribution or Windows to copy your iso to a USB device. However, Unetbootin overwrites syslinux.cfg, so it creates a USB device that does not boot properly. For this reason, '''Unetbootin is not recommended''' -- please use {{ic|dd}} or one of the other methods discussed in this topic.<br />
{{Warning|UNetbootin writes over the default {{ic|syslinux.cfg}}; this must be restored before the USB device will boot properly.}}<br />
<br />
Edit {{ic|syslinux.cfg}}:<br />
<br />
{{hc|sysconfig.cfg|2=<br />
default menu.c32<br />
prompt 0<br />
menu title Archlinux Installer<br />
timeout 100<br />
<br />
label unetbootindefault<br />
menu label Archlinux_x86_64<br />
kernel /arch/boot/x86_64/vmlinuz<br />
append initrd=/arch/boot/x86_64/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
<br />
label ubnentry0<br />
menu label Archlinux_i686<br />
kernel /arch/boot/i686/vmlinuz<br />
append initrd=/arch/boot/i686/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
}}<br />
<br />
In {{ic|/dev/sd'''x1'''}} you must replace '''x''' with the first free letter after the last letter in use on the system where you are installing Arch Linux (e.g. if you have two hard drives, use {{ic|c}}.). You can make this change during the first phase of boot by pressing {{ic|Tab}} when the menu is shown.<br />
<br />
=== In Windows ===<br />
<br />
==== Win32 Disk Imager ====<br />
<br />
{{Warning|This will destroy all information on your USB flash drive!}}<br />
First, download the program from [http://sourceforge.net/projects/win32diskimager/ here]. Next, extract the archive and run the executable. Now, select the Arch Linux ISO under the {{ic|Image File}} section and the USB flash device letter (for example, [D:\]) under the {{ic|Device}} section. Finally, click {{ic|Write}} when ready.<br />
{{Tip|By default, the Win32 Disk Imager's file-browser assumes disk image files end with a {{ic|.img}} extension. However, you can simply change the {{ic|Files of type}} drop-down list to {{ic|*.*}} and continue on to selecting your Arch Linux ISO.}}<br />
{{Note|After installation, you may need to restore the USB flash drive following a process as outlined [[USB_Installation_Media#How_to_restore_the_USB_drive|here]].}}<br />
<br />
==== USBWriter for Windows ====<br />
<br />
Download the program from http://sourceforge.net/projects/usbwriter/ and run it. Select the arch image file, the target USB stick, and click on the {{ic|write}} button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
==== The Flashnul way ====<br />
<br />
[http://shounen.ru/soft/flashnul/ flashnul] is an utility to verify the functionality and maintenance of Flash-Memory (USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash etc).<br />
<br />
From a command prompt, invoke flashnul with {{ic|-p}}, and determine which device index is your USB drive, e.g.:<br />
<br />
{{hc|C:\>flashnul -p|<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
}}<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, {{ic|-L}}, and the path to your image, e.g:<br />
<br />
C:\>flashnul '''E:''' -L ''path\to\arch.iso''<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
{{Note|Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64.}}<br />
<br />
==== Loading the installation media from RAM ====<br />
<br />
This method uses [[Syslinux]] and a [[Ramdisk]] ([http://www.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) to load the entire Arch Linux ISO image into RAM. Since this will be running entirely from system memory, you will need to make sure the system you will be installing this on has an adequate amount. A minimum amount of RAM between 500 MB and 1 GB should suffice for a MEMDISK based, Arch Linux install.<br />
<br />
For more information on Arch Linux system requirements as well as those for MEMDISK see the [[Beginners' Guide]] and [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries here].<br />
{{Tip|Once the installer has completed loading you can simply remove the USB stick and even use it on a different machine to start the process all over again. Utilizing MEMDISK also allows booting and installing Arch Linux to and from the same USB flash drive.}}<br />
<br />
===== Preparing the USB flash drive =====<br />
<br />
Begin by formatting the USB flash drive as '''FAT32'''. Then create the following folders on the newly formatted drive.<br />
* {{ic|Boot}}<br />
** {{ic|Boot/ISOs}}<br />
** {{ic|Boot/Settings}}<br />
<br />
===== Copy the needed files to the USB flash drive =====<br />
<br />
Next copy the ISO that you would like to boot to the {{ic|Boot/ISOs}} folder. After that, extract from the following files from the latest release of {{pkg|syslinux}} from [http://www.kernel.org/pub/linux/utils/boot/syslinux/ here] and copy them into the following folders.<br />
* {{ic|./win32/syslinux.exe}} to the Desktop or Downloads folder on your system.<br />
* {{ic|./memdisk/memdisk}} to the {{ic|Settings}} folder on your USB flash drive.<br />
<br />
===== Create the configuration file =====<br />
<br />
After copying the needed files, navigate to the USB flash drive, /boot/Settings and create a {{ic|syslinux.cfg}} file.<br />
{{Warning|On the {{ic|INITRD}} line, be sure to use the name of the ISO file that you copied to your {{ic|ISOs}} folder!}}<br />
{{hc|/Boot/Settings/syslinux.cfg|2=<br />
DEFAULT arch_iso<br />
<br />
LABEL arch_iso<br />
MENU LABEL Arch Setup<br />
LINUX memdisk<br />
INITRD /Boot/ISOs/archlinux-2013.08.01-dual.iso<br />
APPEND iso}}<br />
For more information on Syslinux see the [[Syslinux|Arch Wiki article]].<br />
<br />
===== Final steps =====<br />
<br />
Finally, create a {{ic|*.bat}} file where {{ic|syslinux.exe}} is located and run it ("Run as administrator" if you're on Vista or Windows 7):<br />
{{hc|C:\Documents and Settings\username\Desktop\install.bat|<br />
@echo off<br />
syslinux.exe -m -a -d /Boot/Settings X:}}<br />
<br />
==== Universal USB Installer ====<br />
<br />
The Windows tool [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/] can be used to quickly create a Live USB media with multiple Installers of many Linux distros. Once created, Installers can be added or removed without reformatting the USB drive.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Note|For the [[#Boot the entire ISO from RAM|MEMDISK Method]], if you get the famous "30 seconds" error trying to boot the i686 version, press the {{ic|Tab}} key over the {{ic|Boot Arch Linux (i686)}} entry and add {{ic|vmalloc&#61;448M}} at the end. For reference: ''If your image is bigger than 128MiB and you have a 32-bit OS, then you have to increase the maximum memory usage of vmalloc''. [http://www.syslinux.org/wiki/index.php/MEMDISK#-_memdiskfind_in_combination_with_phram_and_mtdblock (*)]}}<br />
<br />
{{Note|If you get the "30 seconds" error due to the {{ic|/dev/disk/by-label/ARCH_XXXXXX}} not mounting, try renaming your USB media to {{ic|ARCH_XXXXXX}} (e.g. {{ic|ARCH_201302}}).}}<br />
<br />
== See Also ==<br />
<br />
* [http://www.gentoo.org/doc/en/liveusb.xml Gentoo liveusb document]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=283873USB flash installation medium2013-11-21T08:18:59Z<p>The.ridikulus.rat: /* Recommended Method - In Windows */</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:USB Installation Media]]<br />
[[bg:USB Installation Media]]<br />
[[de:Installation von einem USB-Stick]]<br />
[[es:USB Installation Media]]<br />
[[it:USB Installation Media]]<br />
[[ja:USB Installation Media]]<br />
[[ro:Instalare prin USB]]<br />
[[ru:USB Installation Media]]<br />
[[tr:USB_ile_kurulum]]<br />
[[zh-CN:USB Installation Media]]<br />
[[zh-TW:USB Installation Media]]<br />
{{Article summary start}}<br />
{{Article summary text|Mutiplatform instructions on creating a bootable USB stick which can be used for installing Arch Linux, system maintenance or for recovery purposes.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|CD Burning}}<br />
{{Article summary end}}<br />
<br />
This page discusses various methods on how to create a Arch Linux Installer USB drive (also referred to as ''"flash drive", "USB stick", "USB key"'', etc) for booting in BIOS and UEFI systems. The result will be a LiveUSB (LiveCD-like) system) that, because of the nature of [[Wikipedia:SquashFS|SquashFS]], will discard all changes once the computer shuts down.<br />
<br />
If you would like to run a full install of Arch Linux from a USB drive (i.e. with persistent settings), see [[Installing Arch Linux on a USB key]]. If you would like to use your bootable Arch Linux USB stick as a rescue USB, see [[Change Root]].<br />
<br />
== BIOS and UEFI Bootable USB ==<br />
<br />
{{Note|The instructions below are specifically for [[Archiso]]/official media; [[Archboot]] preparation is identical, without the filesystem LABEL/UUID requirement.}}<br />
<br />
=== Recommended Method - in GNU/Linux ===<br />
<br />
This method is slightly more complicated than writing the image directly with {{ic|dd}}, but it does keep the drive usable for data storage. Before you begin, make sure that your USB device is formatted as either FAT32. Also, make sure that you have the latest ''syslinux'' package (version 6.02 or newer) installed<br />
<br />
* [[Beginners_Guide#Prepare_the_storage_drive|First create a MBR (msdos) partition table with at least one partition, in the USB]] (it is fine to use an already partitioned USB).<br />
<br />
* Mount the ISO image:<br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2013.10.01-dual.iso /mnt/iso<br />
<br />
* Then create a FAT32 filesystem in the partition on the USB (unmount before, if necessary).<br />
<br />
* Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
# mount /dev/sd'''X'''1 /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}<br />
<br />
* Adjust the configuration files (necessary only for [[Archiso]], not needed for [[Archboot]] iso):<br />
<br />
{{Warning|Failure to label the drive "{{ic|ARCH_2013XX}}" (with the appropriate release month) or to use an [[UUID]] (to re-label it to whatever you like) '''will''' get you the infamous "30 seconds" error.}}<br />
<br />
Here's how you can replace the {{ic|1=archisolabel=ARCH_2013XX}} part with your equivalent of {{ic|1=archiso'''device'''=/dev/disk/by-uuid/47FA-4071}} for both config files at the same time, using a single command:<br />
<br />
{{Note|Adjust {{ic|/dev/sd'''X'''1}} before running it, else it will become blank (since drive {{ic|sd'''X'''}} doesn't exist).}}<br />
<br />
$ sed -i "s|label=ARCH_.*|device=/dev/disk/by-uuid/$(blkid -o value -s UUID /dev/sd'''X'''1)|" archiso_sys{32,64}.cfg<br />
<br />
* Install Syslinux to the USB by following [[Syslinux#Manual_install]]. Overwrite the existing syslinux modules ({{ic|*.c32}} files) present in the USB (from the ISO) with the ones from the Syslinux pkg to avoid version mismatch related boot failure.<br />
<br />
* Mark the USB partition as active by following [[Syslinux#MBR_partition_table]]<br />
<br />
=== Recommended Method - In Windows ===<br />
<br />
{{Note|<br />
* Do not use any '''Bootable USB Creator utility''' for creating the UEFI bootable USB. Do not use ''dd for Windows'' to dd the ISO to the USB drive.<br />
<br />
* In the below commands {{ic|X:}} is assumed to be the USB flash drive in Windows.<br />
<br />
* Windows used backward slash {{ic|\}} as path-separator, so the same is used in the below commands.<br />
}}<br />
<br />
* Partition and format the USB drive using [http://rufus.akeo.ie/ Rufus USB partitioner]. Select partition scheme option as '''MBR for BIOS and UEFI''' and File system as '''FAT32'''. Uncheck "Create a bootable disk using ISO image" and "Create extended label and icon files" options. Use '''Volume Label''' of the USB drive (in Rufus) to match the LABEL mentioned in {{ic|1=archisolabel=}} part in {{ic|<ISO>\loader\entries\archiso-x86_64.conf}}. <br />
<br />
{{Note|The '''Volume Label''' step is required for Official ISO (archiso) only, not required for [[Archboot]].}}<br />
<br />
* Extract the ISO (similar to extracting ZIP archive) to the USB flash drive (using [http://7-zip.org/ 7-Zip]. <br />
<br />
* Download latest official syslinux 6.xx binaries (zip file) from https://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract it.<br />
<br />
* Go to {{ic|syslinux-<version>\bios}} directory, and copy all the {{ic|*.c32}} inside all the sub-directories, to {{ic|X:\boot\syslinux\}}.<br />
<br />
* Install Syslinux to the USB by running (in Windows cmd prompt) (use {{ic|bios/win64/syslinux64.exe}} for x64 Windows):<br />
<br />
bios/win32/syslinux.exe -d /boot/syslinux -m -a -i X:<br />
<br />
{{Note|<br />
* The above step install Syslinux {{ic|ldlinux.sys}} to the USB partition VBR, sets the partition as active/boot in the MBR partition table and write the MBR boot code to the 1st 400-byte boot code region of the USB.<br />
<br />
* The {{ic|-d}} switch expects path with forward slash path-separator like in *unix systems.<br />
}}<br />
<br />
== BIOS-only USB using dd ==<br />
<br />
{{Warning|This will irrevocably destroy all data on {{ic|/dev/sd'''x'''}}.}}<br />
<br />
=== In GNU/Linux ===<br />
<br />
{{Tip|Check that the USB flash installation media is '''not''' mounted with {{ic|lsblk}}.}}<br />
<br />
{{Note|Use {{ic|/dev/sd'''x'''}} instead of {{ic|/dev/sd'''x1'''}}.}}<br />
<br />
# dd bs=4M if=/path/to/archlinux.iso of=/dev/sd'''x''' && sync<br />
<br />
=== In Windows ===<br />
<br />
==== Using Cygwin ====<br />
<br />
Make sure your [http://www.cygwin.com/ Cygwin] installation contains the {{ic|dd}} package.<br />
<br />
{{Tip|If you do not want to install Cygwin, you can download {{ic|dd}} for Windows from [http://www.chrysocome.net/dd here]. See the next section for more information.}}<br />
<br />
Place your image file in your home directory:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]: bs=4M<br />
<br />
where image.iso is the path to the iso image file within the {{ic|cygwin}} directory and {{ic|\\.\['''x''']}}: is your USB flash drive where '''x''' is the windows designated letter, e.g. {{ic|\\.\d:}}.<br />
<br />
On Cygwin 6.0 find out the correct partition with:<br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
{{Warning|This will irrevocably delete all files on your USB flash drive, so make sure you do not have any important files on the stick before doing this.}}<br />
<br />
dd if=image.iso of=/dev/sdb bs=4M<br />
<br />
==== dd for Windows ====<br />
<br />
{{Note|Some users have an "isolinux.bin missing or corrupt" problem when booting the media with this method.}}<br />
<br />
A GPL licensed dd version for Windows is available at http://www.chrysocome.net/dd. The advantage of this over Cygwin is a smaller download. Use it as shown in instructions for Cygwin above.<br />
<br />
To begin, download the latest version of dd for Windows. Once downloaded, extract the archive's contents into Downloads or elsewhere.<br />
<br />
Now, launch your {{ic|command prompt}} as an administrator. Next, change directory ({{ic|cd}}) into the Downloads directory.<br />
<br />
If your Arch Linux ISO is elsewhere you may need to state the full path, for convenience you may wish to put the Arch Linux ISO into the same folder as the dd executable. The basic format of the command will look like this.<br />
<br />
{{bc|<nowiki>dd if=archlinux-2013-XX-xx-dual.iso of=\\.\x: bs=4m</nowiki>}}<br />
{{Warning|This command will replace the drive's contents and its formatting with the ISO's. You will likely be unable to recover its contents in the event of an accidental copy. Be absolutely sure that you are directing dd to the correct drive before executing!}}<br />
Simply replace the various null spots (indicated by an "x") with the correct date and correct drive letter.<br />
<br />
Here is a complete example.<br />
{{bc|<nowiki>dd if=ISOs\archlinux-2013.08.01-dual.iso of=\\.\d: bs=4M</nowiki>}}<br />
<br />
=== In Mac OS X ===<br />
<br />
To be able to use {{ic|dd}} on your USB device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and in {{ic|Terminal.app}} run:<br />
<br />
$ diskutil list<br />
<br />
Figure out what your USB device is called with {{ic|mount}} or {{ic|<nowiki>sudo dmesg | tail</nowiki>}} (e.g. {{ic|/dev/disk1}}) and unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1):<br />
<br />
$ diskutil unmountDisk /dev/disk1<br />
<br />
Now we can continue in accordance with the instructions above (but use {{ic|1=bs=8192}} if you are using the OS X {{ic|dd}}, the number comes from {{ic|1024*8}}).<br />
<br />
{{hc|<nowiki>dd if=image.iso of=/dev/disk1 bs=8192</nowiki>|<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
}}<br />
<br />
It is probably a good idea to eject your drive before physical removal at this point:<br />
<br />
$ diskutil eject /dev/disk1<br />
<br />
=== How to restore the USB drive ===<br />
<br />
Because the ISO image is a hybrid which can either be burned to a disc or directly written to a USB drive, it doesn't include a standard partition table.<br />
<br />
After you install Arch Linux and you're done with the USB drive, you should zero out its first 512 bytes ''(meaning the boot code from the MBR and the non-standard partition table)'' if you want to restore it to full capacity:<br />
<br />
# dd count=1 bs=512 if=/dev/zero of=/dev/sd'''x''' && sync<br />
<br />
Then create a new partition table (e.g. "msdos") and filesystem (e.g. EXT4, FAT32) using {{Pkg|gparted}}, or from a terminal:<br />
<br />
* For EXT2/3/4 (adjust accordingly), it would be:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.ext4 /dev/sd'''x1'''<br />
# e2label /dev/sd'''x1''' USB_STICK<br />
<br />
* For FAT32, install the {{Pkg|dosfstools}} package and run:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.vfat -F32 /dev/sd'''x1'''<br />
# dosfslabel /dev/sd'''x1''' USB_STICK<br />
<br />
== Other Methods for BIOS systems ==<br />
<br />
=== In GNU/Linux ===<br />
<br />
==== Using UNetbootin ==== <br />
<br />
UNetbootin can be used on any Linux distribution or Windows to copy your iso to a USB device. However, Unetbootin overwrites syslinux.cfg, so it creates a USB device that does not boot properly. For this reason, '''Unetbootin is not recommended''' -- please use {{ic|dd}} or one of the other methods discussed in this topic.<br />
{{Warning|UNetbootin writes over the default {{ic|syslinux.cfg}}; this must be restored before the USB device will boot properly.}}<br />
<br />
Edit {{ic|syslinux.cfg}}:<br />
<br />
{{hc|sysconfig.cfg|2=<br />
default menu.c32<br />
prompt 0<br />
menu title Archlinux Installer<br />
timeout 100<br />
<br />
label unetbootindefault<br />
menu label Archlinux_x86_64<br />
kernel /arch/boot/x86_64/vmlinuz<br />
append initrd=/arch/boot/x86_64/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
<br />
label ubnentry0<br />
menu label Archlinux_i686<br />
kernel /arch/boot/i686/vmlinuz<br />
append initrd=/arch/boot/i686/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
}}<br />
<br />
In {{ic|/dev/sd'''x1'''}} you must replace '''x''' with the first free letter after the last letter in use on the system where you are installing Arch Linux (e.g. if you have two hard drives, use {{ic|c}}.). You can make this change during the first phase of boot by pressing {{ic|Tab}} when the menu is shown.<br />
<br />
=== In Windows ===<br />
<br />
==== Win32 Disk Imager ====<br />
<br />
{{Warning|This will destroy all information on your USB flash drive!}}<br />
First, download the program from [http://sourceforge.net/projects/win32diskimager/ here]. Next, extract the archive and run the executable. Now, select the Arch Linux ISO under the {{ic|Image File}} section and the USB flash device letter (for example, [D:\]) under the {{ic|Device}} section. Finally, click {{ic|Write}} when ready.<br />
{{Tip|By default, the Win32 Disk Imager's file-browser assumes disk image files end with a {{ic|.img}} extension. However, you can simply change the {{ic|Files of type}} drop-down list to {{ic|*.*}} and continue on to selecting your Arch Linux ISO.}}<br />
{{Note|After installation, you may need to restore the USB flash drive following a process as outlined [[USB_Installation_Media#How_to_restore_the_USB_drive|here]].}}<br />
<br />
==== USBWriter for Windows ====<br />
<br />
Download the program from http://sourceforge.net/projects/usbwriter/ and run it. Select the arch image file, the target USB stick, and click on the {{ic|write}} button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
==== The Flashnul way ====<br />
<br />
[http://shounen.ru/soft/flashnul/ flashnul] is an utility to verify the functionality and maintenance of Flash-Memory (USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash etc).<br />
<br />
From a command prompt, invoke flashnul with {{ic|-p}}, and determine which device index is your USB drive, e.g.:<br />
<br />
{{hc|C:\>flashnul -p|<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
}}<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, {{ic|-L}}, and the path to your image, e.g:<br />
<br />
C:\>flashnul '''E:''' -L ''path\to\arch.iso''<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
{{Note|Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64.}}<br />
<br />
==== Loading the installation media from RAM ====<br />
<br />
This method uses [[Syslinux]] and a [[Ramdisk]] ([http://www.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) to load the entire Arch Linux ISO image into RAM. Since this will be running entirely from system memory, you will need to make sure the system you will be installing this on has an adequate amount. A minimum amount of RAM between 500 MB and 1 GB should suffice for a MEMDISK based, Arch Linux install.<br />
<br />
For more information on Arch Linux system requirements as well as those for MEMDISK see the [[Beginners' Guide]] and [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries here].<br />
{{Tip|Once the installer has completed loading you can simply remove the USB stick and even use it on a different machine to start the process all over again. Utilizing MEMDISK also allows booting and installing Arch Linux to and from the same USB flash drive.}}<br />
<br />
===== Preparing the USB flash drive =====<br />
<br />
Begin by formatting the USB flash drive as '''FAT32'''. Then create the following folders on the newly formatted drive.<br />
* {{ic|Boot}}<br />
** {{ic|Boot/ISOs}}<br />
** {{ic|Boot/Settings}}<br />
<br />
===== Copy the needed files to the USB flash drive =====<br />
<br />
Next copy the ISO that you would like to boot to the {{ic|Boot/ISOs}} folder. After that, extract from the following files from the latest release of {{pkg|syslinux}} from [http://www.kernel.org/pub/linux/utils/boot/syslinux/ here] and copy them into the following folders.<br />
* {{ic|./win32/syslinux.exe}} to the Desktop or Downloads folder on your system.<br />
* {{ic|./memdisk/memdisk}} to the {{ic|Settings}} folder on your USB flash drive.<br />
<br />
===== Create the configuration file =====<br />
<br />
After copying the needed files, navigate to the USB flash drive, /boot/Settings and create a {{ic|syslinux.cfg}} file.<br />
{{Warning|On the {{ic|INITRD}} line, be sure to use the name of the ISO file that you copied to your {{ic|ISOs}} folder!}}<br />
{{hc|/Boot/Settings/syslinux.cfg|2=<br />
DEFAULT arch_iso<br />
<br />
LABEL arch_iso<br />
MENU LABEL Arch Setup<br />
LINUX memdisk<br />
INITRD /Boot/ISOs/archlinux-2013.08.01-dual.iso<br />
APPEND iso}}<br />
For more information on Syslinux see the [[Syslinux|Arch Wiki article]].<br />
<br />
===== Final steps =====<br />
<br />
Finally, create a {{ic|*.bat}} file where {{ic|syslinux.exe}} is located and run it ("Run as administrator" if you're on Vista or Windows 7):<br />
{{hc|C:\Documents and Settings\username\Desktop\install.bat|<br />
@echo off<br />
syslinux.exe -m -a -d /Boot/Settings X:}}<br />
<br />
==== Universal USB Installer ====<br />
<br />
The Windows tool [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/] can be used to quickly create a Live USB media with multiple Installers of many Linux distros. Once created, Installers can be added or removed without reformatting the USB drive.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Note|For the [[#Boot the entire ISO from RAM|MEMDISK Method]], if you get the famous "30 seconds" error trying to boot the i686 version, press the {{ic|Tab}} key over the {{ic|Boot Arch Linux (i686)}} entry and add {{ic|vmalloc&#61;448M}} at the end. For reference: ''If your image is bigger than 128MiB and you have a 32-bit OS, then you have to increase the maximum memory usage of vmalloc''. [http://www.syslinux.org/wiki/index.php/MEMDISK#-_memdiskfind_in_combination_with_phram_and_mtdblock (*)]}}<br />
<br />
{{Note|If you get the "30 seconds" error due to the {{ic|/dev/disk/by-label/ARCH_XXXXXX}} not mounting, try renaming your USB media to {{ic|ARCH_XXXXXX}} (e.g. {{ic|ARCH_201302}}).}}<br />
<br />
== See Also ==<br />
<br />
* [http://www.gentoo.org/doc/en/liveusb.xml Gentoo liveusb document]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=283872USB flash installation medium2013-11-21T08:18:47Z<p>The.ridikulus.rat: /* Recommended Method - In Windows */</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:USB Installation Media]]<br />
[[bg:USB Installation Media]]<br />
[[de:Installation von einem USB-Stick]]<br />
[[es:USB Installation Media]]<br />
[[it:USB Installation Media]]<br />
[[ja:USB Installation Media]]<br />
[[ro:Instalare prin USB]]<br />
[[ru:USB Installation Media]]<br />
[[tr:USB_ile_kurulum]]<br />
[[zh-CN:USB Installation Media]]<br />
[[zh-TW:USB Installation Media]]<br />
{{Article summary start}}<br />
{{Article summary text|Mutiplatform instructions on creating a bootable USB stick which can be used for installing Arch Linux, system maintenance or for recovery purposes.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|CD Burning}}<br />
{{Article summary end}}<br />
<br />
This page discusses various methods on how to create a Arch Linux Installer USB drive (also referred to as ''"flash drive", "USB stick", "USB key"'', etc) for booting in BIOS and UEFI systems. The result will be a LiveUSB (LiveCD-like) system) that, because of the nature of [[Wikipedia:SquashFS|SquashFS]], will discard all changes once the computer shuts down.<br />
<br />
If you would like to run a full install of Arch Linux from a USB drive (i.e. with persistent settings), see [[Installing Arch Linux on a USB key]]. If you would like to use your bootable Arch Linux USB stick as a rescue USB, see [[Change Root]].<br />
<br />
== BIOS and UEFI Bootable USB ==<br />
<br />
{{Note|The instructions below are specifically for [[Archiso]]/official media; [[Archboot]] preparation is identical, without the filesystem LABEL/UUID requirement.}}<br />
<br />
=== Recommended Method - in GNU/Linux ===<br />
<br />
This method is slightly more complicated than writing the image directly with {{ic|dd}}, but it does keep the drive usable for data storage. Before you begin, make sure that your USB device is formatted as either FAT32. Also, make sure that you have the latest ''syslinux'' package (version 6.02 or newer) installed<br />
<br />
* [[Beginners_Guide#Prepare_the_storage_drive|First create a MBR (msdos) partition table with at least one partition, in the USB]] (it is fine to use an already partitioned USB).<br />
<br />
* Mount the ISO image:<br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2013.10.01-dual.iso /mnt/iso<br />
<br />
* Then create a FAT32 filesystem in the partition on the USB (unmount before, if necessary).<br />
<br />
* Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
# mount /dev/sd'''X'''1 /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}<br />
<br />
* Adjust the configuration files (necessary only for [[Archiso]], not needed for [[Archboot]] iso):<br />
<br />
{{Warning|Failure to label the drive "{{ic|ARCH_2013XX}}" (with the appropriate release month) or to use an [[UUID]] (to re-label it to whatever you like) '''will''' get you the infamous "30 seconds" error.}}<br />
<br />
Here's how you can replace the {{ic|1=archisolabel=ARCH_2013XX}} part with your equivalent of {{ic|1=archiso'''device'''=/dev/disk/by-uuid/47FA-4071}} for both config files at the same time, using a single command:<br />
<br />
{{Note|Adjust {{ic|/dev/sd'''X'''1}} before running it, else it will become blank (since drive {{ic|sd'''X'''}} doesn't exist).}}<br />
<br />
$ sed -i "s|label=ARCH_.*|device=/dev/disk/by-uuid/$(blkid -o value -s UUID /dev/sd'''X'''1)|" archiso_sys{32,64}.cfg<br />
<br />
* Install Syslinux to the USB by following [[Syslinux#Manual_install]]. Overwrite the existing syslinux modules ({{ic|*.c32}} files) present in the USB (from the ISO) with the ones from the Syslinux pkg to avoid version mismatch related boot failure.<br />
<br />
* Mark the USB partition as active by following [[Syslinux#MBR_partition_table]]<br />
<br />
=== Recommended Method - In Windows ===<br />
<br />
{{Note|<br />
* Do not use any '''Bootable USB Creator utility''' for creating the UEFI bootable USB. Do not use ''dd for Windows'' to dd the ISO to the USB drive.}}<br />
<br />
* In the below commands {{ic|X:}} is assumed to be the USB flash drive in Windows.<br />
<br />
* Windows used backward slash {{ic|\}} as path-separator, so the same is used in the below commands.<br />
}}<br />
<br />
* Partition and format the USB drive using [http://rufus.akeo.ie/ Rufus USB partitioner]. Select partition scheme option as '''MBR for BIOS and UEFI''' and File system as '''FAT32'''. Uncheck "Create a bootable disk using ISO image" and "Create extended label and icon files" options. Use '''Volume Label''' of the USB drive (in Rufus) to match the LABEL mentioned in {{ic|1=archisolabel=}} part in {{ic|<ISO>\loader\entries\archiso-x86_64.conf}}. <br />
<br />
{{Note|The '''Volume Label''' step is required for Official ISO (archiso) only, not required for [[Archboot]].}}<br />
<br />
* Extract the ISO (similar to extracting ZIP archive) to the USB flash drive (using [http://7-zip.org/ 7-Zip]. <br />
<br />
* Download latest official syslinux 6.xx binaries (zip file) from https://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract it.<br />
<br />
* Go to {{ic|syslinux-<version>\bios}} directory, and copy all the {{ic|*.c32}} inside all the sub-directories, to {{ic|X:\boot\syslinux\}}.<br />
<br />
* Install Syslinux to the USB by running (in Windows cmd prompt) (use {{ic|bios/win64/syslinux64.exe}} for x64 Windows):<br />
<br />
bios/win32/syslinux.exe -d /boot/syslinux -m -a -i X:<br />
<br />
{{Note|<br />
* The above step install Syslinux {{ic|ldlinux.sys}} to the USB partition VBR, sets the partition as active/boot in the MBR partition table and write the MBR boot code to the 1st 400-byte boot code region of the USB.<br />
<br />
* The {{ic|-d}} switch expects path with forward slash path-separator like in *unix systems.<br />
}}<br />
<br />
== BIOS-only USB using dd ==<br />
<br />
{{Warning|This will irrevocably destroy all data on {{ic|/dev/sd'''x'''}}.}}<br />
<br />
=== In GNU/Linux ===<br />
<br />
{{Tip|Check that the USB flash installation media is '''not''' mounted with {{ic|lsblk}}.}}<br />
<br />
{{Note|Use {{ic|/dev/sd'''x'''}} instead of {{ic|/dev/sd'''x1'''}}.}}<br />
<br />
# dd bs=4M if=/path/to/archlinux.iso of=/dev/sd'''x''' && sync<br />
<br />
=== In Windows ===<br />
<br />
==== Using Cygwin ====<br />
<br />
Make sure your [http://www.cygwin.com/ Cygwin] installation contains the {{ic|dd}} package.<br />
<br />
{{Tip|If you do not want to install Cygwin, you can download {{ic|dd}} for Windows from [http://www.chrysocome.net/dd here]. See the next section for more information.}}<br />
<br />
Place your image file in your home directory:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]: bs=4M<br />
<br />
where image.iso is the path to the iso image file within the {{ic|cygwin}} directory and {{ic|\\.\['''x''']}}: is your USB flash drive where '''x''' is the windows designated letter, e.g. {{ic|\\.\d:}}.<br />
<br />
On Cygwin 6.0 find out the correct partition with:<br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
{{Warning|This will irrevocably delete all files on your USB flash drive, so make sure you do not have any important files on the stick before doing this.}}<br />
<br />
dd if=image.iso of=/dev/sdb bs=4M<br />
<br />
==== dd for Windows ====<br />
<br />
{{Note|Some users have an "isolinux.bin missing or corrupt" problem when booting the media with this method.}}<br />
<br />
A GPL licensed dd version for Windows is available at http://www.chrysocome.net/dd. The advantage of this over Cygwin is a smaller download. Use it as shown in instructions for Cygwin above.<br />
<br />
To begin, download the latest version of dd for Windows. Once downloaded, extract the archive's contents into Downloads or elsewhere.<br />
<br />
Now, launch your {{ic|command prompt}} as an administrator. Next, change directory ({{ic|cd}}) into the Downloads directory.<br />
<br />
If your Arch Linux ISO is elsewhere you may need to state the full path, for convenience you may wish to put the Arch Linux ISO into the same folder as the dd executable. The basic format of the command will look like this.<br />
<br />
{{bc|<nowiki>dd if=archlinux-2013-XX-xx-dual.iso of=\\.\x: bs=4m</nowiki>}}<br />
{{Warning|This command will replace the drive's contents and its formatting with the ISO's. You will likely be unable to recover its contents in the event of an accidental copy. Be absolutely sure that you are directing dd to the correct drive before executing!}}<br />
Simply replace the various null spots (indicated by an "x") with the correct date and correct drive letter.<br />
<br />
Here is a complete example.<br />
{{bc|<nowiki>dd if=ISOs\archlinux-2013.08.01-dual.iso of=\\.\d: bs=4M</nowiki>}}<br />
<br />
=== In Mac OS X ===<br />
<br />
To be able to use {{ic|dd}} on your USB device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and in {{ic|Terminal.app}} run:<br />
<br />
$ diskutil list<br />
<br />
Figure out what your USB device is called with {{ic|mount}} or {{ic|<nowiki>sudo dmesg | tail</nowiki>}} (e.g. {{ic|/dev/disk1}}) and unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1):<br />
<br />
$ diskutil unmountDisk /dev/disk1<br />
<br />
Now we can continue in accordance with the instructions above (but use {{ic|1=bs=8192}} if you are using the OS X {{ic|dd}}, the number comes from {{ic|1024*8}}).<br />
<br />
{{hc|<nowiki>dd if=image.iso of=/dev/disk1 bs=8192</nowiki>|<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
}}<br />
<br />
It is probably a good idea to eject your drive before physical removal at this point:<br />
<br />
$ diskutil eject /dev/disk1<br />
<br />
=== How to restore the USB drive ===<br />
<br />
Because the ISO image is a hybrid which can either be burned to a disc or directly written to a USB drive, it doesn't include a standard partition table.<br />
<br />
After you install Arch Linux and you're done with the USB drive, you should zero out its first 512 bytes ''(meaning the boot code from the MBR and the non-standard partition table)'' if you want to restore it to full capacity:<br />
<br />
# dd count=1 bs=512 if=/dev/zero of=/dev/sd'''x''' && sync<br />
<br />
Then create a new partition table (e.g. "msdos") and filesystem (e.g. EXT4, FAT32) using {{Pkg|gparted}}, or from a terminal:<br />
<br />
* For EXT2/3/4 (adjust accordingly), it would be:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.ext4 /dev/sd'''x1'''<br />
# e2label /dev/sd'''x1''' USB_STICK<br />
<br />
* For FAT32, install the {{Pkg|dosfstools}} package and run:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.vfat -F32 /dev/sd'''x1'''<br />
# dosfslabel /dev/sd'''x1''' USB_STICK<br />
<br />
== Other Methods for BIOS systems ==<br />
<br />
=== In GNU/Linux ===<br />
<br />
==== Using UNetbootin ==== <br />
<br />
UNetbootin can be used on any Linux distribution or Windows to copy your iso to a USB device. However, Unetbootin overwrites syslinux.cfg, so it creates a USB device that does not boot properly. For this reason, '''Unetbootin is not recommended''' -- please use {{ic|dd}} or one of the other methods discussed in this topic.<br />
{{Warning|UNetbootin writes over the default {{ic|syslinux.cfg}}; this must be restored before the USB device will boot properly.}}<br />
<br />
Edit {{ic|syslinux.cfg}}:<br />
<br />
{{hc|sysconfig.cfg|2=<br />
default menu.c32<br />
prompt 0<br />
menu title Archlinux Installer<br />
timeout 100<br />
<br />
label unetbootindefault<br />
menu label Archlinux_x86_64<br />
kernel /arch/boot/x86_64/vmlinuz<br />
append initrd=/arch/boot/x86_64/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
<br />
label ubnentry0<br />
menu label Archlinux_i686<br />
kernel /arch/boot/i686/vmlinuz<br />
append initrd=/arch/boot/i686/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
}}<br />
<br />
In {{ic|/dev/sd'''x1'''}} you must replace '''x''' with the first free letter after the last letter in use on the system where you are installing Arch Linux (e.g. if you have two hard drives, use {{ic|c}}.). You can make this change during the first phase of boot by pressing {{ic|Tab}} when the menu is shown.<br />
<br />
=== In Windows ===<br />
<br />
==== Win32 Disk Imager ====<br />
<br />
{{Warning|This will destroy all information on your USB flash drive!}}<br />
First, download the program from [http://sourceforge.net/projects/win32diskimager/ here]. Next, extract the archive and run the executable. Now, select the Arch Linux ISO under the {{ic|Image File}} section and the USB flash device letter (for example, [D:\]) under the {{ic|Device}} section. Finally, click {{ic|Write}} when ready.<br />
{{Tip|By default, the Win32 Disk Imager's file-browser assumes disk image files end with a {{ic|.img}} extension. However, you can simply change the {{ic|Files of type}} drop-down list to {{ic|*.*}} and continue on to selecting your Arch Linux ISO.}}<br />
{{Note|After installation, you may need to restore the USB flash drive following a process as outlined [[USB_Installation_Media#How_to_restore_the_USB_drive|here]].}}<br />
<br />
==== USBWriter for Windows ====<br />
<br />
Download the program from http://sourceforge.net/projects/usbwriter/ and run it. Select the arch image file, the target USB stick, and click on the {{ic|write}} button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
==== The Flashnul way ====<br />
<br />
[http://shounen.ru/soft/flashnul/ flashnul] is an utility to verify the functionality and maintenance of Flash-Memory (USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash etc).<br />
<br />
From a command prompt, invoke flashnul with {{ic|-p}}, and determine which device index is your USB drive, e.g.:<br />
<br />
{{hc|C:\>flashnul -p|<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
}}<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, {{ic|-L}}, and the path to your image, e.g:<br />
<br />
C:\>flashnul '''E:''' -L ''path\to\arch.iso''<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
{{Note|Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64.}}<br />
<br />
==== Loading the installation media from RAM ====<br />
<br />
This method uses [[Syslinux]] and a [[Ramdisk]] ([http://www.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) to load the entire Arch Linux ISO image into RAM. Since this will be running entirely from system memory, you will need to make sure the system you will be installing this on has an adequate amount. A minimum amount of RAM between 500 MB and 1 GB should suffice for a MEMDISK based, Arch Linux install.<br />
<br />
For more information on Arch Linux system requirements as well as those for MEMDISK see the [[Beginners' Guide]] and [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries here].<br />
{{Tip|Once the installer has completed loading you can simply remove the USB stick and even use it on a different machine to start the process all over again. Utilizing MEMDISK also allows booting and installing Arch Linux to and from the same USB flash drive.}}<br />
<br />
===== Preparing the USB flash drive =====<br />
<br />
Begin by formatting the USB flash drive as '''FAT32'''. Then create the following folders on the newly formatted drive.<br />
* {{ic|Boot}}<br />
** {{ic|Boot/ISOs}}<br />
** {{ic|Boot/Settings}}<br />
<br />
===== Copy the needed files to the USB flash drive =====<br />
<br />
Next copy the ISO that you would like to boot to the {{ic|Boot/ISOs}} folder. After that, extract from the following files from the latest release of {{pkg|syslinux}} from [http://www.kernel.org/pub/linux/utils/boot/syslinux/ here] and copy them into the following folders.<br />
* {{ic|./win32/syslinux.exe}} to the Desktop or Downloads folder on your system.<br />
* {{ic|./memdisk/memdisk}} to the {{ic|Settings}} folder on your USB flash drive.<br />
<br />
===== Create the configuration file =====<br />
<br />
After copying the needed files, navigate to the USB flash drive, /boot/Settings and create a {{ic|syslinux.cfg}} file.<br />
{{Warning|On the {{ic|INITRD}} line, be sure to use the name of the ISO file that you copied to your {{ic|ISOs}} folder!}}<br />
{{hc|/Boot/Settings/syslinux.cfg|2=<br />
DEFAULT arch_iso<br />
<br />
LABEL arch_iso<br />
MENU LABEL Arch Setup<br />
LINUX memdisk<br />
INITRD /Boot/ISOs/archlinux-2013.08.01-dual.iso<br />
APPEND iso}}<br />
For more information on Syslinux see the [[Syslinux|Arch Wiki article]].<br />
<br />
===== Final steps =====<br />
<br />
Finally, create a {{ic|*.bat}} file where {{ic|syslinux.exe}} is located and run it ("Run as administrator" if you're on Vista or Windows 7):<br />
{{hc|C:\Documents and Settings\username\Desktop\install.bat|<br />
@echo off<br />
syslinux.exe -m -a -d /Boot/Settings X:}}<br />
<br />
==== Universal USB Installer ====<br />
<br />
The Windows tool [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/] can be used to quickly create a Live USB media with multiple Installers of many Linux distros. Once created, Installers can be added or removed without reformatting the USB drive.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Note|For the [[#Boot the entire ISO from RAM|MEMDISK Method]], if you get the famous "30 seconds" error trying to boot the i686 version, press the {{ic|Tab}} key over the {{ic|Boot Arch Linux (i686)}} entry and add {{ic|vmalloc&#61;448M}} at the end. For reference: ''If your image is bigger than 128MiB and you have a 32-bit OS, then you have to increase the maximum memory usage of vmalloc''. [http://www.syslinux.org/wiki/index.php/MEMDISK#-_memdiskfind_in_combination_with_phram_and_mtdblock (*)]}}<br />
<br />
{{Note|If you get the "30 seconds" error due to the {{ic|/dev/disk/by-label/ARCH_XXXXXX}} not mounting, try renaming your USB media to {{ic|ARCH_XXXXXX}} (e.g. {{ic|ARCH_201302}}).}}<br />
<br />
== See Also ==<br />
<br />
* [http://www.gentoo.org/doc/en/liveusb.xml Gentoo liveusb document]</div>The.ridikulus.rathttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=283871USB flash installation medium2013-11-21T08:17:05Z<p>The.ridikulus.rat: Add info for manuall installation of Syslinux in Windows and reorg of page</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:USB Installation Media]]<br />
[[bg:USB Installation Media]]<br />
[[de:Installation von einem USB-Stick]]<br />
[[es:USB Installation Media]]<br />
[[it:USB Installation Media]]<br />
[[ja:USB Installation Media]]<br />
[[ro:Instalare prin USB]]<br />
[[ru:USB Installation Media]]<br />
[[tr:USB_ile_kurulum]]<br />
[[zh-CN:USB Installation Media]]<br />
[[zh-TW:USB Installation Media]]<br />
{{Article summary start}}<br />
{{Article summary text|Mutiplatform instructions on creating a bootable USB stick which can be used for installing Arch Linux, system maintenance or for recovery purposes.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|CD Burning}}<br />
{{Article summary end}}<br />
<br />
This page discusses various methods on how to create a Arch Linux Installer USB drive (also referred to as ''"flash drive", "USB stick", "USB key"'', etc) for booting in BIOS and UEFI systems. The result will be a LiveUSB (LiveCD-like) system) that, because of the nature of [[Wikipedia:SquashFS|SquashFS]], will discard all changes once the computer shuts down.<br />
<br />
If you would like to run a full install of Arch Linux from a USB drive (i.e. with persistent settings), see [[Installing Arch Linux on a USB key]]. If you would like to use your bootable Arch Linux USB stick as a rescue USB, see [[Change Root]].<br />
<br />
== BIOS and UEFI Bootable USB ==<br />
<br />
{{Note|The instructions below are specifically for [[Archiso]]/official media; [[Archboot]] preparation is identical, without the filesystem LABEL/UUID requirement.}}<br />
<br />
=== Recommended Method - in GNU/Linux ===<br />
<br />
This method is slightly more complicated than writing the image directly with {{ic|dd}}, but it does keep the drive usable for data storage. Before you begin, make sure that your USB device is formatted as either FAT32. Also, make sure that you have the latest ''syslinux'' package (version 6.02 or newer) installed<br />
<br />
* [[Beginners_Guide#Prepare_the_storage_drive|First create a MBR (msdos) partition table with at least one partition, in the USB]] (it is fine to use an already partitioned USB).<br />
<br />
* Mount the ISO image:<br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2013.10.01-dual.iso /mnt/iso<br />
<br />
* Then create a FAT32 filesystem in the partition on the USB (unmount before, if necessary).<br />
<br />
* Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
# mount /dev/sd'''X'''1 /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}<br />
<br />
* Adjust the configuration files (necessary only for [[Archiso]], not needed for [[Archboot]] iso):<br />
<br />
{{Warning|Failure to label the drive "{{ic|ARCH_2013XX}}" (with the appropriate release month) or to use an [[UUID]] (to re-label it to whatever you like) '''will''' get you the infamous "30 seconds" error.}}<br />
<br />
Here's how you can replace the {{ic|1=archisolabel=ARCH_2013XX}} part with your equivalent of {{ic|1=archiso'''device'''=/dev/disk/by-uuid/47FA-4071}} for both config files at the same time, using a single command:<br />
<br />
{{Note|Adjust {{ic|/dev/sd'''X'''1}} before running it, else it will become blank (since drive {{ic|sd'''X'''}} doesn't exist).}}<br />
<br />
$ sed -i "s|label=ARCH_.*|device=/dev/disk/by-uuid/$(blkid -o value -s UUID /dev/sd'''X'''1)|" archiso_sys{32,64}.cfg<br />
<br />
* Install Syslinux to the USB by following [[Syslinux#Manual_install]]. Overwrite the existing syslinux modules ({{ic|*.c32}} files) present in the USB (from the ISO) with the ones from the Syslinux pkg to avoid version mismatch related boot failure.<br />
<br />
* Mark the USB partition as active by following [[Syslinux#MBR_partition_table]]<br />
<br />
=== Recommended Method - In Windows ===<br />
<br />
{{Note|<br />
* Do not use any '''Bootable USB Creator utility''' for creating the UEFI bootable USB. Do not use ''dd for Windows'' to dd the ISO to the USB drive.}}<br />
<br />
* In the below commands {{ic|X:}} is assumed to be the USB flash drive in Windows.}}<br />
<br />
* Windows used backward slah {{ic|\}} as path-separator, so the same is used in the below commands.<br />
}}<br />
<br />
* Partition and format the USB drive using [http://rufus.akeo.ie/ Rufus USB partitioner]. Select partition scheme option as '''MBR for BIOS and UEFI''' and File system as '''FAT32'''. Uncheck "Create a bootable disk using ISO image" and "Create extended label and icon files" options. Use '''Volume Label''' of the USB drive (in Rufus) to match the LABEL mentioned in {{ic|1=archisolabel=}} part in {{ic|<ISO>\loader\entries\archiso-x86_64.conf}}. <br />
<br />
{{Note|The '''Volume Label''' step is required for Official ISO (archiso) only, not required for [[Archboot]].}}<br />
<br />
* Extract the ISO (similar to extracting ZIP archive) to the USB flash drive (using [http://7-zip.org/ 7-Zip]. <br />
<br />
* Download latest official syslinux 6.xx binaries (zip file) from https://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract it.<br />
<br />
* Go to {{ic|syslinux-<version>\bios}} directory, and copy all the {{ic|*.c32}} inside all the sub-directories, to {{ic|X:\boot\syslinux\}}.<br />
<br />
* Install Syslinux to the USB by running (in Windows cmd prompt) (use {{ic|bios/win64/syslinux64.exe}} for x64 Windows):<br />
<br />
bios/win32/syslinux.exe -d /boot/syslinux -m -a -i X:<br />
<br />
{{Note|<br />
* The above step install Syslinux {{ic|ldlinux.sys}} to the USB partition VBR, sets the partition as active/boot in the MBR partition table and write the MBR boot code to the 1st 400-byte boot code region of the USB.<br />
<br />
* The {{ic|-d}} switch expects path with forward slash path-separator like in *unix systems.<br />
}}<br />
<br />
== BIOS-only USB using dd ==<br />
<br />
{{Warning|This will irrevocably destroy all data on {{ic|/dev/sd'''x'''}}.}}<br />
<br />
=== In GNU/Linux ===<br />
<br />
{{Tip|Check that the USB flash installation media is '''not''' mounted with {{ic|lsblk}}.}}<br />
<br />
{{Note|Use {{ic|/dev/sd'''x'''}} instead of {{ic|/dev/sd'''x1'''}}.}}<br />
<br />
# dd bs=4M if=/path/to/archlinux.iso of=/dev/sd'''x''' && sync<br />
<br />
=== In Windows ===<br />
<br />
==== Using Cygwin ====<br />
<br />
Make sure your [http://www.cygwin.com/ Cygwin] installation contains the {{ic|dd}} package.<br />
<br />
{{Tip|If you do not want to install Cygwin, you can download {{ic|dd}} for Windows from [http://www.chrysocome.net/dd here]. See the next section for more information.}}<br />
<br />
Place your image file in your home directory:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]: bs=4M<br />
<br />
where image.iso is the path to the iso image file within the {{ic|cygwin}} directory and {{ic|\\.\['''x''']}}: is your USB flash drive where '''x''' is the windows designated letter, e.g. {{ic|\\.\d:}}.<br />
<br />
On Cygwin 6.0 find out the correct partition with:<br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
{{Warning|This will irrevocably delete all files on your USB flash drive, so make sure you do not have any important files on the stick before doing this.}}<br />
<br />
dd if=image.iso of=/dev/sdb bs=4M<br />
<br />
==== dd for Windows ====<br />
<br />
{{Note|Some users have an "isolinux.bin missing or corrupt" problem when booting the media with this method.}}<br />
<br />
A GPL licensed dd version for Windows is available at http://www.chrysocome.net/dd. The advantage of this over Cygwin is a smaller download. Use it as shown in instructions for Cygwin above.<br />
<br />
To begin, download the latest version of dd for Windows. Once downloaded, extract the archive's contents into Downloads or elsewhere.<br />
<br />
Now, launch your {{ic|command prompt}} as an administrator. Next, change directory ({{ic|cd}}) into the Downloads directory.<br />
<br />
If your Arch Linux ISO is elsewhere you may need to state the full path, for convenience you may wish to put the Arch Linux ISO into the same folder as the dd executable. The basic format of the command will look like this.<br />
<br />
{{bc|<nowiki>dd if=archlinux-2013-XX-xx-dual.iso of=\\.\x: bs=4m</nowiki>}}<br />
{{Warning|This command will replace the drive's contents and its formatting with the ISO's. You will likely be unable to recover its contents in the event of an accidental copy. Be absolutely sure that you are directing dd to the correct drive before executing!}}<br />
Simply replace the various null spots (indicated by an "x") with the correct date and correct drive letter.<br />
<br />
Here is a complete example.<br />
{{bc|<nowiki>dd if=ISOs\archlinux-2013.08.01-dual.iso of=\\.\d: bs=4M</nowiki>}}<br />
<br />
=== In Mac OS X ===<br />
<br />
To be able to use {{ic|dd}} on your USB device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and in {{ic|Terminal.app}} run:<br />
<br />
$ diskutil list<br />
<br />
Figure out what your USB device is called with {{ic|mount}} or {{ic|<nowiki>sudo dmesg | tail</nowiki>}} (e.g. {{ic|/dev/disk1}}) and unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1):<br />
<br />
$ diskutil unmountDisk /dev/disk1<br />
<br />
Now we can continue in accordance with the instructions above (but use {{ic|1=bs=8192}} if you are using the OS X {{ic|dd}}, the number comes from {{ic|1024*8}}).<br />
<br />
{{hc|<nowiki>dd if=image.iso of=/dev/disk1 bs=8192</nowiki>|<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
}}<br />
<br />
It is probably a good idea to eject your drive before physical removal at this point:<br />
<br />
$ diskutil eject /dev/disk1<br />
<br />
=== How to restore the USB drive ===<br />
<br />
Because the ISO image is a hybrid which can either be burned to a disc or directly written to a USB drive, it doesn't include a standard partition table.<br />
<br />
After you install Arch Linux and you're done with the USB drive, you should zero out its first 512 bytes ''(meaning the boot code from the MBR and the non-standard partition table)'' if you want to restore it to full capacity:<br />
<br />
# dd count=1 bs=512 if=/dev/zero of=/dev/sd'''x''' && sync<br />
<br />
Then create a new partition table (e.g. "msdos") and filesystem (e.g. EXT4, FAT32) using {{Pkg|gparted}}, or from a terminal:<br />
<br />
* For EXT2/3/4 (adjust accordingly), it would be:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.ext4 /dev/sd'''x1'''<br />
# e2label /dev/sd'''x1''' USB_STICK<br />
<br />
* For FAT32, install the {{Pkg|dosfstools}} package and run:<br />
<br />
# cfdisk /dev/sd'''x'''<br />
# mkfs.vfat -F32 /dev/sd'''x1'''<br />
# dosfslabel /dev/sd'''x1''' USB_STICK<br />
<br />
== Other Methods for BIOS systems ==<br />
<br />
=== In GNU/Linux ===<br />
<br />
==== Using UNetbootin ==== <br />
<br />
UNetbootin can be used on any Linux distribution or Windows to copy your iso to a USB device. However, Unetbootin overwrites syslinux.cfg, so it creates a USB device that does not boot properly. For this reason, '''Unetbootin is not recommended''' -- please use {{ic|dd}} or one of the other methods discussed in this topic.<br />
{{Warning|UNetbootin writes over the default {{ic|syslinux.cfg}}; this must be restored before the USB device will boot properly.}}<br />
<br />
Edit {{ic|syslinux.cfg}}:<br />
<br />
{{hc|sysconfig.cfg|2=<br />
default menu.c32<br />
prompt 0<br />
menu title Archlinux Installer<br />
timeout 100<br />
<br />
label unetbootindefault<br />
menu label Archlinux_x86_64<br />
kernel /arch/boot/x86_64/vmlinuz<br />
append initrd=/arch/boot/x86_64/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
<br />
label ubnentry0<br />
menu label Archlinux_i686<br />
kernel /arch/boot/i686/vmlinuz<br />
append initrd=/arch/boot/i686/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
}}<br />
<br />
In {{ic|/dev/sd'''x1'''}} you must replace '''x''' with the first free letter after the last letter in use on the system where you are installing Arch Linux (e.g. if you have two hard drives, use {{ic|c}}.). You can make this change during the first phase of boot by pressing {{ic|Tab}} when the menu is shown.<br />
<br />
=== In Windows ===<br />
<br />
==== Win32 Disk Imager ====<br />
<br />
{{Warning|This will destroy all information on your USB flash drive!}}<br />
First, download the program from [http://sourceforge.net/projects/win32diskimager/ here]. Next, extract the archive and run the executable. Now, select the Arch Linux ISO under the {{ic|Image File}} section and the USB flash device letter (for example, [D:\]) under the {{ic|Device}} section. Finally, click {{ic|Write}} when ready.<br />
{{Tip|By default, the Win32 Disk Imager's file-browser assumes disk image files end with a {{ic|.img}} extension. However, you can simply change the {{ic|Files of type}} drop-down list to {{ic|*.*}} and continue on to selecting your Arch Linux ISO.}}<br />
{{Note|After installation, you may need to restore the USB flash drive following a process as outlined [[USB_Installation_Media#How_to_restore_the_USB_drive|here]].}}<br />
<br />
==== USBWriter for Windows ====<br />
<br />
Download the program from http://sourceforge.net/projects/usbwriter/ and run it. Select the arch image file, the target USB stick, and click on the {{ic|write}} button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
==== The Flashnul way ====<br />
<br />
[http://shounen.ru/soft/flashnul/ flashnul] is an utility to verify the functionality and maintenance of Flash-Memory (USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash etc).<br />
<br />
From a command prompt, invoke flashnul with {{ic|-p}}, and determine which device index is your USB drive, e.g.:<br />
<br />
{{hc|C:\>flashnul -p|<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
}}<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, {{ic|-L}}, and the path to your image, e.g:<br />
<br />
C:\>flashnul '''E:''' -L ''path\to\arch.iso''<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
{{Note|Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64.}}<br />
<br />
==== Loading the installation media from RAM ====<br />
<br />
This method uses [[Syslinux]] and a [[Ramdisk]] ([http://www.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) to load the entire Arch Linux ISO image into RAM. Since this will be running entirely from system memory, you will need to make sure the system you will be installing this on has an adequate amount. A minimum amount of RAM between 500 MB and 1 GB should suffice for a MEMDISK based, Arch Linux install.<br />
<br />
For more information on Arch Linux system requirements as well as those for MEMDISK see the [[Beginners' Guide]] and [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries here].<br />
{{Tip|Once the installer has completed loading you can simply remove the USB stick and even use it on a different machine to start the process all over again. Utilizing MEMDISK also allows booting and installing Arch Linux to and from the same USB flash drive.}}<br />
<br />
===== Preparing the USB flash drive =====<br />
<br />
Begin by formatting the USB flash drive as '''FAT32'''. Then create the following folders on the newly formatted drive.<br />
* {{ic|Boot}}<br />
** {{ic|Boot/ISOs}}<br />
** {{ic|Boot/Settings}}<br />
<br />
===== Copy the needed files to the USB flash drive =====<br />
<br />
Next copy the ISO that you would like to boot to the {{ic|Boot/ISOs}} folder. After that, extract from the following files from the latest release of {{pkg|syslinux}} from [http://www.kernel.org/pub/linux/utils/boot/syslinux/ here] and copy them into the following folders.<br />
* {{ic|./win32/syslinux.exe}} to the Desktop or Downloads folder on your system.<br />
* {{ic|./memdisk/memdisk}} to the {{ic|Settings}} folder on your USB flash drive.<br />
<br />
===== Create the configuration file =====<br />
<br />
After copying the needed files, navigate to the USB flash drive, /boot/Settings and create a {{ic|syslinux.cfg}} file.<br />
{{Warning|On the {{ic|INITRD}} line, be sure to use the name of the ISO file that you copied to your {{ic|ISOs}} folder!}}<br />
{{hc|/Boot/Settings/syslinux.cfg|2=<br />
DEFAULT arch_iso<br />
<br />
LABEL arch_iso<br />
MENU LABEL Arch Setup<br />
LINUX memdisk<br />
INITRD /Boot/ISOs/archlinux-2013.08.01-dual.iso<br />
APPEND iso}}<br />
For more information on Syslinux see the [[Syslinux|Arch Wiki article]].<br />
<br />
===== Final steps =====<br />
<br />
Finally, create a {{ic|*.bat}} file where {{ic|syslinux.exe}} is located and run it ("Run as administrator" if you're on Vista or Windows 7):<br />
{{hc|C:\Documents and Settings\username\Desktop\install.bat|<br />
@echo off<br />
syslinux.exe -m -a -d /Boot/Settings X:}}<br />
<br />
==== Universal USB Installer ====<br />
<br />
The Windows tool [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/] can be used to quickly create a Live USB media with multiple Installers of many Linux distros. Once created, Installers can be added or removed without reformatting the USB drive.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Note|For the [[#Boot the entire ISO from RAM|MEMDISK Method]], if you get the famous "30 seconds" error trying to boot the i686 version, press the {{ic|Tab}} key over the {{ic|Boot Arch Linux (i686)}} entry and add {{ic|vmalloc&#61;448M}} at the end. For reference: ''If your image is bigger than 128MiB and you have a 32-bit OS, then you have to increase the maximum memory usage of vmalloc''. [http://www.syslinux.org/wiki/index.php/MEMDISK#-_memdiskfind_in_combination_with_phram_and_mtdblock (*)]}}<br />
<br />
{{Note|If you get the "30 seconds" error due to the {{ic|/dev/disk/by-label/ARCH_XXXXXX}} not mounting, try renaming your USB media to {{ic|ARCH_XXXXXX}} (e.g. {{ic|ARCH_201302}}).}}<br />
<br />
== See Also ==<br />
<br />
* [http://www.gentoo.org/doc/en/liveusb.xml Gentoo liveusb document]</div>The.ridikulus.rat