How can I enlarge the EFI partition on a dual boot-system with Windows and Linux?

I intend to install Windows and Linux on my system which is booted in UEFI-mode.

For Linux, I intend to do the following things:

• install the LTS kernel and whatever current version the mainline brings with it




• use systemd-boot

So ultimately, the default size (100 MB) of the EFI partition, which is created during the installation of Windows gets pretty crowded (roughly 94 MB get used). Hence I'd like to enlarge said partition. As as the standard recommendation for disk layouts puts that MSR partition right after the EFI partition, I deleted the MSR partition. Then Win 10 did not start and the boot repair program from the Win 10 USB drive was able to repair the boot problems.

But the core problem is that I cannot enlarge the EFI partition, either with diskpart or with GParted (on a Xubuntu 16.04.1 USB drive). When I run extend size=100 in diskpart, it says:

You may not shrink oem esp or recovery partitions. The selected volume [etc.]...

GParted throws the error

gnu parted cannot resize this partition to this size. we're working on it

Does anyone know of the necessary steps or an arguably "simple" sequence thereof to enlarge the EFI partition?

Answer

I can think of two ways around the problem that are likely to work; but neither approach is perfect or all that easy.

Method #1

This method is pretty basic:

1. Back up the ESP. A file-based backup will be sufficient.


2. Unmount the ESP.


3. Find the GUID of the ESP by typing sgdisk -i 1 /dev/sda as root. (This example assumes that the ESP is the first partition on the first disk -- /dev/sda1. If it's another partition, you must change -i 1 appropriately. If it's on a disk other than /dev/sda, you must change that part, too.) This command shows various information, including one line identified as Partition unique GUID. Save that value. (Note that recording and re-creating the GUID value is done for the benefit of the computer's built-in boot manager. If you're willing to use efibootmgr to re-create your boot manager entries, you can forego this step and step #6, below.)


4. Delete the ESP.


5. Create a new ESP that's the desired size. Note that this means both the ESP and a new filesystem on it.


6. Use gdisk or sgdisk to change the GUID of the new ESP. For instance, sgdisk -u 1:2C17D5ED-850D-4F76-BA31-47A561740082 /dev/sda (as root) changes the GUID of /dev/sda1 to 2C17D5ED-850D-4F76-BA31-47A561740082.


7. Mount the new ESP


8. Restore the backed-up files to the ESP.


9. If necessary, edit /etc/fstab to record the new "UUID" for the ESP (really a disk serial number, for FAT filesystems). You can use blkid to find the new serial number.

Note that some partitioning tools, such as gdisk and sgdisk, may require rebooting before the OS recognizes changes to disks that are in use. Thus, you should either use an emergency disk boot, with no mounted partitions on the target disk; or use a tool like GParted for the partition deletion and creation operations. (Changing the partition's GUID does not make any change that requires rebooting.)

This procedure runs some risk of catastrophic failure, particularly if you're careless with your backup files. Also, if something goes wrong, your computer will be rendered temporarily unbootable. Having a copy of my rEFInd boot manager on a USB flash drive can be helpful in case of such an emergency.

Method #2

I've not tried this with diskpart, so I don't know what's triggering that warning; but it might be a partition attribute (one of two things that libparted calls "flags"). Something like "system partition" might plausibly cause partitioning tools to refuse to touch the partition. You can use parted or GParted to look for these flags; however, I'm not sure that they'll show all the flags. If the partition has flags other than "boot" (and "esp", with newer versions of libparted), you might consider removing the extras. Alternatively, you can use gdisk, which will show all the attributes:

1. Type gdisk /dev/sda (or whatever the disk's ID is) as root.


2. Type p to view the partition table.


3. Type i to view the details about a partition. You'll be asked to specify the partition number. Several lines with details about the partition will appear.


4. Look for the Attribute flags line. If no flags are present, this line will show a value of 0000000000000000. If so, you can quit gdisk by typing q. If it shows attributes and you want to remove them, though, proceed....


5. Type x to enter the experts' menu.


6. Type a to modify attributes. You'll be asked for a partition number. Enter it.


7. You'll be shown a list of six known attributes and a summary of which ones are set. Type the number of the field you want to change.


8. The previous step will repeat automatically until you hit the Enter key with no value as a signal to stop editing.


9. Type w to exit and save your changes. (If you think you've messed up, type q to exit without saving your changes; gdisk holds changes in memory until you tell it to write them to disk with w, so you can easily abort most actions.)


10. For safety, reboot.


11. Back up your ESP.


12. Use GParted to resize your ESP.

This approach is less likely to work than the first one, both because the problem might not be a partition attribute and because, in my experience, GParted often corrupts FAT filesystems when it resizes them. That final point should not be underestimated; if GParted messes things up, you'll be left having to restore everything from your backup, and this procedure will end up with the worst aspects of both methods. OTOH, if GParted is successful in resizing your ESP, this method may be slightly simpler and less risky than the preceding one.

Further Comments

Of course, if you haven't yet installed Windows, there's a much easier way to do what you want: Create your ESP manually before you install Windows. You can then make the ESP as large as you like.

Another approach is to use something other than systemd-boot. That boot manager is very limited by its inability to launch kernels or boot loaders from anything but the partition on which it's stored. (At least, it was limited in this way the last time I looked at it; and the nature of your question implies that you believe it is still so limited. I haven't reviewed it recently, though.) Neither GRUB nor rEFInd suffers from this limitation and so would be easier to set up -- or at least, neither would require the sort of partition manipulations that systemd-boot will require.