I want to increase the size of the EFI System Partition to 750MiB so.i can install Arch Linux alongside Windows 10 because EFI System Partition Windows gave me which is only 100MiB is too small. Arch Linux recommends you mount the ESP at /boot instead of /boot/efi and 100MiB is too small for /boot. I don't want to touch the Recovery Partition.

  • Exactly how did you try to make the new ESP?
    – fpmurphy
    Jul 18, 2017 at 0:34
  • why do you need such large ESP? Generally it contains only the boot image so won't take much disk space. Kernels and other stuff must be put on /boot
    – phuclv
    Jul 18, 2017 at 2:12
  • Arch Linux' recommendation sounds shoddy to me. I would advise against putting /boot on the EFI partition. I've never done this and never had a problem. Additionally, while the EFI partition uses a FAT32 file system and is mountable as such... it's usually not a good idea to do so as there is certain meta-data on the partition that is not part of the standard FAT32 spec. Finally, the EFI partition is a FAT32 filesystem... which is far from ideal for Linux use, even for /boot. And the EFI partition being FAT32 is part of the EFI spec... not Windows... so no reformating to ext4fs. Jul 18, 2017 at 3:52
  • @Cliff_Armstrong, I think a uefi motherboard should support FAT32, that doesn't mean it can't support additional filesystems.
    – jiggunjer
    Jan 21, 2018 at 14:19

4 Answers 4


This question is among the top results on Google for "How to resize the EFI System Partition" (unsurprising, given that's the question title), however the current answers here, though containing good advice for the OP's situation and generally useful information, do not actually attempt to answer that question as stated. My previous rather terse (now deleted) attempt to answer that question was downvoted, so here's a more thorough one.

There's a good chance that you're reading this because you've tried the obvious thing (use gparted) and got the error "GNU Parted cannot resize this partition to this size. We're working on it!". You may have also tried doing it from within Windows (using Disk Management), only to discover that Windows refuses to perform any operations with the ESP at all.

Well, the next best thing to actually resizing the partition is to recreate it. Here are the detailed steps for doing this:

  1. If you are resizing the ESP of the disk you're booting on, ensure you have some bootable rescue media on hand that you can use to repair your system in case things go wrong. Having a backup of your data before doing any disk partitioning operations is a good idea in general.

  2. If you are enlarging the ESP, make room by moving or resizing any partitions directly following it, using your favorite partitioning tool (e.g. gparted).

  3. Mount the ESP (if it's not mounted already, e.g. on /boot or /boot/efi):

     # mount /dev/sdx1 /mnt # replace sdx1 with ESP
  4. Make a backup of its contents:

     # mkdir ~/esp
     # rsync -av /mnt/ ~/esp/
  5. Unmount the ESP:

     # umount /mnt
  6. Delete and recreate the ESP:

     # gdisk /dev/sdx # replace sdx with disk containing ESP
     p (list partitions)
     (ensure the ESP is the first partition)
     d (delete partition)
     1 (select first partition)
     n (create partition)
     Enter (use default partition number, should be 1)
     Enter (use default first sector, should be 2048)
     Enter (use default last sector, should be all available space)
     EF00 (hex code for EFI system partition)
     w (write changes to disk and exit)
  7. Format the ESP:

     # partprobe /dev/sdx
     # mkfs.fat -F32 /dev/sdx1
  8. Restore the ESP's contents:

     # mount /dev/sdx1 /mnt
     # rsync -av ~/esp/ /mnt
  9. Update EFI entry in /etc/fstab

     # blkid | grep EFI
     # nano /etc/fstab
     UUID=XXXX-XXXX /boot vfat umask=0077 0 2 # Replace with UUID from blkid
  10. If you use GRUB, you may need to update or regenerate its configuration file (/boot/grub/grub.cfg), e.g. by running update-grub.

That should be everything. I've successfully used the above procedure to resize the ESP for a Windows installation whose ESP was too small (50 MB) to allow Windows to upgrade to Fall Creators' Update (before resizing the ESP, Windows Update failed with error 0x8E5E03FB, and the Update Assistant with error 0xc1900200).

  • 3
    it works, in my case I also needed to update the UUID of the boot partition on my /etc/fstab
    – osdamv
    Jun 20, 2019 at 5:34
  • And if using EFIstub, also delete and recreate the Linux entry(-ies) with efibootmgr, as the UUID is embedded there too.
    – jwh
    Feb 14, 2020 at 23:01
  • Upvoted, even though GParted actually worked for me :-)
    – rsenna
    Aug 3, 2020 at 17:21
  • 1
    Thank you!! Worked flawlessly for me setting up dual boot on Windows 10 on a Dell XPS 9700. Ran the commands from terminal on GParted live USB (didn't have to do step #9) and, when I restarted, Windows flawlessly found the EFS and booted up as if nothing had happened, woohoo. (Default values in step #6 were correct except for first sector, I had to manually put 2048 [which was start sector of old EFS] default was some huge value.)
    – tobek
    Feb 6, 2022 at 20:57
  • Does it work for nvme0n1 instead of sda? Did anyone here try this for it? I gonna try it now (after making a backup of my fat16 boot ESP with rescuezilla). Will report here on success or fail, but yet interested in community experience as well.
    – moudrick
    Feb 27 at 9:20

The Arch community has taken the Freedesktop.org Boot Loader Specification to heart. AFAIK, Arch and its derivatives are the only distributions to do this, and even in Arch, it's not required. The Boot Loader Specification recommends using a shared FAT partition, such as the ESP, as the location to store Linux kernels, along with a system to isolate one distribution's kernels from another on this partition and to manage boot loader configuration for the kernels.

The Boot Loader Specification is an attempt to solve some real problems with Linux distribution co-existence on multi-boot computers; however, because it's been adopted by just one major distribution, even after several years of existence, it doesn't provide any practical benefits. Furthermore, the Boot Loader Specification is tied closely to the systemd-boot boot manager, which is rather unpopular except in the Arch community. Although systemd-boot has some advantages, unless you're familiar enough with the field to understand those advantages and know that you need them, you might not want to start setting things up in odd ways (like mounting the ESP at /boot) just to enable use of systemd-boot. What's more, systemd-boot has one huge disadvantage: It can launch follow-on boot programs (including Linux kernels) only from the partition from which it was launched itself. This in turn means that, if you use systemd-boot, you're pretty much committed to storing systemd-boot, your Linux kernels, and the boot loaders for other OSes (like Windows) on one partition -- the ESP. This conforms to the Boot Loader Specification vision, but it creates its own problems.

That said, if you want to enlarge an ESP, you can do so with various tools; however, this means you'll need to shrink the following partition from its start point. This is riskier and more time-consuming than shrinking a partition from its end, so I strongly recommend backing up the following partition. Also, on a Windows computer, the partition following the ESP is likely to be a Microsoft Reserved partition, which is basically just an empty partition that Windows uses for scratch space. It normally has no filesystem, so most partitioning tools won't let you shrink it -- and Windows likes it to be a specific size (100 MiB or 128 MiB, IIRC). You may instead need to shrink the partition following the Microsoft Reserved partition, delete the Microsoft Reserved Partition, and create a new one. This is all one huge hassle and greatly increases the risks involved in installing a new OS.

Instead, you may want to create a new ESP elsewhere on the disk. After you make space for Arch Linux, you can create a new ESP and other partition(s) for Arch Linux. Depending on the boot manager you use, you can simply have separate Arch and Windows ESPs; or you can move the Windows boot loader files to the new ESP and delete or re-purpose the original ESP. Note that because systemd-boot can't launch boot loaders that reside on partitions other than its own, if the reason for mounting the ESP as /boot is that you want to use systemd-boot, you'll have to move the Windows boot loader to the new ESP if you expect to launch it from systemd-boot. Also, the last time I checked (which was with Windows 7, so this may no longer be true), the Windows installer became very confused and malfunctioned if it saw two ESPs on a disk, making the installation of Windows on such a disk impossible. Thus, if you set things up with two ESPs, you could have problems down the road. Such problems can be easily overcome by temporarily changing the partition type code of the non-Windows ESP, but you must be aware of this workaround.

In sum, although I recognize that the Arch community likes to mount the ESP at /boot and use it to store Linux kernels that are (often) launched via systemd-boot, this approach creates complications and few or no significant benefits. Overall, you're probably better off using GRUB 2 or my own rEFInd, both of which will fit on your small ESP and launch kernels stored elsewhere. My EFI Boot Loaders for Linux page describes Linux boot loader and boot manager options in more detail.

  • 1
    A good reason to mount the ESP on /boot and place kernels on the ESP is to make use of EFISTUB kernels, thus allowing the motherboard firmware to boot directly into the Linux kernel. This greatly simplifies the boot configuration, as there is now no need to configure a bootloader or separate Linux /boot partition. Jan 26, 2018 at 3:38

To add to Vladimir Panteleev's answer, instead of updating fstab to new UUID, you can re-create the efi partition with the same partition UUID and volume ID. To do so:

  • use blkid to note old UUID and PARTUUID.
  • after creating partition, run sgdisk -u 1:OLD_PARTUUID /dev/sdx.
  • when creating file system, use mkfs.fat -i OLD_UUID -F32 /dev/sdx1.

There's a bit involved in dual-booting OSs.

The first thing I can suggest is don't use the existing EFI system partition. That's there to boot windows. Don't mess with that.

Instead, open up disk management, and shrink the windows partition (your main one) by an amount (however much you'd like to use with Arch Linux). There's always usually a set limit as to how much you can shrink by, even when it seems like there's plenty of space on the disk. This "issue" is solved elsewhere so I won't explain it here. Just remember which one is which. Eg. the big one's windows, the small space is empty etc.

Don't forget to disable fast startup in windows - this is essentially hibernating your PC instead of shutting it down, in order to achieve a "fast startup." If you instead boot into Linux, you risk losing data in the windows system.

Boot into the Linux installation environment (from a USB or whatnot) and then setup that free space you made in windows, and make it into your linux system partition. Just remembering which partition is which. Eg. don't reformat the windows partition accidentally - use your partition sizes you recorded above to double check.

  • 1
    I forgot to mention Fast Startup in my own answer, and this is a critical point! That feature causes more problems than I'd care to think about.
    – Rod Smith
    Jul 18, 2017 at 17:54
  • I couldn't possibly forget it now. I've dual booted different linux distros for so many people and most of them had problems with fast startup, so it's become second nature to click that checkbox haha Jul 19, 2017 at 4:41
  • 1
    EFI system partition is for booting anything, not just Windows, and is required for EFISTUB (as already answered by Vladimir). The problem is that Windows only creates a 100 MiB EFI partition, which was the whole point of the original question. Also, Fast Startup won't corrupt Windows via Linux unless you're modifying the Windows partition.
    – jwh
    Feb 14, 2020 at 23:06
  • Yeah; but you did not address the question of how to enlarge the EFI partition if it is too small; which was the whole point here...
    – Maxim
    Apr 18, 2020 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.