Multi Boot System – RetiredTechie Take

Published on November 30, 2023 at 8:41 pm by LEW


Recently I dual booted my MSI Raider GE76 laptop, and it was an experience. I don’t mean that in a totally negative way, because I always learn so much from those “Experiences”.

Now I have dual and triple booted many different computers, but this one did not want to cooperate in the least. This usually means either I have forgotten something very basic, or I am not taking everything into consideration that I should.

To resolve the issue, I went back to the basics of the whole dual boot process. I did my research, tested my hypothesizes, and came to an interesting conclusion. While much of the information I read was not technically wrong, it tended to apply to specific cases. Generally speaking it did not translate well to other different cases.

So in this post I want to forget about cases for the most part and revisit the basics of multi booting. I say this for the most part, as I am going to focus on UEFI based systems (a specific case), and not look back to legacy MBR systems. So if you have a legacy MBR multi boot issue, this is probably not the post to read.

Basics of UEFI Booting

It is hard buy a computer without UEFI these days. So it behooves us to understand how it works. So lets get down to the basics, in simple layman’s terms.

UEFI (Unified Extensible Firmware Interface) is a specification or standard put forth by the UEFI Forum. For ones computer to use UEFI, the system board must have firmware installed that conforms to the specification.

When your computer starts it runs the UEFI firmware. This firmware checks the various systems, and provides various functions before handing off operations to a bootloader, that actually starts your Operating System (OS).

The boot loader resides on a special partition of your hard drive. The firmware scans all drives for this special EFI System Partition, and locates any and all boot loaders. If there is no facility within the firmware to decide which boot loader to use, in case of multiple boot loaders, the firmware will most likely boot from the first one it finds.

The bootloader is the program that starts the OS, then hands control over when the OS is up and running.

Drive Setup

Since we are using the UEFI specification, our drives need to be setup as GPT (GUID Partition Table). GUID stands for Globally Unique Identifier. This is considered to be a better way to identity drives and partitions as the identifier strings are considered unique (it is possible to have duplicate IDs, but statistically the chances are close to zero).

A boot loader is stored in an EFI System Partition on a GPT drive. You do not need to have an EFI System Partition on a GPT drive. It is only required if you want to store boot loaders on that drive.

An EFI System Partition can contain multiple boot loaders, so generally only one is required per system. However the EFI firmware should scan any and all EFI System Partitions it finds on multiple drives that are setup that way.

Multiple Boot Loaders

How your system handles multiple boot loaders is dependent on the EFI firmware installed. For example on the laptop I am working with currently, there is a section in the EFI Firmware interface (on old systems this was the BIOS interface) that lists all fond boot loaders, and sets the order in which they are executed. This is in addition to the boot order priority, which is only concerned with physical drives and devices.

As an example I currently have both a Windows and a Linux boot loader listed. If I go into the EFI interface I can set which boot loader runs by making it first on the list.

Chaining Boot Loaders

You probably do not want to go into the EFI Firmware screens every time you want to boot to a different OS. Some boot loaders, like GRUB (GRand Unified Bootloader) can chain to a different boot loader. Unfortunately the Windows boot loader does not have this capability.

As an example, on my system I have GRUB first in the boot loader order, so it always runs. If setup properly, there is an entry in the grub screen for the Linux OS and one for the Microsoft OS. Choosing the Microsoft OS causes GRUB to start the Microsoft Boot Loader and transfer control (chain to it). This way you get access to multiple OSs through one boot loader.

Example 1 Arch EFI mount to /boot

There are generally two methods suggested in most Arch installation documentation for how to use the EFI directory. In this first example, the EFI system Partition is mounted to the /boot folder of the root file system. In my experience this is the most prevalent method suggested.

EFI mounted to /boot

In this method, the EFI System Partition is mounted to the /root file tree via the /etc/fstab file. With this method the EFI System partition is mounted every time the computer starts, and is the /boot folder. Because it is mounted as /boot, it will contain, in addition to the EFI files, the grub directory and the Linux init image files.

Example 2 Arch EFI mount to /boot/efi

This is my preferred method. Unless one is modifying the boot loaders, there is no reason the EFI System Partition needs to be mounted at all. The EFI firmware accesses the bootloader before the file system is setup. It then chains to the kernel init image, also before the file system is setup.

separate boot loader

In this method, the EFI System Partition does not appear in the fstab file, and is not mounted. During installation, it is mounted to an empty folder temporarily (I use /boot/efi). Once grub is setup, and the os prober has found any other OS (EFI System Partition needs to be mounted for this to happen), it no longer needs to be mounted.

In this method the grub files and the Linux boot image are in the /boot folder, and not on the EFI System Partition.


We have taken a look at UEFI and the EFI System partion in general, and how the EFI System Partition is setup in Arch Linux specifically. It is my hope that the above can clarify some of the information presented in other procedures. Understanding the process form a procedure has been difficult for me in the past.

Add New Comment

Your email address will not be published. Required fields are marked *