Is it possible to have two EFI partitions?

Hi all,

Is it possible to use separate EFI partitions for Windows and Fedora?

My use case is Windows is already installed with a 105MB EFI partition. I’d like Fedora to have more space for its own EFI partition.

Can I create a new EFI partition with the Fedora installer, have it mounted as /boot/efi and have, at the same time, GRUB also “pointing” at the other EFI partition to get a Fedora/Windows multiboot (provided the UEFI gives the Fedora EFI priority)?

1 Like

Only if they are on separate disks. Not on the same disk.

Remember its your BIOS that loads the files from the EFI partition, not Windows or Fedora.

Thank you!

So, if I read you correctly, if I use two separate disks and install Windows on the first one and Fedora on the second one, then I can use a dedicated EFI partition for Fedora on the second one and the installer will properly configure GRUB for a multiboot with Windows on the other disk?

It is correct that the bios can only have one ESP on a disk. It is quite possible to have 2 partitions containing efi data and formatted as such on the same disk but only one of those may be flagged as the ESP partition.

OK, but in the case of separate disks with separate ESP, will the Fedora installer correctly setup GRUB menu to give option both for Windows on disk 1 and Fedora on disk 2?


It somewhat depends upon what drives fedora can access during the installation to search for other OSes that may be installed. I have not tested your scenario so cannot be certain.

I do know that if you allow fedora to do a default installation with automatic partitioning and access to a drive that already has an esp partition it will use the existing esp partition instead of creating its own. Thus for a separate esp partition on the second drive you must either use a custom installation or only allow writing to the second drive during the installation.

If it doesn’t auto-detect the OS on the other disk, it should be possible to manually add a “custom” menu entry to grub for chainloading the OS on the other disk.

Another option (which might be required if secure boot is enabled) would be to press the F12 key as soon as your computer powers up and then the firmware should let you chose which OS/disk you want to boot.

1 Like

Only if they are on separate disks. Not on the same disk.

Is that true? I have machines with multiple ESPs on the same disk and it works fine. Ex, multiple linux’s with their own grubs in their own ESPs. It will be confusing, but it does work.

And AFAIK there isn’t a restriction in the UEFI spec either, which doesn’t mean that various BIOS’s won’t have a problem with it, particularly when booting without a defined boot path. Ex: 13.3.3 in UEFI 2,9 starts with “UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system.”

Maybe there is a restriction somewhere else in the spec I missed?

Either way, its going to be platform defined what happens if there isn’t a BootXXXX entry/etc and there are multiple ESPs in the system, regardless of whether they are on different disks, or the same one. Maybe there is something in the PlatfformRecoveryXXXX logic, but I don’t see that behavior defined in the spec sufficiently to answer what happens when its in recovery mode and there are multiple ESPs, other than “platform defined”

The firmware will only find and use one (probably the first one) of the ESPs if you have multiple ESPs on the same disk. So things may seem to be working fine with multiple ESPs, but if you reset your firmware or need to move your hard drive to another physical system, you might discover that it will no longer boot if the ESP that the reset or new system discovers isn’t the one with the “right” bootloader and data (kernels, intramfses, loader entries, etc.). I think the UEFI spec actually does specify that there should only be one ESP per disk. But I’d have to dig that up to be sure.

BTW, thanks for getting anaconda to support sd-boot! I’d really like to see the THREE! partition madness that anaconda currently requires (BIOSBOOT, /boot, and /boot/efi) reduced to the much simpler one-ESP-for-everything-mounted-at-/boot that the current booloader specification recommends: Boot Loader Specification | UAPI Group Specifications Let me know if there would be anything I could do to help with such an initiative.

Inst.sdboot works fine if you simply tell anaconda not to create a /boot partition via kickstart, or manually editing the partition layout. My usual systemd partition setup is just a root mounted at / and an ESP mounted at /boot/efi. Its easy in the GUI, create a default partition layout and delete /boot. Which isn’t what the BLS document suggests, but its not the problem it also suggests because its the “third option”, there isn’t a nested filesystem. I’m personally happy with the ESP mounted to /boot/efi because that is the way fedora/etc has been doing it for ages, and there really isn’t a good reason to change if /boot is just part of the root partition. There has been talk of simply not mounting the ESP by default (like windows), but its complicated by the fact that anything that needs to modify the ESP (bls entries, kernel upgrades, dracut/initrd/udev/etc config tweaks, etc) needs to trigger it to automount, and at that point why not just leave it mounted.

So the work is largely convincing people that /boot should just be a directory rather than a full mount point. The only technical work then might be changing the default layout. Frankly, the bit I was sorta looking at was doing a clean fedora secure boot key enroll in order to avoid the need for shim. Which breaks multi-boot, because the only thing that will then boot is fedora, but that’s a feature, right?

But then kernel-install is putting kernel and initramfs on the root filesystem instead of on the ESP. I think the BLS states that the kernel and initramfs should also be on a FAT filesystem that is accessible by the firmware. The root filesystem cannot be FAT because FAT is non-POSIX. The simplest solution is to mount the ESP at /boot.


the MBR boot and GPT XBOOTLDR partition should — be a file system readable by the firmware. For most systems this means VFAT (16 or 32 bit).

1 Like

No, inst.sdboot moves the kernel+initrd to the ESP. It only works that way. The debug symbols, config-xxx files etc all remain on the rootfs in /boot, but the important stuff needed for boot get moved to /boot/efi. If you have an inst.sdboot machine, just poke around and look at it. Nothing remaining in /boot is needed for boot. Then you can format / as anything you want, no fat restrictions.

So you’ve effectively renamed /boot to /boot/efi. IMO, that is an unnecessary complication. I’d rather leave /boot where it has always been. I have systems that install other bootloaders as well (syslinux) to /boot so when I want to use coreboot/libreboot, all that will work. I’m sure it would be possible to change those systems to work with /boot mounted to /boot/efi, but I’d really rather not change that mountpoint which has been consistent for decades.

In fedora the only thing I see that makes using vfat for what is in /boot is the symvers symlink.

UEFI mostly only understands vfat. I have set things up where the ESP is vfat and has an ext2 driver added. Then XBOOTLDR is ext2 and fedora is happy.

Currently I am happier with just a vfat ESP and put everything needed in it as regular files. Maybe a kernel-install change is necessary before all fedora utilities can handle this. I expect the uki work will result in the necessary changes materializing. Working with both grub and sd-boot seems to be progressing as well.

symvers doesn’t have to be a symlink. it is a small file and it is only necessary for debugging the kernel. (and it is not even necessary for that really, the debuggers could use /proc/kallsyms which is better because it is guaranteed to match the running kernel).

FYI: Peter's Notes:

Right, either one makes /boot firmware readable which means more code running in firmware context (which is a big part of replacing grub with systemd-boot) or the parts the firmware needs to execute get moved to ESP. There really isn’t a space argument as it doesn’t really matter space wise if the kernel is in the ESP or another partition on the disk, and resizing ESP’s isn’t hugely difficult. Part of the problem with grub and /boot is the question of should /boot be ext2/3/4, btrfs, xfs, or what. And of course does that match what the user wants, and having a root that is btrfs, and a extX /boot is just more unneeded complexity for what should be a simple file read during early boot.

And so, /boot can retain permissions/ownership information, that isn’t possible with FAT, on any linux supported filesystem. It also cuts the amount of code running in firmware context. And it more clearly separates in the filesystems the stuff in /boot actually needed to boot the machine.

So its a win-win-win just to move the kernel+initrd to the ESP, while largely maintaining compatibility with a stock fedora system running grub.

I 100% agree with moving everything to the ESP. I just want it mounted at the “traditional” /boot mount point. (And that is what the revised BLS is recommending as well.) kernel-install and everything else is already designed to work with the /boot mountpoint. It is just a matter of getting the anaconda folks to mount that partition there. (There are a few small odds and ends such as setting the SELinux permissions. But they are quite trivial and unobtrusive.)

There is a bunch of other junk in /boot that isn’t needed in the ESP, including things like the kernel dtb’s on arm platforms, system-map files, etc. And in fedora packages tend to have hardcoded file paths, so if you want to say install the shim package its going to want to put its files in /boot/efi/EFI/fedora regardless of which bootloader is being used.

Its just easier this way.

There really isn’t. If something somewhere along the line decided it “needed” to be on /boot I’m sure it will soon decide that it “needs” to be on the ESP as soon as systems start moving the kernel there. The whole purpose of /boot’s existence is to hold the bootloader (older systems had to ensure that the bootloader was “within reach” of the BIOS, this is the exact same problem that the ESP solves but instead of the limitation being the cylinder number, it is now the filesystem format).

So let it. It is shim’s fault for hard-coding that path like that in the first place. It should have been coded as relative to the mountpoint.

With sd-boot, you wouldn’t need any of the grub2 packages, and if you also remove the syslinux package, then /boot will be basically an empty directory.