My system currently has this partition setup: enter image description here

I would like to enlarge /dev/sdb2, the EFI System Partition, to 500MB.

The problem is that I do not want to delete the Windows Recovery Partition (/dev/sdb1) and I do not know how to move the unallocated space after /dev/sdb4 to be adjacent to /dev/sdb2.

Using Linux, I can move the /dev/sdb4 partition to the right by 400MB, but then I cannot move the MSR (/dev/sdb3) as it is of unknown format.

Using Windows, I cannot move the Windows10 partition, and by the way the MSR partition seems hidden so I cannot act on it.

So I'm stuck with only 100MB of EFI partition which is totally insufficient for multiple kernels.

  • 1. Backup. 2. What about to create a partition at the end of /sdb5 and use directly that one? You can always re-format the unknown partition when you are sure that it is not in use... 3. Backup. 4. Backup...
    – Hastur
    Jul 30, 2016 at 21:23
  • @Hastur the unknown partition is Microsoft's MSR and I'd like it to stay untouched. I don't use Windows much but I do not want to mess it up. So you are basically suggesting to move the EFI partition to the 400MB space I previously created? Will this mess with the BIOS (some data of which is also contained in the EFI) or Windows? Do I have to edit some Windows config for this? As for Linux, I know it's not a problem.
    – AF7
    Aug 1, 2016 at 6:48
  • I meant inside /sdb5... (faster) from the end if it is allowed...
    – Hastur
    Aug 1, 2016 at 7:39
  • @Hastur Sorry, I do not understand. Could you please elaborate?
    – AF7
    Aug 1, 2016 at 9:33
  • Sorry elaboration idea. About grub. From mobile (+holyday) I cannot more :)
    – Hastur
    Aug 1, 2016 at 10:25

5 Answers 5


To move sensitive partitions, you need to boot from CD or USB.

Some free partition editors that have boot CD are :

Of the two, MiniTool has the better user interface.

I suggest before starting, to take an image of the entire hard disk on external media, using a product that also has a rescue boot CD. Create this rescue CD and test whether it can see the backup disk and image, just in case, as any mistake can destroy the disk and render the installed operating systems unbootable. My favorite backup product is the free AOMEI Backupper.

Below is the procedure to follow once you boot into the partition editor's boot CD. It brings the unallocated space to below the EFI (sdb2), but as unallocated space is not counted as a partition, one needs to rather move its adjoining partition.

  1. Move sdb4 right/down by 400MB
  2. Do the same for sdb3 (MSR). The unallocated space should now directly follow sdb2.
  3. Reboot to test if the disk still functions. If reboot is impossible, then the MSR could not be moved - see below.
  4. Resize sdb2 to include the unallocated space
  5. Reboot

If the tools fail to move the MSR, or if Windows cannot boot after the MSR was moved, you will need to delete and recreate it.

This is explained in this answer :

Boot into the Windows installation media, and press SHIFT+F10 to open the command prompt. Type diskpart. Type list disk, and then select disk X where X is the number of the physical drive containing the Boot partition. Type list partition to give you the partition list. I had the EFI System Partition at the start of the disk now which is 100 MB in size, and the partition list says that it began at an offset of 1024 kB. Windows considers a megabyte to be 1024 kB so the free space begins at an offset of 1024 + (100*1024) = 103424 kB. Type the command create partition msr size=128 offset=103424. If you have the sizes and offsets right, this should work, and in my case, it indeed did.

See also the description of the command Create partition msr.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Mokubai
    Aug 4, 2016 at 11:14
  • Always backup before mucking with partitions. Looks like his Windows partition is sdb4. If he adds the unallocated space to sdb4 (parted or whatever), then boots into windows, he should be able either to expand the drive inside windows to use the added space, or to add another drive using that space. Part of this will depend whether the Windows 10 drive was allocated with a dynamic filesystem (gpt) or a static one (mbr).
    – Jeter-work
    Aug 5, 2016 at 20:59
  • 1
    @harrymc My problem was solved, but - sorry to say that - not thanks to your answer, which I find not factually correct. Moving the MSR is not possible. It has an unknown filesystem and thus cannot be moved. You can clone it to another location and delete the original, but Windows will not boot. It is mandatory to use Diskpart: you have to recreate the MSR using Diskpart, or Windows will not boot. Thus while partially true and indeed providing good links, I find this answer not ready. If you want to edit the correct information in I'll be glad to accept it. Or if you want I can edit it.
    – AF7
    Aug 7, 2016 at 16:56
  • 1
    @AF7: You may edit the text to your liking, no problem. Just that half of your bounty was lost.
    – harrymc
    Aug 7, 2016 at 17:17
  • 1
    Note for the readers: I have no idea what tool the poster used which refused to move a partition because it has an unknown filesystem. Most partition tools don't care much about the filesystem inside the partition.
    – harrymc
    Jan 25, 2018 at 12:15

TLDR: Backup - this is a dangerous process. Then restore the disk, adjusting parititon sizes to taste.

The strategy I would take would be to back up first and adjust partition sizes when I restore. It seems a little odd, but firstly, its idiotproof (if you mess up, you simply restore) and many good backup software gives you the option to resize when you restore, and in many cases would fix the things that would break since its recreating the partitions from scratch.

Doing any sort of file system editing without a backup is irresponsible

My usual backup software's veem endpoint backup and - I've backed up, resized and restored and it seems to work for me -iirc you rightclick on the partition, and set the volume sizes and you're good. This isn't software designed for one off backups, so something else like macrium reflect might work as well.

  • However AFAIK no software can move, resize or delete the MSR without messing up with windows, except diskpart.
    – AF7
    Aug 4, 2016 at 7:25
  • @Journeyman Geek Just curious wouldn't creating new partitions and dump the content over creat new UUIDs and partition numbering? And in the process mess up GRUB und EFI boot loader? (And I'd suspect WIN boot loader too)
    – gilgwath
    Aug 4, 2016 at 7:57
  • Windows loader should be fine, I've actually done this on EFI systems before. The idea being that the backup software would handle most of the wierdness, and grub is relatively easy to fix
    – Journeyman Geek
    Aug 5, 2016 at 2:40

So I'm stuck with only 100MB of EFI partition which is totally insufficient for multiple kernels.

Seeing as this is the actual problem here, I'll address it. I solved this issue by removing the "fallback" preset(s) in "mkinitcpio" config files. I then deleted the fallback images (for example: /boot/initramfs-linux-fallback.img). The fallback images are a lot larger than the default images. Before doing any of this, please read up and make sure you understand the risks involved with not having a fallback kernel available. That said, if you can boot from the default kernel and do not plan on changing your hardware, you should be all good. I would recommend having a backup installer (USB flash drive or the like) on hand in case you need the fallback kernel.

In my case, the linux config file is at /etc/mkinitcpio.d/linux.preset (you should have one per installed kernel). I commented out this line:
PRESETS=('default' 'fallback')

and added this line:

I then ran sudo mkinitcpio -P to rebuild the images and test the config file.

With linux, linux-lts and Windows 10 installed, df -h shows:

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2   95M   56M   40M  59% /efi

Looks like I still have space for a kernel or two and I'm glad I avoided the parition resizing headache/stress.

  • 1
    I wouldn’t recommend it unless absolutely required. This works with Arch, but with Debian old kernel versions can quickly accumulate if you don’t manually take care. A bigger partition is better. Especially for Windows updates and whatnot.
    – Daniel B
    Apr 21, 2020 at 14:31
  • 1
    This was perfect, thank you.
    – Ruslan
    Nov 6 at 20:58

Here's what worked for me. I had an existing unallocated 1000MB available on /dev/sda. My ESP was on /dev/sda1 and was 100MB Fat32. I booted into a live linux environment via USB (/dev/sdb) and loaded gparted.

In gparted, I see the /dev/sda with all the partitions. I selected /dev/sda1 then choose copy to the unallocated 1000MB partition and selected to resize to 500MB, applied the changes, the copy completed.

Next, I modified the flags and removed the esp and boot from the old ESP partition and changed it to msftdata. Then modified the flags on the newly created ESP partition, unselecting msftdata and checking on the efi and boot flags. Applied the changes and rebooted, and windows recognized the boot, but still not complete, as the 100MB partition appears as 'system' when looking at it Windows Disk Manager.

I wanted to delete the 100MB empty partition (probably don't have to), so I loaded EasyUEFI and was able to back up the old and the new ESP partitions.

It was working, but since the 100MB old partition was still being recognized as 'system' in Windows Disk Manager and using it. Loaded EasyUEFI, chose the Rebuild Windows System partition option, select the boot partition (C: drive) and the system partition (esp), and it will rebuild correctly. Windows was then recognizing the 500MB partition as ESP Boot System and Windows 10 boots up correctly. I was able to delete the 100MB old partition. You might be able to do the same thing without using EasyUEFI via command line, but this was quicker and easier.


If you don't want to mess with diskpart, you can do this in GParted. I tested this method on my machine and it works.

  1. shrink /dev/sdb4 (windows partition) by 400MB (you've already done this)
  2. unmount /dev/sdb2 (efi partition)
  3. copy /dev/sdb2 into the empty space between /dev/sdb4 (windows partition) and /dev/sdb5 (linux partition) and call this new partition /dev/sdb7
  4. enlarge /dev/sdb7 (new efi partition) to take the entire 400 MB
  5. delete /dev/sdb2 (old efi partition)
  6. ensure /dev/sdb7 (new efi partition) has the esp boot flag
  7. if you use linux, update your fstab file to reflect the UUID of the new EFI partition
  • 1
    This would be a better answer if you gave detailed instructions — specifically for steps 1 and 3-7. Nov 24, 2018 at 21:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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