[multiboot-guide] master: File is now in rough final stage and ready for peer review (ca4399b)
immanetize at fedoraproject.org
immanetize at fedoraproject.org
Tue Jan 6 03:39:12 UTC 2015
Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
>---------------------------------------------------------------
commit ca4399bb255f7163d2b4e544d293e2ecae8ed01c
Author: Roger Baran <rapidrecoveryit at gmail.com>
Date: Sat Oct 4 08:58:13 2014 -0500
File is now in rough final stage and ready for peer review
>---------------------------------------------------------------
en-US/UEFI-win.xml | 224 ++++++++++++++++++++++++++--------------------------
1 files changed, 113 insertions(+), 111 deletions(-)
diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 00fc8bc..eb7d2ff 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -1,19 +1,22 @@
<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
-[
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "Fedora_Multiboot_Guide.ent">
%BOOK_ENTITIES;
+
]>
-<section id="UEFI-win">
- <title>Introduction</title>
+
+ <section id="UEFI-win">
+ <title>Booting on Windows Systems</title>
<para>
Fedora is a great choice for all aspects of multibooting your system using UEFI! Fedora has gone to great lengths to ensure that you can install it on many different platforms and in several different environments; including desktops, laptops (with or without Secure Boot enabled) as well as Apple/Macintosh based computers.
</para>
<para>
This section of the Multiboot Guide begins by covering a few important definitions as well as the more general aspects of the Windows and Fedora UEFI boot process. Windows and Fedora specific boot files, their purposes, and locations are then listed. After that, the guide deal with the similarities and the differences in the UEFI boot process for both operating systems. The final section is how to use <filename>BCD</filename> to dual boot; but there are a few, very important caveats to doing that, and they are pointed out within that section.
-</para><para>
+ </para>
+ <para>
We hope that you will find this information both interesting and helpful. With the information outlined in this, and other, sections of this guide, you will have a better understanding of what is happening 'behind the scenes'. That should prove useful when it comes time to work your way through troubleshooting a particular issue related to booting using UEFI.
- </para><para>
+ </para>
+ <para>
This guide represents our best effort at explaining a very technical and difficult to understand specification in terms that everyone can understand. For this reason, some parts of the explanation have been over-simplified for ease in understanding the overall concept or process that is taking place. For those that desire more information that what is available in this article, extensive information about UEFI is available here <ulink url="http://www.uefidk.com/learn" /> and here <ulink url="http://www.uefi.org/" />
</para>
<section id="Boot_Manager_vs_BootLoader">
@@ -21,23 +24,23 @@
<para>
Knowing the difference between a Boot Manager and Boot Loader is a good start to understanding the UEFI boot process for both Windows and Fedora.
</para>
- <orderedlist>
- <listitem>
- <para>
- <literal>Boot Manager:</literal> A utility that allows multiple operating systems to be booted from the same computer
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>Boot Loader:</literal> The program that calls the operating system into memory
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>GRUB2</literal> acts as both a Boot Manager and a Boot Loader
- </listitem>
- </para>
-</orderedlist>
+ <orderedlist>
+ <listitem>
+ <para>
+ <literal>Boot Manager:</literal> A utility that allows multiple operating systems to be booted from the same computer
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>Boot Loader:</literal> The program that calls the operating system into memory
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>GRUB2</literal> acts as both a Boot Manager and a Boot Loader
+ </para>
+ </listitem>
+ </orderedlist>
</section>
<section id="Windows_EFI_Files">
<title>Windows EFI Partition Files</title>
@@ -49,8 +52,8 @@
</para>
<para>
Mui stands for 'Multilingual User Interface' and the <filename>*.mui</filename> files located in the <filename class="directory">bg-BG</filename> sub-directory are used to provide language support in other-than-english installations.
- </para>
- <para>
+ </para>
+ <para>
There doesn't seem to be any information at all on what <filename>boot.stl</filename> is or what functions it may perform.
</para>
</section>
@@ -59,68 +62,83 @@
<para>
Within a Fedora-created EFI partition you will find the following files at the designated locations. The purpose of each file is also given:
</para>
- <orderedlist>
- <listitem>
- <para>
+ <orderedlist>
+ <listitem>
+ <para>
./EFI/fedora/MokManager.efi: To launch a locally-compiled kernel, you must sign it with a MOK and register that MOK with the system. For example, if you recompiled the kernel with third-party kernel drivers, such as those needed by Nvidia's and AMD/ATI's proprietary video drivers. This file manages that process.
- </para>
- </listitem>
- <listitem>
- <para>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
./EFI/fedora/gcdx64.efi: Used to boot live media; called by shim.
- </para>
- </listitem>
- <listitem>
- <para>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
./EFI/fedora/grubx64.efi: The main GRUB executable (signed with Fedora's key for Secure Booting).
- </para>
- </listitem>
- <listitem>
- <para>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
./EFI/fedora/shim-fedora.efi: Performs the signing mechanism for grubx64.efi in a Secure Boot scenario
- </para>
- </listitem>
- <listitem>
- <para>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
./EFI/fedora/shim.efi: This a Microsoft signed stub to allow booting using Secure Boot on 'Windows Ready Certified' computers.
- </para>
- </listitem>
-</orderedlist>
-</section>
-<section id="Bootfiles">
-<section id="Bootfiles.Windows_BCD">
- <title>Windows uses <filename>bootmgrfw.efi</fliename> and <filename>BCD</filename> to boot</title> 64 bit Windows operating systems. <filename>bootmgr.efi</filename> is used in conjunction with <filename>BCD</filename> in 32 bit installations.
+ </para>
+ </listitem>
+ </orderedlist>
+ </section>
+ <section id="Bootfiles.Windows_BCD">
+ <title>Windows Boot Files</title>
+ <para>
+ Windows 64 bit installations use <filename>bootmgrfw.efi</filename> to load <filename>BCD</filename> and execute <filename>winload.efi</filename>. 32 bit installations use <filename>bootmgr.efi</filename> to initiate the same chain of events.
+ </para>
<para>
On a legacy, BIOS-based, PC the <filename>BCD</filename> is located at <filename class="directory">\Boot\BCD</filename>
On an EFI firmware-based PC it is located at <filename class="directory">\EFI\Microsoft\Boot\</filename>
- </para><para>
- <filename>BCD</filename> is actually formatted as a registry hive and is therefore totally Windows-centric and proprietary. While <filename>BCD</filename> can be configured to boot other operating systems, it cannot be done without a certain measure of difficulty and an even greater level of un-dependability after reboots.
</para>
<para>
- <filename>BCD</filename> contains configuration data that controls the operation of the Windows Boot Loader. Since there is only one defined mechanism for booting, if <filename>bootmgr.efi</filename>, <filename>bootmgrfw.efi</filename> or the <filename>BCD</filename> is missing, or corrupt, you cannot boot into Windows.
+ <filename>BCD</filename> is a formatted as a registry hive and is therefore totally Windows-centric and proprietary. While <filename>BCD</filename> can be configured to boot other operating systems, it cannot be done without a certain measure of difficulty and an even greater level of un-dependability after reboots.
+ </para>
+ <para>
+ <filename>BCD</filename> contains configuration data that controls the operation of the Windows Boot Loader. Since there is only one defined mechanism for booting, if <filename>bootmgr.efi</filename>, <filename>bootmgrfw.efi</filename> or the <filename>BCD</filename> is missing, or corrupt, you cannot boot into Windows.
</para>
</section>
<section id="Bootfiles.Fedora_GRUB">
- <title>Fedora uses <filename> shim.efi</filename>, <filename>gurbx64.efi</filename> and <filename>grub.cfg</filename> to boot</title>
- <!-- comment: need to finish filling in this section -->
- <para>
- Full text will be added here....
- </para>
- <para>
- In the event that the normal files cannot be loaded, a process is provided that uses a process called "fallback".
- </para>
- <para>
- In this process, <filename>bootx64.efi</filename> is loaded and executed by the UEFI firmware; which in turn loads <filemame>fallback.efi</filename>. Another file called <filename>Boot.csv</filename> contains entries that will be added 'on-the-fly' to the EFI NVRAM. <filename>fallback.efi</filename> will search the entire partition looking for Boot.csv files, read their data, and create entries in NVRAM for each one. It will then adjust the BootNext variable and pass execution back to the firmware to boot from that entry. This process is known as fallback and allows for a 'second chance' to get an operating system loaded in the event that its original entry in EFI firmware was deleted or corrupt.
+ <title>Fedora Boot Files</title>
+ <para>
+ Fedora uses <filename>shim.efi</filename> during Secure Boot to load and execute <filename>grubx64.efi</filename>; which then reads <filename>grub.cfg</filename> and displays a boot selection menu.
</para>
<para>
- If your <filename>grub.cfg</filename> file is missing you will go to a GRUB command prompt where (using various GRUB commands) you can gather the information you need to boot your Fedora installation.
+ In a Secure Boot environment, each link in the boot chain must be signed by a trusted authority. On Windows Ready certified computers, the key that is trusted is provided by Microsoft and is pre-loaded on the computer prior to shipping. Thus, in order to boot (without manually adding/changing the key structure in the EFI firmware) a boot manager and boot loader has to be signed by the pre-loaded key in order to execute.
+ </para>
+ <para>
+Fedora's <filename>shim.efi</filename> is a code stub that has been signed by Microsoft. This allows the EFI firmware, in Secure Boot mode, to load and execute <filename>shim.efi</filename>. <filename>shim.efi</filename> then checks the signature on <filename>gurbx64.efi</filename> and, if correct, passes execution over to it. <filename>grubx64.efi</filename> has been signed by Fedora and that is the signature that <filename>shim.efi</filename> is looking for. Thus, <filename>shim.efi</filename> effectively transfers the chain of trust from Microsoft to Fedora as early in the boot sequence as possible.
+ </para>
+ <para>
+<filename>grubx64.efi</filename> continues the chain of trust by checking the signature of the kernel files prior to passing execution to them.
+ </para>
+ <para>
+The only real difference in the boot process between having Secure Boot enabled or disabled is the signature checking that takes place. If a file in the chain has a missing or invalid signature, then that file will not be allowed to execute. This provides another 'brick-in-the-wall' for protecting your computer against executing malware prior to loading the operating system.
</para>
<para>
- As a side note, the <filename>shim.efi</filename> file, located in <filename class="directory">/EFI/fedora</filename> of the EFI Partition, is used in Secure Boot scenarios (covered in detail here: <xref linkend="UEFI-general" />) and simply passes control to GRUB2; which then lists the various Operating Systems entries from the <filename>grub.cfg</filename> file to the screen for selection by the user.
+It is important to note that Microsoft is not 'in charge' of this process. The whole issue of having to use Microsoft signed keys comes from the desire of operating system software companies (including Fedora) to have thier software installed on hardware that has complied with the certification process for a "Windows Ready" computer. Many computers do not go through the certification process and other-than-Windows operating systems can be installed on them without a Microsoft signed boot manager/loader. Additionally, one can also, at-will, disable Secure Boot or add your own keys for a Secure Boot environment. So, as you can see, Microsoft does not have a monopoly on the UEFI Secure Boot process and simply provides a process for all other operating system developers to boot on machines that have been specifically designed for running Microsoft Windows.
+ </para>
+ <para>
+ With Secure Boot disabled, in the event that the normal files cannot be loaded, Fedora provides a 'second chance' boot sequence that uses a process called "fallback".
+ </para>
+ <para>
+ In fallback, <filename>bootx64.efi</filename> is loaded and executed by the UEFI firmware; which in turn loads <filename>fallback.efi</filename>. Another file called <filename>Boot.csv</filename> contains entries that will be added 'on-the-fly' to the EFI NVRAM. <filename>fallback.efi</filename> searches the entire EFI partition looking for Boot.csv files. It read their data, and creates entries in NVRAM for each one. After that, it changes the BootNext variable and passes execution back to the firmware to boot from that entry. The fallback process is executed as a part of 'Default Boot Behavior'. Default Boot Behavior is initiated when the EFI firmware is unable to load any boot managers/loaders after traversing the entire BootOrder variable. More information about Default Boot Behavior is available here: <xref linkend="UEFI-general" />.
+ </para>
+ <para>
+ If your <filename>grub.cfg</filename> file is missing you will go to a GRUB command prompt where (using various GRUB commands) you can gather the information you need to boot your Fedora installation.
</para>
<para>
+ As a side note, the <filename>shim.efi</filename> file, located in <filename class="directory">/EFI/fedora</filename> of the EFI Partition, is used in Secure Boot scenarios (covered in detail here: <xref linkend="UEFI-general" />) and simply passes control to GRUB2; which in turn lists the various Operating Systems entries from the <filename>grub.cfg</filename> file to the screen for selection by the user.
+ </para>
</section>
-</section>
<section id="Similarities_and_Differences">
<title>Similarities and Differences Between <filename>bootmgrfw.efi</filename>, <filename>grubx64.efi</filename> and <filename>bootx64.efi</filename></title>
<para>
@@ -128,66 +146,50 @@
</para>
<para>
<filename>bootmgrfw.efi</filename> is roughly equivilent to both of the GRUB2 files <filename>bootx64.efi</filename> and <filename>grubx64.efi</filename> (which will be covered in more detail later). What happens as each is called (and the format of the files involved) is where the differences start to show up...
- </para><para>
+ </para>
+ <para>
They are similar in that they all look for a configuration file: <filename>bootmgrfw.efi</filename> looks for <filename>BCD</filename>, <filename>grubx64.efi</filename> looks for <filename>grub.cfg</filename>, and <filename>bootx64.efi</filename> (using <filename>fallback.efi</filename> looks for <filename>Boot.csv</filename>
</para>
<para>
The main difference is that the GRUB2 <filename>bootx64.efi</filename> file is used when the EFI firmware goes into 'Default Boot Behavior' as a result of not finding any bootmanagers to load on the first time through the BootOrder listing in NVRAM; <filename>bootmgrfw.efi</filename> is called every time for a Windows boot. The end result is that if either the <filename>bootmgrfw.efi</filename> or the <filename>BCD</filename> is corrupt, or otherwise inaccessible, then Windows will not boot. Its game over.
- </para>
- <para>
- GRUB, on the other hand, has alternative methods for booting, which are implemented using <filename>bootx64.efi</filename> as well as a GRUB command prompt. This is all explained in detail below.
- </para>
-</section>
+ </para>
+ <para>
+ GRUB, on the other hand, has alternative methods for booting, which are implemented using <filename>bootx64.efi</filename> as well as a GRUB command prompt. This is all in detail below.
+ </para>
+ </section>
<section id="BCD_vs_GRUB">
<title>BCD Limitations vs GRUB2 Universality</title>
<para>
- BCD, by default, only knows about ONE installation (Windows); which it boots by loading winload.efi
+ <filename>BCD</filename>, by default, only knows about ONE installation (Windows); which it boots by loading <filename>winload.efi</filename>
</para>
<para>
- While BCD can be configured to allow for other entries, including pointing its default loader to a particular GRUB2 installation, it doesn't work very well. <filename>bootmgrfw.efi</filename>, using <filename>BCD</filename>, is designed to handle Windows. Period. It provides a straight shot to the Windows installation and that's it. Adding additional entries to the <filename>BCD</filename> is done through a commandline tool called <filename>bcdedit</filename> which is poorly documented and not intuitive to use at all; primarilly becuase it is formatted as a proprietary database file (registry hive).
+ While <filename>BCD</filename> can be configured to allow for other entries, including pointing its default loader to a particular GRUB2 installation, it doesn't work very well. <filename>bootmgrfw.efi</filename>, using <filename>BCD</filename>, is designed to handle Windows. Period. It provides a straight shot to the Windows installation and that's it. Adding additional entries to the <filename>BCD</filename> is done through a commandline tool called <filename>bcdedit</filename> which is poorly documented, not intuitive to use, and what information is available on the Internet it usually incorrect and confusing. It is difficult to properly modify primarilly becuase it is formatted as a proprietary database file (registry hive).
</para>
<para>
GRUB2, on the other hand, is designed from the gound up to handle all types of operating systems and makes it relatively easy to make changes to its configuration file.
</para>
<para>
- Under normal boot operations, the GRUB2 manager/loader (<filename>grubx64.efi</filename>) is called directly (via <filename>shim.efi</filename> in Secure Boot), which then reads the <filename>grub.cfg</filename> file and displays its entries for user intervention. Adding additional entries to <filename>grub.cfg</filename> can be done with any simple text editor. More specific nformation on GRUB is available here: <xref linkend="GRUB" />
- </para>
+ Under normal boot operations, the GRUB2 manager/loader (<filename>grubx64.efi</filename>) is called directly (via <filename>shim.efi</filename> in Secure Boot), which then reads the <filename>grub.cfg</filename> file and displays its entries for user intervention. Adding additional entries to <filename>grub.cfg</filename> can be done with any simple text editor. More specific nformation on GRUB is available here: <xref linkend="GRUB-basics" />
+ </para>
</section>
<section id="If_You_Must">
<title>Using BCD to dual boot</title>
+ <para>
+Using the default windows boot manager <filename>bootmrgfw.efi</filename> (which in turn uses <filename>BCD</filename>), to dual boot can be accomplished by using an administrators command prompt and entering:
+ </para>
+ <screen>
+ <prompt>C:\Windows\System32></prompt><command> bcdedit /set {bootmgr} path \EFI\fedora\shim.efi</command>
+ </screen>
+ <para>
+ This command causes the <filename>BCD</filename> to point to the Fedora <filename>shim.efi</filename>, which will in turn call <filename>grubx64.efi</filename> and present the gurb menu. The only caveat with this, is that the Fedora EFI partition files have to be moved to the windows-created EFI partition (usually <filename class="directory">/dev/sda1</filename>). Specifically, <filename class="directory">/dev/sda1/boot/EFI/</filename>
+ The actual procedure for doing so is covered later in this article.
+ </para>
<para>
- Using the default windows boot manager (which in turn uses BCD), to dual boot can be accomplished by entering 'bcdedit /set {bootmgr} path \EFI\fedora\shim.efi' at an administrator's command prompt. That command causes the windows boot manager to point to the Fedora shim.efi, which will in turn call grubx64.efi and present the gurb menu. The only caveat with this, is that the Fedora EFI partition files have to be moved to the windows-created EFI partition (usually /dev/sda1). For ease of understanding, this could be notated as /dev/sda1/boot/EFI/
- That is the location to copy the fedora directory to. The actual procedure for doing so is covered later in this article. For now, just the concept and overview is being presented.
- /dev/sda1/boot/EFI will already have directories for Boot and Microsoft; you will be adding in the fedora directory sturcture at that location.
- </para><para>
- During an installation of Fedora, where Anaconda creates the partitions automatically, there will be a separate EFI partition for the Fedora installation. To make BCD the boot manager for booting into your fedora installation, you will need to copy all of the files from the Fedora-created EFI partition (starting at the fedora sub-directory) to the EFI partition created by Microsoft during its installation. You can also choose, during installation, to manually set up your partitions; in which case you can simply indicate a mount point of '/boot/efi' for the Microsoft created partition and tell it not to format that partition. Grub will then create the "/dev/sda1/EFI/fedora directory and populate it with the necessary files and upon restart, /dev/sda1 will be mounted at /boot/efi/
- </para><para>
- <literal>However! Please keep reading!</literal>
- </para><para>
- <literal>Note!:</literal> There are reports that Windows, upon seeing another OS listing in "its" EFI partition, will (either inadvertantly or deliberately; no one knows which one for sure) destroy the directory structure for the other OS; thus disallowing the EFI Boot Manager to access the GRUB boot manager file pointed to by the modified BCD. It is recommended to maintain a separate EFI partition (by letting Anaconda do the grunt work of setting up all of the partitions) and then tweaking their sizes as desired.
- </para><para>
- Letting Anaconda create, and use, a separate EFI partition ensures that what has happened to others will not happen to you.
+During an installation of Fedora, where Anaconda creates the partitions automatically, there will be a separate EFI partition for the Fedora installation. To make <filename>BCD</filename> the boot configuration default for booting into your fedora installation, you will need to copy all of the files from the Fedora-created EFI partition (starting at the fedora sub-directory) to the EFI partition created by Microsoft during its installation. You can also choose, during installation, to manually set up your partitions; in which case you can simply indicate a mount point of <filename class="directory">/boot/efi</filename> for the Microsoft created partition and tell it not to format that partition. Grub will then create a <filename class="directory">/dev/sda1/EFI/fedora</filename> directory and populate it with the necessary files. Upon restart, <filename class="directory">/dev/sda1</filename> will be mounted at <filename class="directory">/boot/efi/</filename>
</para>
-</section>
-<!-- comment
-Refs:
-
-http://www.rodsbooks.com/efi-bootloaders/index.html
-http://www.solvusoft.com/en/files/error-missing-download/mui/windows/microsoft/windows-8-pro/bootmgfw-efi-mui/
-http://blog.hansenpartnership.com/uefi-secure-boot/
-http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm
-https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
-http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/
-http://nwrickert2.wordpress.com/2013/05/13/notes-on-uefi-windows-and-linux/
-https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
-http://www.uefidk.com/
-https://www.youtube.com/watch?v=eAnlhkbMang&list=PLk2sjg_-F-McRbCBoVRkP1sYMbmDf6zJM
-https://www.youtube.com/watch?v=ALzySqflHJw
-https://www.youtube.com/user/metalx1000/videos
-https://www.youtube.com/watch?v=tDREcY5EzTQ&list=PLXEcKYHTGBdQPSchdZV2UONYf3ve0DCJK
-https://www.youtube.com/watch?v=dRMIvY7BiL4
-https://www.youtube.com/watch?v=amwujljr7pY
-https://www.youtube.com/watch?v=35D0_feZnK8
-http://superuser.com/questions/376470/how-to-reinstall-grub2-efi
-https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System_Administrators_Guide/index.html#ch-Working_with_the_GRUB_2_Boot_Loader
-https://en.wikipedia.org/wiki/GNU_GRUB#GRUB_version_2 -->
+ <para>
+ <literal>However! Please keep reading!</literal>
+ </para>
+ <para>
+ <literal>Note!:</literal> There are reports that Windows, upon seeing another OS listing in "its" EFI partition, will (either inadvertantly or deliberately; no one knows which one for sure) destroy the directory structure for the other OS; thus disallowing the EFI Boot Manager to access the GRUB boot manager file pointed to by the modified <filename>BCD</filename>. It is recommended to maintain a separate EFI partition for all installations other than Windows. Letting Anaconda do the work of setting up all of the partitions, and then tweaking their sizes as desired, ensures that what has happened to others will not happen to you.
+ </para></section></section>
\ No newline at end of file
More information about the docs-commits
mailing list