I wanted to install lubuntu, dual boot with windows, on my laptop but it requires at least 300mb of /boot/efi partition. Currently, my nvme0n1 drive only has 260mb. Is there a way to resize it without damaging the Windows installation? Right now, I will need to shrink my Windows partition
The other thing I was thinking is to clone each partition using dd command:
dd if=/dev/nvme0n1p1 | gzip -c > nvme0n1p1.img.gz
Then I can manually partition a new nvme drive, creating a bigger /boot/efi partition and restore cloned images but I’m not sure if that will work either because all UUIDs will be different.
I’m a little confused by your post. You’ve put this in the Lubuntu flavor category; thus are you asking for the Lubuntu team to consider increasing the default [ESP] size in Lubuntu 26.10 ??
but your text reads a little like you are actually after help?
Lubuntu’s installer will let you create an ESP of any size during install; my system here was installed with a manually chosen ESP size (this system is dual boot, and I wanted it larger than default).
My apologies for posting on the wrong category. And yes, I was wondering if anyone has an idea how to resize the ESP partition, make it bigger, without damaging the Windows partition. The only way to make it bigger right now is by shrinking my Windows partition.
Anyways, please feel free to move my post where it needs to be. Thank you.
FYI: Providing release is always helpful; an easy way for us to know what software is installed by default (including versions of software).
ESP or EFI System Partitions are normal partitions; thus I’d boot live media & just re-size it (shrinking other partitions if I required space, moving them too if required).. At worst the system may not boot due to move/resize; but I’ll usually fix that if it was a problem.
Note: If your system has encryption, fastboot, hibernate or other things activated it maybe more complex; though fastboot & hibernate can just be disabled prior to any resize-moves; encryption though is more complex.
Is that a hard requirement? I couldn’t find any official documentation on it in a quick search. I don’t dual boot, so I cannot say how much space the Windows boot loader wants for itself, but I’ve read somewhere that Windows can work just fine with a 100 MiB ESP and it’s hardly ever using all of it. My Ubuntu 24.04 installation only occupies 11 MiB of the ESP. That suggests to me that you’d have at least 160 MiB to do with as you please and you shouldn’t run out of space any time soon.
One exception is TPM-backed full disk encryption, though, which requires a 5 gigabytes ESP.
As you have Windows, I recommend that you use Windows itself.
Go into the Windows disk manager. Shrink your partition to leave enough space for your pending Lubuntu installation, plus a bit extra for the EFI system partition (ESP).
Move your Windows partition to leave space for a bigger ESP; based on personal experience of dual booting, I recommend a full 1 GB, not just 300 MB.
Once that is done, expand your ESP if Windows allows it, otherwise do it from a Live USB with Lubuntu.
Then you should be able to install Lubuntu without problem.
In my experience, even 300 MB runs out sometimes. I’ve found that 1 GB is preferable, although you can get away with smaller.
Are you sure you’re not thinking of /boot, where the kernels and initrds are? TPM/FDE aside, Ubuntu doesn’t require much space on the ESP; only the EFI shim an GRUB live there, effectively a rounding error.
In the meantime I’ve found this at MS. Looks like there is some wiggle room, because 300 MB are only required with native 4K sector size. One can check with this command:
LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good (in use)
LBA Format 1 : Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0x1 Better
Some devices allow to change the block size (destructively), but I believe the default is probably 512 bytes. If that’s the case here, then there should be at least 60 MB available for Lubuntu’s purposes, which should suffice, with room to spare.
UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system
I have used a dual boot disk with two ESPs for 3 years (Windows 11 and Ubuntu 24.04 now 26.04)
Generally, I boot via the PC boot menu but if you prefer booting via grub, there will be no difficulty.
Here is a terminal output and a gparted picture
Windows 11 ESP is dev/nvme0n1p1
Ubuntu 26.04 ESP is /dev/nvme0n1p5
sudo parted -l
[sudo: authenticate] Password:
Model: Lexar SSD NM610PRO 1TB (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 106MB 105MB fat32 EFI system partition boot, esp
2 106MB 240MB 134MB Microsoft reserved partition msftres
3 240MB 214GB 214GB ntfs Basic data partition msftdata
4 214GB 216GB 2011MB ntfs msftdata
5 216GB 217GB 1074MB fat32 boot, esp
6 217GB 271GB 53.7GB ext4
7 271GB 314GB 42.9GB ext4
8 314GB 432GB 118GB ext4
Just to add here, as soon as you do this, make sure to fsck your partitions and make sure that they all check out. Also make a note that when you move partitions around data sometimes has to be moved on disk so these can take a long time depending on the size of your disk and the amount of data you have.
Do not understand why you must have larger ESP. I do normally suggest making a larger ESP when installing from scratch. My Dell laptop with both Windows 11 & Kubuntu Noble has Windows default size of 200MB & total use is 69MB used by both systems. ESP have several folders because I change “ubuntu” to “noble” in /etc/default/grub and reinstall grub.
So new entry & folder added to UEFI & ESP.
/dev/nvme0n1p1 vfat 196M 128M 69M 66% /boot/efi
I have seen systems work with two ESP & not work with two ESP. But you can have multiple FAT32 partitions with boot files. Grub does not use ESP once installed. UEFI uses GUID/partUUID to know which partitions have UEFI boot files. Install uses boot flag which really is a long GUID type in the partition. Some have switched boot flags/part type back and forth to have two partitions with boot files. Not really recommended.
You can and probably should have ESP on every drive especially if you have install on that drive.
Thanks @paddylandau . I didn’t think of using Windows to resize partitions as I’ve always used Linux but your suggestions makes sense. So, that’s what I’m going to do.
@peterwhite23 No. It’s not the /boot folder where your kernel images are saved. The /boot folder resides on the same partition where lubuntu is installed. /boot/efi is on a separate partition
Shrunk my Windows partition using Windows and did not get what I was hoping for. Instead of creating a new space at the beginning of the partition, Windows did it from the end. Which means I can’t make the existing /boot/efi partition bigger.
I guess there is really no way of creating a new space at the beginning of the partition without risking Windows not booting?
That is actually the expected outcome. You can use GParted to then move the partition further back, so the free space is in front of it. IIRC, since this is a purely block-based operation, it shouldn’t matter what type the filesystem is; it’s never even touched.
Generally, it is advisable to use Windows tools to manipulate Windows partitions.
In particular, there will be a problem with extending the file system within the ESP.
If you are determined to follow this route, then I would ask you to search for suitable Windows utilities.
gparted will make the partition larger but it will not increase the size of the filesystem itself
You can’t resize FAT32 partition lesser than 512Mb because Windows(R) doesn’t work properly with small FAT32 file system. Use FAT16.
One can overdo it with superstition, you know? The ESP is just a FAT32/vFAT filesystem, probably what GParted can do between zips of coffee at breakfast.
If one needs to resort to 3rd party tools — which seems to be the case here, because Windows Disk Management doesn’t support moving partitions, IIRC —, one might just as well resort to the gold standard swiss army chainsaw that is GParted.
Are you sure about that? The feature matrix seems to disagree.
That’s the man page of fatresize, which isn’t installed and seems to be an opinionated frontend for libparted, the heart of GParted. I’ve just tried this with my live ESP on this very laptop; I had zero doubts that nothing untoward would happen:
check file system on /dev/nvme0n1p1 for errors and (if possible) fix them 00:00:00 ( SUCCESS )
fsck.fat -a -w -v '/dev/nvme0n1p1' 00:00:00 ( SUCCESS )
fsck.fat 4.2 (2021-01-31) Checking we can access the last sector of the filesystem Boot sector contents: System ID "mkfs.fat" Media byte 0xf8 (hard disk) 512 bytes per logical sector 4096 bytes per cluster 32 reserved sectors First FAT starts at byte 16384 (sector 32) 2 FATs, 32 bit entries 524288 bytes per FAT (= 1024 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 1064960 (sector 2080) 130812 data clusters (535805952 bytes) 32 sectors/track, 64 heads 2048 hidden sectors 1048576 sectors total Reclaiming unconnected clusters. Checking free cluster summary. /dev/nvme0n1p1: 17 files, 2672/130812 clusters
shrink file system 00:00:00 ( SUCCESS )
using libparted
shrink partition from 512.00 MiB to 511.00 MiB 00:00:01 ( SUCCESS )
old start: 2048 old end: 1050623 old size: 1048576 (512.00 MiB)
new start: 2048 new end: 1048575 new size: 1046528 (511.00 MiB)
I’ve done this countless times dating back at least a decade, if not two.
Yes, that is correct, but I wanted to demonstrate that <512 MiB is not a problem at all. I have since grown the FS back to its original size, also without a problem. Plus, usually the more dangerous operation is shrinking, because blundering there might destroy actual data.
