How to safely enlarge the /boot/efi and remove Windows partition(s) while keeping Fedora running smoothly

Laptop is a Windows / Fedora dual boot. I have 2 somewhat related issues due to the partitions.

  1. /boot/efi is too small to perform fwupd BIOS updates. They fail saying not enough space. I’m hesitant to delete files in the drive or enlarge the partition because I don’t want to create boot issues.

  2. I don’t need windows on the laptop (the only thing I use it for is the BIOS update…). How can I safely delete the Windows partitions, but leave the Dell recovery partition(s) still functioning?

Note, I already shrunk the NTFS drive once, and created the smaller 2nd btrfs partition. I don’t know if that will create issues when trying to modify other partitions.

Including a screenshot of the partition layout as shown in GParted.

Thanks for the help.

I think partition 5, labeled “image” is a restore image. If you were to boot the Dell recovery utility, one of the options is to restore/reinstall Windows and that likely uses a block copy from the binary blob found on p5. That’s my guess.

I think the built-in firmware boot manager can directly boot Dell Recovery without the Windows bootloader on p1, ESP, or WinRE found on p4, image. But I’m not certain without testing it. And only from fuzzy memory, I’m pretty sure Dell recovery is kindof a single button restore. I think it’ll obliterate the partitioning in favor of a fixed scheme, and then immediately start a block copy to restore Windows. There isn’t a partitioning tool, therefore it is completely destructive.

The only partitions safe to remove are 2 and 3.

I think you should do this from a Live USB stick, because once you change the partition map on this drive, the kernel will refuse to update its view of the partition map until reboot, because the root file system is in use. I don’t even think partprobe will work around it.

Once the partition map is written and updated (by the kernel) you can reformat the larger p1, ESP, and restore the contents.

To backup my ESP

# cd /boot
# tar -acf bootefi.tar efi/

This weekend I was able to do all that with the KDE partition manager from a Fedora KDE 41 Live USB.

:warning: Just in case, I created a Clonezilla image of the whole disk just in case things went south, and I am glad they didn’t.

You would have to shrink one of the operating systems’ filesystem partition, and then move partitions towards the end of the disk to clear some space contiguous to the EFI partition.

Once done that, what I did was to expand the EFI partition to the desired size (1 GB in my case).

To my initial dismay Plasma crashed before the operation was confirmed, but when I rebooted on Windows all the sizes were the expected ones, meaning that the operation was ultimately successful.

Both operating systems boot successfully, so I would say that any capable partition manager / resizer should do the work for you (disclaimer: I didn’t try the recovery partitions).

Looking at that image it seems quite easy to remove all the following using gparted.
nvme1n1p2
nvme1n1p3
nvme1n1p4
nvme1n1p5
nvme1n1p6
All these appear to be the windows partitions that would not be used by fedora.
p6 appears to be the one for dell recovery/repair but would be windows related and probably not useful for fedora.

Now you can use gparted to expand or relocate the remaining partitions using the space that should now show as unallocated. Remember that you can use as a guideline the default size used by fedora for the efi partition of 600MB.

Removal of the windows partitions can be done from your installed system, but altering the partitions for the running system should be done by booting to a live media and then using gparted to make the changes. It would not allow changes to partitions that are in use (the ones that show with the locked symbol (the key).
Once all those are removed then you would also need to remove the /boot/efi/EFI/Microsoft directory and its content.
Following the removal of that directory the final step to remove all traces of windows would be running the command sudo grub2-mkconfig -o /boot/grub2/grub.cfg so that the window boot entry would be removed from the grub boot menu.

I also would consider the possibility of merging the content of p8 & p9 since they contain the same btrfs file system but are spread across 2 partitions.

Note that all this could be done in a single step by doing a new clean reinstall and choosing to recover the drive space when selecting the drive for installation.

Thanks for the replies. I followed a similar, earlier post from @computersavvy and removed all the windows partitions.

I’ve used the btrfs add device feature so the btrfs partitions appear as a single drive to the OS. The reason for the multiple partitions is I started with p7 (/boot) and p8 (/,/home) but then shrank the Windows partition which allowed me to create p9. Since that was in front of p7, I couldn’t just expand p8, so I used the device add feature of btrfs to make p8 and p9 appear as one drive to the OS. I did the same thing after deleting the Windows partition.

This sounds interesting but I’m not familiar with this option.

Would this restore my /home data, or would I need to manually restore that after the reinstall?

I currently have 3 btrfs partitions but combined as 1 for the OS. I’m not sure if there are any performance or data integrity issues with this approach.

For future reference: I cannot recommend moving partitions with any partition utility under any circumstances. I personally consider this to be a misfeature because this process doesn’t have any sort of journaling, checkpointing, or rollback.

There’s long periods of time when moving partitions that file systems are functionally broken, and if a power failure or crash occurs during this period - it’s unrecoverable.

So I just can’t recommend it. It’s not safe. And also it’s not faster than the alternative, which is already having a backup of your important data, and just obliterating the entire disk and reinstalling everything with the partition layout you want.


Re: using btrfs device add to add partitions. This works fine, I ran Fedora for a year in this configuration for the same reasons. There’s no downside in a non-encrypted regime. Of course in an encrypted regime you’d want to use the same passphrase for the two partitions, that way plymouth can unlock both at the same time (using the same passphrase). The DEK is different, and that’s fine.


While you can do a clean install of Fedora preserving home subvolume to an existing btrfs, this assumes you’re not repartitioning and reformatting. But in your case, repartitioning is the point of the clean install, and in that case you’d need a backup of home so it can be restored.

This is pretty straightforward on btrfs, pseudo-code is like this:

# mount $DEV1 /mnt/1
# cd /mnt/1
# btrfs sub snap -r home home.20250204
# mount $DEV2 /mnt/2
# cd /
# btrfs send /mnt/1/home.20250204 | btrfs receive /mnt/2

$DEV2 is a separate drive, formatted btrfs. The gist is you’re making a read only snapshot and replicating it from main drive to backup drive. This replication preserved everything, all files, metadata including DAC and MAC security, etc.

All that gets torn down and you do the clean install, and then either in the LiveOS environment after installation, or reboot from installation you do:

# mount $DEV1 /mnt/1
# mount $DEV2 /mnt/2
# btrfs send /mnt/2/home.20250204 | btrfs receive /mnt/1/
# mv /mnt/1/home /mnt/1/home.delete
# btrfs sub snap /mnt/1/home.20250204 /mnt/1/home

Here you’re sending the read-only snapshot back to the new clean installed system, renaming the current home subvolume, and you’ll delete that later; then making a read-write snapshot of the read-only snapshot of your replicated home. And now you reboot.

It does not mind that you’re renaming things behind the scenes, no rugs are being pulled out from anyone. When you reboot your old home is restored. Optionally delete the home.deleted subvolume.

Now this does assume you add users in the same order and using the same shortname they had originally. Added users get their UID in order of creation, and that’s in /etc/shadow, which needs to match the UID for the user’s directory found in /home. If this isn’t the case then you’ll have additional changes to make e.g. chown -R

2 Likes

I agree, and that’s why I was pointing out to do a clonezilla image, as it’d be the only way to recover a failure. Perhaps (or definitely) I could have emphasised that much better.