How to resize the EFI System Partition?

Question

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.

Solution 1

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:

    # 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
   

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).

Solution 2

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.

Solution 3

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.

Comments

[Rod Smith]

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.

[technotron101]

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

[Vladimir Panteleev]

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.

[osdamv]

it works, in my case I also needed to update the UUID of the boot partition on my /etc/fstab

[jwh]

And if using EFIstub, also delete and recreate the Linux entry(-ies) with efibootmgr, as the UUID is embedded there too.

[jwh]

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.

[Maxim]

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...

[rsenna]

Upvoted, even though GParted actually worked for me :-)

[tobek]

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.)