[multiboot-guide] master: Editing and sectioning off in prepartation for parting to other articles as necessary (27ece5f)
immanetize at fedoraproject.org
immanetize at fedoraproject.org
Tue Jan 6 03:38:50 UTC 2015
Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
>---------------------------------------------------------------
commit 27ece5fc123c333a90d1debe116e82fa5ed116a2
Author: Roger Baran <rapidrecoveryit at gmail.com>
Date: Sat Sep 27 10:52:43 2014 -0500
Editing and sectioning off in prepartation for parting to other articles as necessary
>---------------------------------------------------------------
en-US/UEFI-win.xml | 74 ++++++++++++++++++++++++++++++++-------------------
1 files changed, 46 insertions(+), 28 deletions(-)
diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 1fb6fd3..3ad4f71 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -7,19 +7,25 @@
<section id="UEFI-win">
<title>Booting with Windows</title>
<para>
- The good news is that 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 in all environments; including Secure Boot.
+ Intro:
- This article will cover the UEFI boot process in general, as well as how both Fedora and Windows boot in both standard UEFI and Secure Boot modes. Finally, it will cover how you can use Fedora's GRUB2 to multiboot all of the OS's you wish to install.
+ 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 in all environments; including Secure Boot.
- Notes:
- Discuss the definition and differences between boot managers and boot loaders.
+ This article will cover the UEFI boot process in general, as well as how both Fedora and Windows boot in both standard UEFI and Secure Boot modes. Finally, it will cover how you can use Fedora's GRUB2 to multiboot all of the OS's you wish to install.
+ -------------------------------------------------------------------------------
+ The Difference Between a Boot Manager and a Boot Loader:
+ Discuss the definition and differences between boot managers and boot loaders:
Boot Manager: A utility that allows multiple operating systems to be booted from the same computer
Boot Loader: The program that calls the operating system into memory
GRUB2 acts as both a Boot Manager and a Boot Loader
--------------------------------------------------------------------------------
- Microsoft uses bootmgr.efi and bootmgrfw.efi as boot managers; bootmgr.efi is the 32 bit version and bootmgrfw.efi is the 64 bit version. These EFI applications then call winload.efi as the boot loader. winload.efi is located at /WINDOWS/System32/Boot.
+ Files within the Microsoft EFI Partition:
+ Microsoft uses bootmgr.efi and bootmgrfw.efi as boot managers; bootmgr.efi is the 32 bit version and bootmgrfw.efi is the 64 bit version. Both of these files are located in the root directory of the Microsoft-created EFI partition (usually found at /dev/sda1). For EFI compatibility, they are both located at /EFI/Microsoft/Boot/ as well. These EFI applications then call winload.efi as the boot loader. winload.efi is located at /WINDOWS/System32/Boot.
- While you could say that bootmgrfw.efi acts in the same way as GRUB2 there are technical differences that show this not to be the case.
+ Other files found withing the /EFI/Microsoft/Boot directory structure are the BCD (a registry formatted configuration file), sub-directoris for language files, a memory test efi application, and the BCD log files. The BOOTSTAT.DAT file is used to flag whether a recovery mode is required. Mui stands for Multilingual User Interface and the *.mui files located in the bg-BG sub-directory are used to provide language support in other-than-english installations. There isn't any information at all on what boot.stl is or what functions it may perform.
+ ---------------------------------------------------------------------------------
+ Similarities and Differences Between bootmgrfw.efi and bootx64.efi:
+ While you could say that bootmgrfw.efi acts in the same way as GRUB2 there are technical differences that show this not to be the case.
Explanation:
bootmgrfw.efi is roughly equivilent to GRUB2's bootx64.efi (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...
@@ -31,7 +37,7 @@
On EFI firmware-based PC's it is located at \EFI\Microsoft\Boot\
BCD is actually formatted as a registry hive and is therefore totally Microsoft-centric. While BCD can be configured to boot other OS's, it cannot be done without a certain measure of difficulty and an even greater level of un-dependability after reboots.
- BCD contains configuration data that controls the operation of Microsoft's boot manager.
+ BCD contains configuration data that controls the operation of the Microsoft's boot manager.
Boot.csv contains entries that will be added to the EFI NVRAM by fallback.efi; which is called by bootx64.efi.
If BCD is missing, or corrupt, you can't boot into Windows.
@@ -45,15 +51,16 @@
GRUB2's bootx64.efi, on the other hand, scans the entire EFI partition looking for Boot.csv files in each sub-directory within the EFI partition. Everytime it finds one, it creates and appends an entry in the EFI NVRAM and changes the NextBoot variable to point to the first one it found. When finished, it directs execution back to EFI Boot Manager to boot using the NextBoot variable. This process is sometimes referred to as "fallback" but it is a standard part of the EFI specification under such circumstances and is called the "Default Boot Behavior" by that specification. "Default Boot Behavior" specifically refers to the loading of \EFI\Boot\bootx64.efi.
This happens in the event that there are either no existing NVRAM entires for any installed operating systems, that the entries that were listed in the BootOder resulted in a 'no boot' situation from all installed, fixed devices, or that your removable device settings in your EFI Boot Order Priority are such that removable devices (USB's, Live media, etc) are listed above your installed OS's -- in which case (as noted below) the expected directory structure for normal EFI booting is not present.
-
- Note 1:
+ --------------------------------------------------
+ What is Fallback and How Does it Work?
The reason it is referred to as "fallback" is because, bootx64.efi will look to see if fallback.efi is in the same directory as itself, and if it is, will execute it as an EFI application. It is the fallback.efi application that enumerates the various boot.csv's that it finds, creates and appends the EFI NVRAM entries, and finally, passes control back to the EFI Boot Manager to boot the first entry it created; which, as mentioned earlier, it does by changing the NextBoot variable.
In other words, the "Default Boot Behavior" (looking for removable devices to boot from by searching for and calling \EFI\Boot\bootx64.efi) provides a way to place boot entries into the EFI NVRAM by a process that uses an EFI application, typically called fallback.efi.
-
- Note 2:
+ ------------------------------------------------------------------------
+ Booting Live Media in EFI:
As indicated above, this is the way that removable media gets listed in the NVRAM for booting. LiveCD's, as well as other Live Media (USB, etc.) are missing the standard directory structure called for in the EFI specifications -- unless an OS has actually been installed to that device (such as a USB). Since that directory sturcture is not there, it won't be added to the EFI Boot Manager menu until removable devices are enumerated. Removable devices are enumerated -- usually -- after the BootOrder list has been exhausted without a boot. However, removable device enumeration will take place before you are presented with the EFI Boot Manager menu when you hold down the correct key (while powering on) to enter the EFI firmware screen. You will notice a short delay in getting into the EFI Settings page whenever you press the 'magic' key during power on. That is because the removable device enumeration process is occurring and adding entries for any/all removable media that may
be inserted. Once the enumeration process has completed, the EFI will halt the boot process and you are presented with the EFI Boot Manager Menu from which you can make your selection.
----------------------------------------------------
+ More Details on EFI's Default Boot Behavior:
One caveat to all that has been said about "Default Boot Behavior":
If you already have installed OS's on your system that will boot normally....
And you want "Default Boot Behavior" to boot your removable media...
@@ -65,22 +72,21 @@
If you do not have any installed OS's on your system...
Just plug in removable media that meets the criteria for EFI "Default Boot Behavior" and turn it on.
-
- End of caveat
------------------------------------------------------
+ BCD's Limitations vs GRUB's universality:
BCD, by default, only knows about ONE installation (Windows); which it boots by loading winload.efi
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. bootmgrfw.efi, using BCD, is designed to handle Windows. Period. It provides a straight shot to the Windows installation and that's it.
GRUB2, on the other hand, is designed from the gound up to handle all forms of operating systems.
Under normal boot operations, the GRUB2 manager/loader (grubx64.efi) is called directly (via shim.efi in Secure Boot), which then reads the grub.cfg file and displays its entries for user intervention.
- =====================================
- EFI BOOT SEQUENCE:
+ -----------------------------------------------------
+ EFI Boot Sequence Explained:
Two scenarios:
1. How EFI handles a normal boot cycle - no intervention.
2. What happens when you press the appropriate key to enter the EFI Settings prior to a successful boot of an operating system.
- -----------------------------
+ -----
First, EFI attempts each entry in the order listed in its BootOrder variable.
It will boot the first entry that 'works' with the data listed for that entry.
A typical entry is in the format of:
@@ -104,6 +110,7 @@ In any event, EFI will boot to the first device it can either find on its own, o
When you enter the "EFI Settings" of your computer and look at the menu, all of that enumeration is complete before the menu is displayed. All you then have to do is select which device you wish to boot from and hit Enter.
-------------------
+ Using BCD to Dual-Boot:
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.
@@ -115,6 +122,8 @@ When you enter the "EFI Settings" of your computer and look at the menu, all of
Note!: There are reports that Microsoft, 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 shim.efi 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. Letting Anaconda create, and use, a separate EFI partition ensures that what has happened to others will not happen to you.
----------------------------------------------
+ File reference, example information for further use in explaining other aspects of multibooting and repairing an installation...
+
FIles listing for EFI partition created by Fedora:
./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.
@@ -122,9 +131,8 @@ When you enter the "EFI Settings" of your computer and look at the menu, all of
./EFI/fedora/grubx64.efi -- This is the main GRUB executable signed with Fedora's key.
./EFI/fedora/shim-fedora.efi -- This is the file that performs the signing mechanism for grubx64.efi in a Secure Boot scenario
./EFI/fedora/shim.efi -- This is the version of shim that's signed with Microsoft's key.
- ----------------------------------------------
-
- File system stuff:
+ --------------------------------------------------------------------------------
+ Using df -H:
root at localhost /: df -H
Filesystem Size Used Avail Use% Mounted on
@@ -137,6 +145,8 @@ tmpfs 4.2G 58k 4.2G 1% /tmp
/dev/sda8 500M 104M 366M 23% /boot
/dev/sda7 210M 10M 200M 5% /boot/efi
/dev/mapper/fedora-home 162G 26G 128G 17% /home
+----------------------------------------------------------------------------------
+Using parted print:
root at localhost /: parted /dev/sda print
Model: ATA TOSHIBA MQ01ABD1 (scsi)
@@ -154,6 +164,8 @@ Number Start End Size File system Name Flags
8 753GB 754GB 524MB ext4
9 754GB 989GB 235GB
6 989GB 1000GB 10.8GB ntfs Microsoft recovery partition hidden, diag
+------------------------------------------------------------------------------
+Using blkid:
root at localhost /: blkid
/dev/sda1: LABEL="ESP" UUID="6481-E0BE" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="dfb7601a-7aab-4cd5-9469-50ea6d52c429"
@@ -169,6 +181,9 @@ root at localhost /: blkid
/dev/mapper/fedora-root: UUID="6302bae0-5a18-4fdb-84da-a83bf512ad82" TYPE="ext4"
/dev/mapper/fedora-swap: UUID="7a4fabaf-3385-40c3-822f-b3ba3d33caaf" TYPE="swap"
/dev/mapper/fedora-home: UUID="96872f18-6312-43ea-a177-447fdbee98df" TYPE="ext4"
+------------------------------------------------------------------------------
+Looking at fstab entries;
+Modifying fstab:
root at localhost /: vi /etc/fstab
#
@@ -186,6 +201,9 @@ UUID=E085-2C94 /boot/efi vfat umask=0077,shortname=win
~
~
"/etc/fstab" 13L, 688C
+-----------------------------------------------------------------------------
+Looking at crypttab;
+Modifying crypttab:
root at localhost /: vi /etc/crypttab
luks-c32b5719-857f-48fb-a782-6086dd05d008 UUID=c32b5719-857f-48fb-a782-6086dd05d008 none
@@ -194,7 +212,7 @@ luks-c32b5719-857f-48fb-a782-6086dd05d008 UUID=c32b5719-857f-48fb-a782-6086dd05d
~
"/etc/crypttab" 1L, 90C
-==========================
+----------------------------------------------------------------------------
Copying the Fedoara-created ESP files to the Microsoft-created ESP (for whatever reason)
# cd /mnt
@@ -212,24 +230,27 @@ Verify the copy...
# cd /
# umount /mnt/msftesp
# rm -r -f /mnt/msftesp
-
-Make an EFI entry...
+------------------------------------------------------------------------------
+Make an EFI entry:
# efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi -L Fedora
-
-===============================
+ -----------------------------------------------------------------------------
A proper Windows GRUB entry:
Place inside the 'custom' section...
-menuentry 'Windows Boot Manager - Windows 8.1' {
+menuentry 'Windows Boot Manager - Windows 8.1' {s
+
insmod part_gpt
insmod msdos
set root='hd0,gpt1'
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
boot
}
+-----------------------------------------------------------------------------------
+Refs:
<!-- comment url: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/
@@ -248,8 +269,5 @@ 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>
</section>
More information about the docs-commits
mailing list