Repository :
http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
---------------------------------------------------------------
commit b39756382858e7487ba91ee4200651c95134ebb3
Author: Pete Travis <immanetize(a)fedoraproject.org>
Date: Sat May 30 12:12:26 2015 -0600
finishing trimming of UEFI-win, and clarifying Secureboot win8 requirements
---------------------------------------------------------------
en-US/BOOT-BIOS_or_UEFI.xml | 2 +-
en-US/UEFI-win.xml | 193 +------------------------------------------
2 files changed, 5 insertions(+), 190 deletions(-)
diff --git a/en-US/BOOT-BIOS_or_UEFI.xml b/en-US/BOOT-BIOS_or_UEFI.xml
index e022d3a..7b7a266 100644
--- a/en-US/BOOT-BIOS_or_UEFI.xml
+++ b/en-US/BOOT-BIOS_or_UEFI.xml
@@ -50,7 +50,7 @@
</listitem>
<listitem>
<para>
- Your computer shipped with Windows 8. The terms of service for Windows 8
<emphasis>require</emphasis> SecureBoot, a UEFI feature.
+ Your computer shipped with Windows 8. The terms of service for manufacturers to
distribute computers with Windows 8 <emphasis>require</emphasis> SecureBoot, a
UEFI feature.
</para>
</listitem>
<listitem>
diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index bec8137..5fff237 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -7,201 +7,16 @@
<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,
this section deals with the similarities and the differences in the UEFI boot process for
both operating systems. The final section covers how to use
<filename>BCD</filename> to dual boot. Please be sure to read the few, but
very important caveats to modifying that critical Windows configuration file.
- </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>
- This guide represents our best effort at explaining a very technical and difficult to
understand specification in terms that everyone can understand. For those that desire more
information than what is available in this guide, 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">
- <title>Boot Managers and Boot Loaders Defined</title>
- <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>
- </orderedlist>
- <para>
- As you will see, <literal>GRUB</literal>* acts as both a Boot Manager
and a Boot Loader
- </para>
- <para>
- * The word <literal>GRUB</literal> will be used in this section of the
guide to indicate all versions of GRUB, including GRUB2, without differentiation.
- </para>
-</section>
-<section id="Windows_EFI_Files">
+ <section id="Windows_EFI_Files">
<title>Windows EFI Partition Files</title>
<para>
Microsoft uses <filename>bootmgr.efi</filename> and
<filename>bootmgrfw.efi</filename> as Boot Managers.
<filename>bootmgr.efi</filename> is the 32 bit version and
<filename>bootmgrfw.efi</filename> is the 64 bit version. Both of these files
are located in the root directory of the Microsoft-created EFI partition (usually found at
<filename class="directory">/dev/sda1</filename>). For EFI
compatibility, they are both located at <filename
class="directory">/EFI/Microsoft/Boot/</filename> as well.
</para>
<para>
Other files found within the <filename
class="directory">/EFI/Microsoft/Boot</filename> directory structure
are the <filename>BCD</filename> (a registry formatted configuration file),
sub-directories for language files, a memory test efi application, and the
<filename>BCD</filename> log files. The
<filename>BOOTSTAT.DAT</filename> file is used to flag whether a recovery mode
is required.
- </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>
- There doesn't seem to be any publicly available information on what
<filename>boot.stl</filename> is or what functions it may perform.
- </para>
- <para>
- The Windows boot loader, <filename>winload.efi</filename>, is located at
<filename class="directory">/WINDOWS/System32/Boot</filename> on
whatever drive and partition Windows was installed on.
- </para>
-</section>
-<section id="Fedora_EFI_Files">
- <title>Fedora EFI Partition Files</title>
- <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>
- <filename>./EFI/fedora/MokManager.efi</filename>: Mok stands for Machine
Owner Key. To launch a locally-compiled kernel, you must sign it with a MOK and register
that MOK with the system. You would need to do this, for example, if you recompiled the
kernel with third-party kernel drivers, such as those needed by Nvidia's or
AMD/ATI's proprietary video drivers. This file manages that process.
- </para>
- </listitem>
- <listitem>
- <para>
- <filename>./EFI/fedora/gcdx64.efi</filename>: Used to boot live media;
called by shim.
- </para>
- </listitem>
- <listitem>
- <para>
- <filename>./EFI/fedora/grubx64.efi</filename>: The main GRUB executable
(signed with Fedora's key for Secure Booting).
- </para>
- </listitem>
- <listitem>
- <para>
- <filename>./EFI/fedora/shim-fedora.efi</filename>: Performs the signing
mechanism for grubx64.efi in a Secure Boot scenario when using a MoK
- </para>
- </listitem>
- <listitem>
- <para>
- <filename>./EFI/fedora/shim.efi</filename>: This a Microsoft signed stub
to allow booting using Secure Boot on 'Windows Ready' certified computers.
- </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>
- Windows uses the same boot process whether the Secure Boot mechanism is enabled or
not.
- </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 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 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. With Secure
Boot disabled, <filename>grubx64.efi</filename> is called directly.
- </para>
- <para>
- 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 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 and
having it 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>
-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, the end user can also completely disable Secure Boot at any time or even add
their own keys to be used in 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>
- In the event that the normal files cannot be loaded, with or without Secure Boot
enabled, 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 <filename>Boot.csv</filename> files. It read their data, and creates
entries in NVRAM for each one. After that, it changes the
<literal>BootNext</literal> 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 list of operating system entries
indicated in the <literal>BootOrder</literal> variable. More information about
the UEFI Boot Process and 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. Additional information on using the GRUB command
prompt can be found here: <xref linkend="GRUB-runtime" />
- </para>
- </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>
- While you could say that <filename>bootmgrfw.efi</filename> acts in the
same way as the boot manager files provided by GRUB, there are technical differences that
show this not to be the case.
- </para>
- <para>
- <filename>bootmgrfw.efi</filename> is roughly equivilent to both of the
GRUB files <filename>grubx64.efi</filename> and
<filename>bootx64.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>
- 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> files.
- </para>
- <para>
- A major difference between the two systems is that GRUB provides an additional method
of booting using <filename>bootx64.efi</filename>. This file is used when the
EFI firmware goes into 'Default Boot Behavior' as a result of not finding any boot
managers to load on the first time through the <literal>BootOrder</literal>
listing in NVRAM.
- </para>
<para>
- In a Windows based system, <filename>bootmgrfw.efi</filename> is called
every time and no other mechanism is provided. 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 and in other sections of this guide.
- </para>
- </section>
-<section id="BCD_vs_GRUB">
- <title>BCD Limitations vs GRUB Universality</title>
- <para>
- <filename>BCD</filename>, by default, only knows about ONE installation
(Windows); which it boots by loading <filename>winload.efi</filename>
- </para>
<para>
- While, in theory, <filename>BCD</filename> can be configured to allow for
other entries, including pointing its default loader to a particular GRUB installation, in
reality, 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.
- </para>
- <para>
- Adding additional entries to the <filename>BCD</filename> is accomplished
through a commandline tool, provided by Microsoft, called
<filename>bcdedit</filename>. Unfortunately,
<filename>bcdedit</filename> is poorly documented, not intuitive to use, and
the little information available on the Internet about it is usually incorrect and
confusing. It is also difficult to properly modify primarilly becuase it is formatted as a
proprietary database file (registry hive); in other words you must use
<filename>bcdedit</filename> and that can only be done from within Windows.
+ If you need to restore these files to your EFI System Partition, you can find a copy
in <filename class="directory">C:\Windows\System32\Boot</filename>.
</para>
- <para>
- GRUB, 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 GRUB 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>
-Modifying <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>, as the default boot manager for Windows.
<filename>shim.efi</filename> will in turn call
<filename>grubx64.efi</filename> and present the GRUB 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>
- </para>
- <para>
-During an installation of Fedora, where Anaconda is allowed to create 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>
- <para>
- <literal>However! Please keep reading!</literal>
- </para>
- <para>
- <literal>Note!:</literal> There are reports that Windows, upon seeing a
change to "its" EFI partition, will (either inadvertantly or deliberately; no
one knows which one for sure) destroy the directory structure for the other operating
system; thus disallowing <filename>bootmrgfw.efi</filename> to access the GRUB
file pointed to by the modified <filename>BCD</filename>. This will completely
render all of your installations non-bootable.
- </para>
- <para>
- It is highly recommended to maintain a separate EFI partition for all installations
other than Windows. Simply let Anaconda do the work of setting up all of the partitions,
and then tweak their sizes as desired. This will ensure that what has happened to others
will not happen to you.
- </para></section></section>
\ No newline at end of file
+ </section>
+ </section>