== 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
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.
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
