[multiboot-guide] master: Parted out material. Reached rough draft stage (563298c)
immanetize at fedoraproject.org
immanetize at fedoraproject.org
Tue Jan 6 03:38:56 UTC 2015
Repository : http://git.fedorahosted.org/cgit/docs/multiboot-guide.git
On branch : master
>---------------------------------------------------------------
commit 563298c157472c368b55bf5d80dd7f323361536f
Author: Roger Baran <rapidrecoveryit at gmail.com>
Date: Tue Sep 30 15:57:29 2014 -0500
Parted out material. Reached rough draft stage
>---------------------------------------------------------------
en-US/UEFI-win.xml | 215 +++++++++++++---------------------------------------
1 files changed, 52 insertions(+), 163 deletions(-)
diff --git a/en-US/UEFI-win.xml b/en-US/UEFI-win.xml
index 95a1389..cf3bc02 100644
--- a/en-US/UEFI-win.xml
+++ b/en-US/UEFI-win.xml
@@ -7,11 +7,14 @@
<section id="UEFI-win">
<title>Introduction</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 in all environments; including Secure Boot.
+ 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 many different environments; including desktops, laptops (with or without Secure Boot enabled) and Apple/Macintosh based computers.
</para>
<para>
- This article begins by covering both the Windows and Fedora UEFI boot process in general. From there, it moves on to explain the specifics of both standard and Secure Boot modes.
+ This article begins by covering the more general aspects of the Windows and Fedora UEFI boot process; such as the files involved, their purposes, and locations. The next few sections deal with the similarities and the differences in the UEFI boot process for both operating systems. From there, the UEFI boot process is explained in detail. The final section covers how Fedora successfully handles a Secure Boot environment.
+</para><para>
+ We hope that you will find this information both interesting and helpful. With the information outlined in 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. 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>
<section id="Boot_Manager_vs_BootLoader">
<title>Boot Managers and Boot Loaders Defined</title>
<para>
@@ -46,7 +49,7 @@
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 GRUB2's <filename>bootx64.efi</filename> 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. GRUB, on the other hand, has an alternative methods for booting, which is implemented using <filename>bootx64.efi</filename> as well as a GRUB command prompt. This is all explained in detail below.
+ The main difference is that GRUB2's <filename>bootx64.efi</filename> 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. GRUB, on the other hand, has alternative methods for booting, which is implemented using <filename>bootx64.efi</filename> as well as a GRUB command prompt. This is all explained in detail below.
</para>
</section>
<section id="BCD_vs_GRUB">
@@ -55,13 +58,13 @@
BCD, by default, only knows about ONE installation (Windows); which it boots by loading winload.efi
</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. bootmgrfw.efi, using BCD, is designed to handle Windows. Period. It provides a straight shot to the Windows installation and that's it.
+ 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).
</para>
<para>
- GRUB2, on the other hand, is designed from the gound up to handle all forms of operating systems.
+ 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 (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.
+ 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>
</section>
<section id="Windows_EFI_Files">
@@ -86,12 +89,50 @@
<para>
<filename>bootmgrfw.efi</filename> is called at every boot into windows and, after reading the <filename>BCD</filename> to determine the location of the windows installation, goes straight to loading windows via its boot loader -- <filename>winload.efi</filename>.
</para>
+ <para>
+ GRUB2, on the other hand, takes advantage of two additional processes to boot: Default Boot Behavior (which includes the fallback process as outlined below) and a GRUB command prompt.
+ </para>
+ <section id="If_You_Must">
+ <title>Using BCD to dual boot</title>
+ <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.
+ </para>
</section>
-<section id="GRUB_EFI_Files">
- <title>GRUB EFI Partition Files</title>
+<section id="Fedora_EFI_Files">
+ <title>Fedora EFI Partition Files</title>
+ <para>
+ The below listed files are all found within the Fedora-created EFI partition:
+ </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>
+ ./EFI/fedora/gcdx64.efi: used to boot live media; called by shim.</para>
+ </listitem><listitem>
+ <para>
+ ./EFI/fedora/grubx64.efi: This is the main GRUB executable signed with Fedora's key.</para>
+ </listitem><listitem>
+ <para>
+ ./EFI/fedora/shim-fedora.efi: This is the file that performs the signing mechanism for grubx64.efi in a Secure Boot scenario</para>
+ </listitem><listitem>
+ <para>
+ ./EFI/fedora/shim.efi: This is the version of shim that's signed with Microsoft's key.</para>
+ </listitem>
+</orderedlist>
<para>
- <!-- Comment Listing of GRUB2 files and their purposes here.... -->
- </para><para>
GRUB2 takes advantage of two additional processes to boot: Default Boot Behavior (which includes the fallback process as outlined below) and a GRUB command prompt.
</para>
</section>
@@ -113,7 +154,7 @@
</para><para>
It is the <filename>fallback.efi</filename> application that enumerates the various <filename>boot.csv</filename> files 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 BootNext variable.
</para><para>
- The Default Boot Behavior, with initiates fallback, happens in the event that any of the following conditions are met:
+ The Default Boot Behavior, which initiates fallback, happens in the event that any of the following conditions are met:
<orderedlist>
<listitem>
<para>
@@ -128,7 +169,6 @@
</para>
</listitem>
</orderedlist>
- </para>
<para>
Before moving on, I would like to add a few notes to help clariy the above information:
</para>
@@ -192,154 +232,6 @@
</para>
</section>
<!-- comment
- 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 ins
erted. 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.
-
- 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.
- /dev/sda1/boot/EFI will already have directories for Boot and Microsoft; you will be adding in the fedora directory sturcture at that location.
-
- 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/
-
- However! Please keep reading!
-
- 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.
- ./EFI/fedora/gcdx64.efi: used to boot live media; called by shim.
- ./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.
-
-
- Using df -H:
-
-root at localhost /: df -H
-Filesystem Size Used Avail Use% Mounted on
-/dev/mapper/fedora-root 62G 8.0G 51G 14% /
-devtmpfs 4.2G 0 4.2G 0% /dev
-tmpfs 4.2G 189k 4.2G 1% /dev/shm
-tmpfs 4.2G 1.2M 4.2G 1% /run
-tmpfs 4.2G 0 4.2G 0% /sys/fs/cgroup
-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)
-Disk /dev/sda: 1000GB
-Sector size (logical/physical): 512B/4096B
-Partition Table: gpt
-Disk Flags:
-Number Start End Size File system Name Flags
- 1 1049kB 525MB 524MB fat32 EFI System Partition boot
- 2 525MB 567MB 41.9MB fat32 Basic data partition
- 3 567MB 701MB 134MB fat32 Microsoft reserved partition msftres
- 4 701MB 1488MB 786MB ntfs Microsoft recovery partition hidden, diag
- 5 1488MB 753GB 752GB ntfs Basic data partition
- 7 753GB 753GB 210MB fat16 EFI System Partition boot
- 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"
-/dev/sda2: LABEL="DIAGS" UUID="3AEE-450D" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="d6e615b6-5622-49b5-b1a8-26fc2c292ace"
-/dev/sda3: UUID="3015-2D1B" TYPE="vfat" PARTLABEL="Microsoft reserved partition" PARTUUID="635e137d-cd6f-407d-bcc6-a4910caf4c1f"
-/dev/sda4: LABEL="WINRETOOLS" UUID="6CA219D3A219A31E" TYPE="ntfs" PARTLABEL="Microsoft recovery partition" PARTUUID="7c6fb1d0-c57f-4406-9dbd-48aa944eb7f6"
-/dev/sda5: LABEL="OS" UUID="A0C4A657C4A63008" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="10d5a99c-e2c2-4b33-a795-2444cd59b339"
-/dev/sda6: UUID="C21C237B1C236A1D" TYPE="ntfs" PARTLABEL="Microsoft recovery partition" PARTUUID="e986d425-2360-43e0-828f-833aa84a4fd7"
-/dev/sda7: SEC_TYPE="msdos" UUID="E085-2C94" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="2c746a4d-6539-4553-9ebb-b7b9603c446f"
-/dev/sda8: UUID="4821d546-440e-47da-8272-50a97f711c3e" TYPE="ext4" PARTUUID="081594eb-5430-49b0-a068-7759bc62130e"
-/dev/sda9: UUID="c32b5719-857f-48fb-a782-6086dd05d008" TYPE="crypto_LUKS" PARTUUID="9ce3fa3d-f995-4327-9989-520f938b6d5a"
-/dev/mapper/luks-c32b5719-857f-48fb-a782-6086dd05d008: UUID="XRrOfA-n5wr-FdY2-oT8D-sLr9-hziR-UugtSv" TYPE="LVM2_member"
-/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
-#
-# /etc/fstab
-# Created by anaconda on Sat Sep 20 20:40:25 2014
-#
-# Accessible filesystems, by reference, are maintained under '/dev/disk'
-# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
-#
-/dev/mapper/fedora-root / ext4 defaults,x-systemd.device-timeout=0 1 1
-UUID=4821d546-440e-47da-8272-50a97f711c3e /boot ext4 defaults 1 2
-UUID=E085-2C94 /boot/efi vfat umask=0077,shortname=winnt 0 0
-/dev/mapper/fedora-home /home ext4 defaults,x-systemd.device-timeout=0 1 2
-/dev/mapper/fedora-swap swap swap defaults,x-systemd.device-timeout=0 0 0
-~
-~
-"/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
-~
-~
-~
-
-"/etc/crypttab" 1L, 90C
-
-
-Copying the Fedoara-created ESP files to the Microsoft-created ESP (for whatever reason)
-
-# cd /mnt
-# mkdir msftesp
-# mount /dev/sda1 /mnt/msftesp
-# cd /boot/efi/EFI
-# cp -r * fedora /mnt/msftesp
-
-Verify the copy...
-
-# cd /mnt/msftesp
-# ls
-# cd fedora
-# ls
-# cd /
-# umount /mnt/msftesp
-# rm -r -f /mnt/msftesp
-
-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' {s
-
- insmod part_gpt
- insmod msdos
- set root='hd0,gpt1'
- chainloader /EFI/Microsoft/Boot/bootmgfw.efi
- boot
-}
-
-
Refs:
http://www.rodsbooks.com/efi-bootloaders/index.html
@@ -361,6 +253,3 @@ 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 -->
-
-
-</section>
More information about the docs-commits
mailing list