Just how bad would it be to have multiple EFI partitions on a disk for dual boot?

I’ve been looking into dual booting on my old MSI Gs70 gaming laptop when Pop!_OS 21.10 officially releases. I’ve technically been dual booting through a kind of hacky way since it had an HDD where I was would mess around in MX_Linux, but I’m interested in dual booting through the main drive (Well raid array. Old msi laptops are weird) just to say I could do it and have it work. My plan is to eventually delete the windows partition as windows 8.1 will no longer receive extended support in about a years time, plus the laptop doesn’t have tmp 2.0 chip so windows 11 is out of the question.

The only problem is that the EFI partition for my laptop is only about 300MB while pop OS recommends 500MB or so. Microsoft’s Reserved Partition (MSR). From what I’ve gathered is my options are to either:

  1. Create a second EFI partition only for Pop!_OS. Not the cleanest method but has worked when installing other distros to the HDD in the past.
  2. Reinstall windows on the machine and clean install the disk and create an EFI partition from scratch with the size I need. Probably the easiest method noob wise.
  3. Change the partition sizes and a move them through Gparted. Try my best to take it slow and carefully and insure the windows partition boots so I can also extend the EFI partition. If it doesn’t I may need to delete and recreate the MSR through the command line, and possibly use a system image to fix that install. The hardest method, and can easily be messed up.
  4. Stop being a wimp and just try to go full linux on the laptop early and just ensure all my data is properly backed up and off those drives before I do it. I’m really only doing this if I can get this to work at all/the way I want it to. I’d have to do it sooner or later anyways.

I’m willing to do any of these but option 1 I’ve read mixed advice on. I’ve read everything from “it should be fine” to “not best practice” to “You’ll run into issues since it’s out of spec/past the MSR.”

So in short I’m asking: How bad would it really be to have multiple efi partitions on the same disk/logical volume? Would I be better off with one of the other methods?

I mean I know dual booting is kind of messy regardless (with windows + Linux at least), but I figure is worth a try. For the experience, and better understanding of partitions and what not.

Well, an EFI partition can’t go on a Logical Volume, which I assume you realize on further thought. As for multiple EFI partitions, that worked for me in the past when circumstances (similar to yours) seemed to call for it. Sounds like you, too, have done this successfully. But I had a couple of issues.

Possibly major issue: when it became necessary to do a Windows restore from backup, it totally messed up the disk - neither OS would boot afterward; not sure whether the data partitions survived. Possibly “just one of those things”; I have had poor experience with Windows Restore, especially on dual-boot machines and even with only one EFI partition.

Minor issue: the Linux efibootmgr command takes an additional argument to specify the EFI partition if not working with the “default” one. There may be similar boot-manager-related needs.

Good luck with whatever you decide.

1 Like

Yeah upon reflection I used the wrong term. Sorry about that.

I’ve heard similar stories on the forum. I’ve done a few disk images through the Microsoft’s tools but may look into a 3rd party solution just as an extra precaution. I’ve heard others have had better success.

That is good information to know. I’ll be sure to look into that. As far as I know right now, it seems Windows needs the eif partition behind the MSR partition and the windows System(?) in front. But there might be something I’ve missed.

Thank you for you’re post, and I’ll likely try to take this one option at time and see where it goes. This does make me more confident though.

300 MB will be fine IMO. A recommendation for 500 MB has a lot of “Why not?”. A grub .efi file is only a few MB; my /boot/efi/EFI/ubuntu has 4.3 MB.

I doubt Pop OS is actually doing this, but if you were booting via EFI directly (EFIStub), rather than using GRUB, ELILO, rEFInd or SystemD-boot/gummiboot, you would need more space to store the kernels and initrd files, because EFI by default will only understand FAT partitions such as an EFI System Partition.

Even without EFIStub, you could also setup /boot on the EFI System Partition, which also would require more space than the usual GRUB setup that actively uses less than 100 MiB. Reading the following article, it sounds like some minimum size requirements might not even be related to space; it gives the example that many installers (as a result of using mkfs.fat) will format the ESP as FAT16 if it is smaller than 260 MiB, despite UEFI specifying that the ESP should be FAT32:

In the Arch Wiki, there is a note that some bugs might require a partition size of > 512 MiB:


All in all, it seems like PopOS’s 500 MiB recommendation is probably not necessary in most cases, and is just a way of avoiding as many edge cases as possible with one simple rule.

Personally, I would be willing to try using the same ESP (EFI System Partition) as long as each OS has 100 MiB of space.

However, the real question here is which of the following Windows will tolerate better:

  • sharing an ESP
  • seeing multiple ESPs

I think you should clarify that in this case “default” is not a property of the ESP, but just means that efibootmgr will default to partition 1 unless otherwise specified.

As far as I can tell at a glance, efibootmgr does not check if partition 1 is an ESP or even if it is FAT formatted. You can see the help output on the GitHub page, pulled from efibootmgr’s README.md.

See I thought that too but the current beta for 20.10 seem to make it mandatory. not that would until the full release hasn’t come out yet, but I can’t seem to progress with the singular efi partition on the disk. But I can if I used the one for my current Mx Linux install.

That’s a bug in the text, /boot where you hold the kernel, sure 500M or greater is good.

/boot/efi where you put the bootloader… usually can’t go over 512 reliably (iirc)

I’ve looked into this a bit, for uefi boots, Pop Os favors systemd boot, according to the system 76 website. Maybe there’s a command line way to install on a smaller partition that could try as an option as well? GUI installer doesn’t let me use the current 300MB (or I guess 314MB?) eif partition for some reason so maybe it’s less of a recommendation than I thought…

This explains a bit on how I currently dual boot with MX Linux on the seperate, slower drive. I tend to fiddle with the UEFI/BIOS boot order to pick what OS I want to use. efibootmgr must work in a similar way.

Just had the opportunity to check a Windows 10 EFI directory, it has 26 MB.

1 Like

PopOS really should not call it that, calling the ESP currently in-use (/boot/efi) “Boot” is just asking for someone to confuse it with /boot, which is sometimes itself a separate partition.

Depends on what you mean by fiddling with order; the EFI (and later UEFI) specification defines some NVRAM variables that it uses to store an ordered list of boot entries as well as an entry the can specify something different for just the next boot. The efibootmgr utility directly changes these variables.

Obviously, this creates a chicken-egg problem, since a NVRAM reset or brand new machine could have no boot entries, or a machine with a new hard drive could have only invalid entries; this is why there is a EFI-specified fallback path at /BOOT/BOOTx64.EFI (for x86 64-bit machines) that firmware can use without a boot entry. This is how EFI discs, or USB flash drives can boot without having a pre-existing boot entry.

I mention this distinction between boot entries in NVRAM and the default/fallback boot path in an ESP because the boot selector you see in your EFI firmware (F12 sometimes brings this up) can show a completely different boot order then the boot entry list in NVRAM.

I think I have seen some firmware boot selectors which try to merge the NVRAM entries into a list of hardware devices for which it will use that fallback path, but I have also seen EFI firmware which does not show any NVRAM boot entries.

For example, the boot selector on Intel Macs will happily display a list of multiple partitions with a fallback path (including non-FAT partitions), but will give you no indication that it is in fact keeping a separate boot entry list that it will use when you boot normally.

I should note, EFI boot entries are not just a file location, they are more like a line in shell script or GRUB; you can pass arguments/parameters to the .efi executable you specify (unless your EFI firmware is badly written). If you boot via EFIStub, this can let you change your kernel boot options via efibootmgr, but if your kernel needs specific options to boot, then clearing NVRAM or moving to a new boot drive could leave you unbootable until you recreate the necessary boot entry from a livecd.

While I cannot find documentation on how Pop OS is using its ESP, I did find this post on reddit showing two files as taking up the majority of space in that user’s ESP:

101M ./EFI/Recovery-0371-085D
201M ./EFI/Pop_OS-825489ea-ae51-4e04-a926-f9ef36203b61

So perhaps it really does need that much space.

I guess I should say change boot priority. I know it’s a janky solution than using gurb, systemd-boot, or rEFInd with a windows boot entry but it worked for my needs at time. I also forgot at the time what key (f11 on msi for some reason) to use for boot section so I’d into the bios every time. I may use rEFInd after ensuring everything works just to simplify things.

Yeah this is how I would describe using the liveusbs and MX linux on the hard disk.

By like… 2 MB. Man. Well it explains why I can’t have it on the current partition. Also thank you for the explanations on efi and NVRAM.

When 21.10 gets a stable release I’m going to try the two EFI parition and see how that will work out.

so small update. I tired the multiple ESP partition method with the beta version of Pop os 21.10 and it works fine. I can still go in between my windows and my pop!_OS installs.

Thank you all again for the information provided in the thread.

1 Like

One last small update for people finding this post in the future. It took a bit of work but I got rEFInd is working on the laptop as well. I had to manually add the boot entry with efibootmgr since my OS drive is Raid0 and as result the partition is under dev/md/RAID0IMSVolume instead of dev/sdx. From there I’m able to switch in between all three Oses I have installed (POP, MX, and Windows) Flawlessly.

If others are having rEFInd appearing in your options try the following command:
efibootmgr --create --disk /dev/sdX --part Y --loader /EFI/refind/refind_x64.efi --label “rEFInd Boot Manager” --verbose

For clarification:
/dev/sdX = is the disk the ESP/boot partition is on. Not if running on a raid config your drive will likely be under dev/md/[DRIVE_NAME]. You can always use the lsblk command or a disk application to check in your case.
Y = the partition number rEFInd was installed to on your system, in my case 5.

I hope this helps anyone in the future, or you just found this interesting.

I think I’m going to enjoy my time with Pop!_Os now that I got it mostly configured the way I want it for now. May make a future post on how the multiboot is working for me, I’m not sure yet. I’m just kind of glad things have worked out andI have yet to bork my system.

knocks on wood

This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.