[multiboot-guide] master: Edit for appearance and increased clarity (0d6ec68)
immanetize at fedoraproject.org
immanetize at fedoraproject.org
Tue Jan 6 03:39:16 UTC 2015
Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
>---------------------------------------------------------------
commit 0d6ec68f3003e7bff9b0a36cd6655bdd195ea08e
Author: Roger Baran <rapidrecoveryit at gmail.com>
Date: Sat Oct 4 14:09:06 2014 -0500
Edit for appearance and increased clarity
>---------------------------------------------------------------
en-US/UEFI-win.xml | 88 +++++++++++++++++++++++++++++----------------------
1 files changed, 50 insertions(+), 38 deletions(-)
diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index eb7d2ff..3f62612 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -11,13 +11,13 @@
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.
+ 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 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/" />
+ 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>
@@ -35,17 +35,18 @@
<literal>Boot Loader:</literal> The program that calls the operating system into memory
</para>
</listitem>
- <listitem>
+ </orderedlist>
<para>
- <literal>GRUB2</literal> acts as both a Boot Manager and a Boot Loader
+ 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>
- </listitem>
- </orderedlist>
</section>
<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. These EFI applications then call <filename>winload.efi</filename>; which is the Windows Boot Loader. <filename>winload.efi</filename> is located at <filename class="directory">/WINDOWS/System32/Boot</filename>.
+ 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.
@@ -54,7 +55,10 @@
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 information at all on what <filename>boot.stl</filename> is or what functions it may perform.
+ 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">
@@ -65,27 +69,27 @@
<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.
+ <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>
- ./EFI/fedora/gcdx64.efi: Used to boot live media; called by shim.
+ <filename>./EFI/fedora/gcdx64.efi</filename>: Used to boot live media; called by shim.
</para>
</listitem>
<listitem>
<para>
- ./EFI/fedora/grubx64.efi: The main GRUB executable (signed with Fedora's key for Secure Booting).
+ <filename>./EFI/fedora/grubx64.efi</filename>: The main GRUB executable (signed with Fedora's key for Secure Booting).
</para>
</listitem>
<listitem>
<para>
- ./EFI/fedora/shim-fedora.efi: Performs the signing mechanism for grubx64.efi in a Secure Boot scenario
+ <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>
- ./EFI/fedora/shim.efi: This a Microsoft signed stub to allow booting using Secure Boot on 'Windows Ready Certified' computers.
+ <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>
@@ -96,6 +100,9 @@
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>
@@ -103,16 +110,16 @@
<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.
+ <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.
+ 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 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.
+ 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.
@@ -121,75 +128,80 @@ Fedora's <filename>shim.efi</filename> is a code stub that has been signed by Mi
<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.
+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, 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.
+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>
- 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".
+ 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 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.
+ 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>
- 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.
+ 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 GRUB2 there are technical differences that show this not to be the case.
+ 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 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...
+ <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>
+ 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>
- 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.
+ 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 in detail below.
+ 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 GRUB2 Universality</title>
+ <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 <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).
+ 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.
</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.
+ 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 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" />
+ 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>
-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:
+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>, 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.
+ 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 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>
+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 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.
+ <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
More information about the docs-commits
mailing list