13

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.

AF7
  • 261

6 Answers6

7

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.

harrymc
  • 498,455
3

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.

Journeyman Geek
  • 133,878
3

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:
PRESETS=('default')

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.

robsco
  • 131
2

After reading through multiple guides (including this one), and spending a full day trying everything possible - I finally ran into the process that is quick, easy and reproducible.

Tools needed:

1. Partition imaging/restoration software -- I used both Clonezilla and Symantec Ghost v11.5.1.226

2. GParted -- I used PartedMagic on a USB to access, Clonezilla, GParted and CGDisk

3. CGDisk (or whatever partitioning utility floats your boat)

4. A Windows PE via a Windows install disk/thumbdrive or Hiren's BootCD -- I have all of these - you should, to!

Process: For our example, let me layout a hypothetical 'current' partitioned disk that we want to change.

Partition1 - 100mb -- EFI system partition

Partition2 - 16mb -- MS Reserved partition

Partition3 - 200gb -- Windows

Partition4 - 520mb -- MS Recovery (RE) partition

Partition5 - 400gb -- MS NTFS formatted data drive

Our goal is to SAFELY increase Partition1 (EFI) to, let's say.. 500mb

Begin!

Step 1: Make separate partition images using your imaging software of choice. NOT a disk image, but separate partition images. In this case, we would end up with 5 images. Most of these partitions are excruciatingly small, so this process takes very little time. Using these actual numbers and Clonezilla, probably 20 mins.

Step 2: If you're extra paranoid (I am!), restore these partitions and make sure they are rock solid.. if you used Clonezilla, and had it verify each image after creation, you're probably good. Or, if you're not paranoid and trust all things in the Universe, skip this step.

Step 3: Now, within your environment of choice to use GParted, open this disk and DELETE all 5 partitions. Apply changes. Keep a cloth handy for the sweat. It's going to start at 'Apply'. You now have a disk that is 100% unallocated. Quickly check GParted's disk info and verify it has a GPT partition table (it should, of course, but remember we're paranoid!).

Let me say something right here... We made an image of Partition1 (EFI) just in case something goes horrifically wrong and we want to restore everything 100%. Assuming nothing goes that South, we WON'T be restoring that image... while most imaging software allows you to restore an image to a larger partition, this does NOT seem to work with EFI partitions. You are left with all sorts of frustrating error messages. Ok? So we're going to rebuild an EFI partition from scratch and not restore Partition1. Let's move on.

Step 4: Now we rebuild the partitions. I use CGDisk for this, because I'm very fast in there. I will use that method here. Assuming my target disk is /dev/sda, I do

cgdisk /dev/sda

from the CLI. Inside, I arrow key down to FREE SPACE, then arrow left/right to NEW. I hit return for default start, enter 500MiB, hex code 0700 (for MS data), empty return for partition name. I now see it listed in the pending write list.

(note: This is our new 500mb EFI partition, but we do NOT use the hex code ef00 here. That will screw up everything, or at least is always did in my case. We are tricking utilities down the road that will be very fussy about doing anything to a system partition flagged as ef00. So we set it initially to 0700, and we will come back later and change it back.)

I next select FREE SPACE and create the 16MiB MS reserved partition, use 0c01 code and no partition name. Next is the Windows partition, created with 200GB, code 0700, and no name. Next is the RE partition, created with 530MiB, code 2700 and no name. Finally, we create the data partition with 400GB and code 0700 - no name.

We write this to disk. Exit CGDisk.

Step 5: Reload up GParted or whatever you're using. Format the new 500mb Partition1 to 'Fat32'. Apply. Now restore images for Partition2 through whatever. If you weren't following a guide and tip-toeing through this, you would probably have invested less than an hour to now. 95% of that time would be imaging and restoring.

Ok, at the end of this step, you should have a new 500mb EFI partition flagged as msfsdata, formatted as Fat32 and empty. You should have a restored 16mb MS Reserved partition as Partition2, a 200gb Windows partition back as Partition3 (to eventually become drive C:), a 530mb Recovery Environment as Partition4 and finally our 400gb data partition (that will eventually be drive D:).

In GParted, it is quite common to have an error flag on the 16mb MS Reserved partition. It's because it has no valid filesystem. You can ignore this. But there should not be any other errors for the other partitions. Let's rebuild the EFI partition next.

Step 6: Disconnect all unnecessary disks, leaving just the disk we are working with. Boot into a Windows PE. I use Hiren's BootCD. Whatever you use, make your way to an elevated (Administrator) CMD console. We will now use DISKPART.

Step 7: Type DISKPART at CMD prompt. Once loaded, type

LIST VOL

(you don't have to use caps.. I am, here, to designate typed out commands). Since your new EFI partition was formatted as Fat32, it will probably be in the volume list as C. We are going to remove all drive letters associated with our disk. So type

SEL VOL 0

REMOVE LETTER={whatever is there for Vol 0}

Go down the rest of the volumes and remove their drive letters via SEL and REMOVE commands. Do not remove the environment drive letters, typically X and/or Y. Look and find your Windows volume. In my case, I'm looking for size of 200gb. I see it as volume 1, so I type

SEL VOL 1

ASSIGN LETTER=C

Then I locate my 400gb data drive and see it as volume 4

SEL VOL 4

enter code here

ASSIGN LETTER=D

Now I locate the new 500mb EFI partition - I see it at volume 3

SEL VOL 3

ASSIGN LETTER=Z (any available letter, doesn't matter)

Do LIST VOL one last time to verify my Windows drive is C, the EFI drive is Z (or whatever you assigned), and any other data drives have their appropriate drive letter(s). Now type EXIT and you should back to your CMD prompt. Whew!

Step 8: Ok, let's build a new BCD store. If you didn't use Z for your EFI drive letter, replace Z in the following command with your letter. Type at the CMD prompt

BCDBOOT C:\Windows /s Z: /f UEFI

You should receive confirmation that writing the boot files was successful. You're pretty much done. But wait! We're paranoid!!

Step 9 (optional): From the command prompt type Z: to switch to the EFI drive. Type DIR and you should only see one entry - a directory called EFI. That's it. Let's set it back bootable as an EFI partition again...

Step 10: Let's get back in to GParted. Load the disk. Select Partition1 and 'Manage Flags' (you can do this by right-clicking the partition in the partition list, or by highlighting the partition in the list and then selecting 'Partition' from the top menu. Once in the 'Manage Flags' GUI, just click on 'boot'. Verify that at the same time, the 'esp' boxed was ticked by GParted as well. If it wasn't, that might be a problem... but tick it. Both 'boot' and 'esp' should be ticked. Exit the 'Manage Flags' window and the flags will automatically be set. There is no need to 'Apply'.

Step 11: Reboot into your new system with a 500mb EFI system partition. I would suggest you hold down whatever key gets you into your BIOS 'boot menu', and ensure you select the EFI entry for that disk.. once it successfully boots from that EFI partition, it should be the default next time around. If you just blindly booted and didn't get into Windows, definitely do this on your second try. Make SURE the EFI choice is selected by you.

Step 12: Are you extra paranoid? Once you are in Windows, go to elevated CMD. Enter DISKPART. LIST VOL, SEL VOL that is your 500mb EFI. ASSIGN LETTER=G or whatever. Open File Explorer. Right click on G: and select 'Properties'. You should see somewhere around 30mb used and 470mb free.

Time for me to do all of this, using these actual drive sizes, is slightly over an hour. And I would consider this 100% safe since you have the images. Also, I did use Symantec Ghost to image my Windows and data partitions (2 and 5). I do this so that I can restore them to a smaller partition if I want, and as well, I can browse through the image using Ghost Explorer, and extract any single file or files that I want.

In case the questions arise of why I use both Clonezilla and Ghost, well I answered why I like to use Ghost.. the typical NTFS data partitions are something it has always handled quite well. It doesn't do well with EFI and system partitions. It doesn't even see the MS Reserved partition. So I use Clonezilla for those, and Ghost for the data partitions.

I am not an expert in disk partitioning, Windows, or Linux. I am well aware that 'this step' or 'that step' might not be necessary, or could be done some other way. But I can do this as listed over and over with successful results. I will certainly entertain any comments that help make any of this more efficient or quicker.

Enjoy.

  • Keith
1

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.

rofrol
  • 2,001
  • 19
  • 17
0

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