== why you might wish to grow the ESP == In a UEFI system, booting starts with the ESP (EFI System Partition). Apparently Windows creates a 100M ESP during a fresh install. 100M isn't enough sometimes. On my notebook, Linux's firmware update mechanism, when updating the UEFI firmware ("BIOS" is a misnomer), stages gobs of stuff in /boot/efi. My ESP filled up and updates stopped. (The ESP was mostly filled up with Dell / Windows stuff, but the firmware update pushed it over the edge.) == growing ESP partition with gparted == This should be done from a bootable live Linux system. It isn't wise to move partitions while they are in use. gparted can grow a partition by shuffling all the other partitions. It needs free space, either from unallocated disk space or from shrinking other partitions. After it had made my ESP larger, it refused to resize the (FAT) filesystem inside the partition. == growing the ESP FAT filesystem == gparted? no luck (see above). === fatresize == no luck: it claims that the ESP's partition isn't FAT. It is wrong. What was it thinking? I hacked on it to cough up more information in the diagnostic. For some reason, fatresize thinks that the FS is NTFS. See my fork of fatresize, if you care: https://github.com/HughR/fatresize === brute force === [this can actually be done while running off the disk. You do need to unmount the ESP after step 2] 1) copy all of /boot/efi to a different filesystem 1a) see later, but do this now. 2) use gparted to make a new FAT32 filesystem in the partition (it will naturally use the whole space) 3) copy the backup back into /boot/efi OOPS: fedora won't boot properly because the filesystem's UUID has changed. It is used (at least) in /etc/fstab for /boot/efi. A partition has a UUID and a filesystem within a partition has a UUID. It is the filesystem's UUID that matters. FAT filesystems don't have a UUID but they have something that is a bit like one: the "serial number". That's what Linux considers to be the filesystem's UUID. Each FAT filesystem has a likely-unique serial number. It is 8 hex digits, sometimes shown with a "-" between the fourth and fifth characters. It is generated randomly by the file-system formatter. We need to get the new VFAT FS's serial number to be the same as the old ones. 1a) note the old FS's UUID. You can glean it from the UUID field of the /etc/fstab entry for the ESP. Or you can figure it out from the gnome "disks" program (before you blow away the old FS). 4) fix up the serial number using mtools mlabel command. Note the serial must not have "-" in it. From <https://superuser.com/questions/1247972/how-to-change-vfat-partition-uuid> sudo mlabel -i /dev/sda???? -N 12345678 where ???? gets you the correct ESP partition and 12345678 is the desired UUID / serial number. If you use mtools to create the FAT filesystem, you can probably specify the serial number and not have to go back to fix it up.