Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
>---------------------------------------------------------------
commit d40655625bccc740e8c90af010432f8f6b8247c9
Author: Pete Travis <immanetize(a)fedoraproject.org>
Date: Sat May 30 18:26:09 2015 -0600
some markup corrections, a little cleanup
>---------------------------------------------------------------
en-US/BOOT-BIOS_or_UEFI.xml | 6 ++++++
en-US/UEFI-win.xml | 2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/en-US/BOOT-BIOS_or_UEFI.xml b/en-US/BOOT-BIOS_or_UEFI.xml
index 7b7a266..e4ee56d 100644
--- a/en-US/BOOT-BIOS_or_UEFI.xml
+++ b/en-US/BOOT-BIOS_or_UEFI.xml
@@ -73,4 +73,10 @@ Windows
</para>
</listitem>
</itemizedlist>
+ <important>
+ <title>Be Consistent!</title>
+ <para>
+ Be consistent with your booting methods when using multiple operating systems. If Windows is installed with UEFI, do not install Fedora in legacy BIOS compatibility mode. Installing all of your operating systems as either UEFI or BIOS booting will ensure that you can boot them all.
+ </para>
+ </important>
</section>
diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 5fff237..0104da2 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -14,7 +14,7 @@
</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>
<para>
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>
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>
Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
>---------------------------------------------------------------
commit 41142974f7ae3a2b781633f5686e816760737c6c
Author: Pete Travis <immanetize(a)fedoraproject.org>
Date: Sat May 30 11:58:20 2015 -0600
trim down UEFI-win.xml, save the rest for later reorganization
>---------------------------------------------------------------
en-US/{UEFI-win.xml => UEFI-win-detailed.xml} | 0
1 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win-detailed.xml
similarity index 100%
copy from en-US/UEFI-win.xml
copy to en-US/UEFI-win-detailed.xml
Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
>---------------------------------------------------------------
commit 610321a84348bbb05d20a226d5f941cbbee527f0
Author: Pete Travis <immanetize(a)fedoraproject.org>
Date: Sat May 30 10:57:41 2015 -0600
markup fix, note about apple
>---------------------------------------------------------------
en-US/GRUB-reinstalling.xml | 2 +-
en-US/UEFI-apple.xml | 7 ++++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/en-US/GRUB-reinstalling.xml b/en-US/GRUB-reinstalling.xml
index c2f8ef8..94a906b 100644
--- a/en-US/GRUB-reinstalling.xml
+++ b/en-US/GRUB-reinstalling.xml
@@ -76,7 +76,7 @@
Exit the chroot before creating the EFI boot entry.
</para>
<screen>
-<screen>#</prompt> exit
+<prompt>#</prompt> exit
</screen>
<substeps>
<step>
diff --git a/en-US/UEFI-apple.xml b/en-US/UEFI-apple.xml
index 8dc3561..fcaf68a 100644
--- a/en-US/UEFI-apple.xml
+++ b/en-US/UEFI-apple.xml
@@ -6,5 +6,10 @@
]>
<section id="UEFI-apple">
<title>Booting on Apple systems</title>
- <para />
+ <para>
+ This section needs help! If you would like to contribute content, you can contact the Fedora Docs team via <ulink url="https://lists.fedoraproject.org/pipermail/docs/">the Docs mailing list</ulink>.
+ </para>
+ <para>
+ If you would like to request content, file a bug via &BZURL;
+ </para>
</section>