[GTALUG] long war story: growing the ESP (/boot/efi)

[D. Hugh Redelmeier]

== 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.