Introduction

Let’s talk about EFI partitions, and how they’ve replaced BIOS booting. If you’re old enough to remember the turn of the millennium, you’re probably familiar with a computer’s BIOS. Specifically, how to navigate BIOS screens and tell it which device (hard drive 1, hard drive 2, cd-rom, flash drive, etc) you’d like the computer to boot an operating system from. Once the computer knew which device to boot from, it could examine the drive’s Boot Sector for its Master Boot Record (MBR), which was effectively a list of exactly where on the disk different operating systems could be loaded from.

Simplified BIOS Boot Flow

This method for booting was straight forward. It allowed tinkerers to easily manipulate the MBR when they wanted to boot their computer into different operating systems. A couple of popular/familiar tools for managing the MBR include GRUB and Windows Boot Manager. However, the computer industry moves rapidly, and by the early aughts, computer hardware development was being hindered by limitations inherent to BIOS booting (specifically, the fact that BIOS could not boot to partitions larger than 2 TB). Development ensued. Fast-forward to 2012, and EFI was was more or less standard across the industry.

In a fundamental sense, how does EFI differ from BIOS? Imagine that your motherboard has an internal SD-card, similar to a modern smartphone. That means it’s accessible, readable, and editable by the right software. It can even store critical variables that can then later be recognized and utilized by EFI-aware operating systems. In this way, hardware details and specifics can be managed by motherboard firmware and remain agnostic of operating systems later installed. The EFI is effectively a micro-operating system that initially boots when your computer turns on. From there, the EFI bootmanager is examined. It will include at least one file that effectively reads “operating system X in installed on drive Y, look at partition Z for further boot instructions”. Partition Z is then regarded, and its boot instructions are followed. For WAY more explanation, refer to this post by Adam Williamson.

Simplified EFI Boot Flow

If you’ve examined your hard drive partition table in the last couple years, you’ve probably seen a small 100MB partition sitting at the front of the disk. That’s the EFI system partition, and it contains specific boot details that relate to your operating system (for Windows, that’s where the product code is stored for example).

Okay, so how do you manipulate the information on the EFI partition on your disk? I’m going to assume we’re dealing with Windows here, as someone familiar with Linux has likely done this sort of thing 10,000 times. What we want to do is mount the EFI partition by assigning it a drive letter. Next, we’ll use a file explorer to examine its contents.

Mount the EFI partition

1. Open a command prompt with Admin Privileges



2. diskpart
3. list disk to see all the disks installed on your system
4. select disk 0, or whichever disk you happen to know your operating system is installed on
5. list partition to see all the partitions on the selected disk
6. select partition X where X is the partition number of Type System, which is likely 100 MB and is likely partition 1
7. assign letter=X where X is the drive letter (I use B)
8. exit to close the diskpart tool and return to a regular command prompt
9. taskkill /im explorer.exe /f to terminate the explorer process, so that it can be reloaded momentarily
10. explorer.exe

Assuming all went well, you should have a new “drive” show up under My Computer. However, if you attempt to access the drive, you’ll encounter a Windows error that informs you you’re not secure enough to access the files. Sure, whatever.

Use An Alternate File System Explorer

Here’s where you’ll need to download a third-party file system explorer. The one that I’ve found to be extremely useful and versatile is Explorer++. Download either the 32 or 64 version of Explorer++, whichever matches your system.

When you run this alternative file system explorer, you’ll have full access to the EFI partition!

Here’s where this gets fun/frustrating. In my example above, you’ll notice that there are 4 folders. There’s also a README.txt, and a file named bootx64.efi.backup at the root level within the EFI folder.

Both the bootx64.efi.backup and README.txt files were placed in this partition by me. Astutely, I left these breadcrumbs for myself when I first delved into this years ago! Do yourself a favor and do the same by leaving a link to this post in this EFI directory. I bring this up, because it helps to highlight the fact that this is really not much different than any other partition your system reads/writes to, it just has a special purpose.

Lessons Learned

If you look in the Boot folder, you’ll see a file that’s named something like bootx64.efi. This is the file responsible for launching your operating system, and as you might imagine – it’s the target of all kinds of fuckery from both hardware and software manufacturers. Here are a couple critical pieces of information I’ve learned having messed with my system for the past 2 years:

1. This is my work computer. It’s an HP, and it came pre-loaded with Windows 10. I can’t speak for every implementation, but in this system, HP/Windows 10 are very hesitant to give up control of this file. If you make an attempt to modify this file by say, replacing it with a different file that points to a linux OS instead, when you boot into Windows, that .efi file will be updated and replaced with the original. In other words, you can’t a linux .efi, rename it to bootx64.efi. Then, place it in the Boot folder, and expect to have an effective dual-boot environment.
2. Any time you go through a substantial system update to Windows, it will re-write the EFI partition to ensure it boots exclusively and without issue.
3. Once your linux flavor has been installed, and it’s written its respective folder to the EFI partition (ubuntu, in the case above), you’ll have to tell Windows to use the Linux GRUB bootloader instead of its own, since the GRUB bootloader allows you to selectively launch whichever OS you’d like.

Force Windows to use GRUB

To the second point above, you’ll tell Windows to use the GRUB bootloader by executing the following:

1. Open a command prompt, as an administrator, the same as before
2. Type bcdedit /enum firmware to show a list of all the devices on your system and their respective launch paths. Source: https://askubuntu.com/a/655279
3. Note the location of the ubuntu loader, in my case \EFI\ubuntu\shimx64.efi



4. Type bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi, or possibly \EFI\ubuntu\grubx64.efi depending on the last result

After you’ve tackled that entire process, restart your computer. You’ll now be able to choose which OS you’d like to boot into!