Resizing the ESP /boot/efi partition

RoqueOne · 07-02-2017, 05:26 AM

Guys, I actually went ahead with expanding my /boot/efi from the previous 250 MB to the present 1 GB with GParted in SystemRecueCD. It was not without its scare though.

The error message informed that GParted wasn't able to resize the FAT32 partition and that they are working on it. However I was able to install Antergos-17.6 and its own grubx64x.efi in /boot/efi/EFI/antergos_grub. That said, I recall seeing a message while using the GParted that comes with the Antergos installer CD saying something to the tune of "unallocated space in the /boot/efi partition" and to select the Check option in one of GParted menu to grow the aforementioned partition. I did as told but as with GParted in SystemRescueCD, GParted again failed with the same error message i.e. that they are working on it. I must add that I did re-enable Secure Boot in my Acer BIOS and get it to recognized Antergos as well as Debian's efis as Trusted sources then disabling Secure Boot again before I was able to successfully boot into either Debian or Antergos. Seemingly at present, with no adverse effects.

While I seem to have come away somewhat unscathed by the episode, should I be worried about the GParted warnings? Are there or could there be any long-term issues? What can I do about the unallocated space in my now 1 GB (see at end of this post snippet from discus' output on my /boot/efi) hydrurga? syg00? Anyone?

Code:

# fdisk -l
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 94DB51F1-DD44-4187-8FE5-0D10162249B5

Device          Start        End   Sectors   Size Type
/dev/sda1        2048  107421695 107419648  51.2G Linux filesystem
/dev/sda2   107421696  175781887  68360192  32.6G Linux filesystem
/dev/sda3   175781888  234375167  58593280    28G Linux filesystem
/dev/sda4   234375168  265625599  31250432  14.9G Linux swap
/dev/sda5   265625600  382812159 117186560  55.9G Linux filesystem
/dev/sda6   382812160 1164062719 781250560 372.5G Linux filesystem
/dev/sda7  1164062720 1166110719   2048000  1000M EFI System
/dev/sda8  1166110720 1278750719 112640000  53.7G Linux filesystem
/dev/sda9  1278750720 1360670719  81920000  39.1G Linux filesystem
/dev/sda10 1360670720 1422110719  61440000  29.3G Linux filesystem
/dev/sda11 1422110720 1463070719  40960000  19.5G Linux swap
/dev/sda12 1463070720 1585950719 122880000  58.6G Linux filesystem
/dev/sda13 1585950720 2476830719 890880000 424.8G Linux filesystem

Code:

# ls -al /boot/efi/EFI/debian
total 185
drwx------ 3 root root    512 Jun 24 10:17 .
drwx------ 8 root root    512 Jul  2  2017 ..
drwx------ 2 root root    512 Jun 24 10:17 fw
-rwx------ 1 root root  63629 Jun 24 10:17 fwupx64.efi
-rwx------ 1 root root 123904 Jun 24 08:37 grubx64.efi

Code:

# ls -al /boot/efi/EFI/antergos_grub
total 123
drwx------ 2 root root    512 Jul  2  2017 .
drwx------ 8 root root    512 Jul  2  2017 ..
-rwx------ 1 root root 124416 Jul  2  2017 grubx64.efi

Code:

# ls -al /boot/efi/EFI/BOOT
total 2
drwx------ 3 root root 512 Jul  2  2017 .
drwx------ 8 root root 512 Jul  2  2017 ..
drwx------ 2 root root 512 Jul  2  2017 BOOTX64.efi

Code:

/boot/efi       234.3 MB       1.2 MB     233.1 MB     0.5%   [----------]

hydrurga · 07-02-2017, 06:38 AM

Hi RogueOne.

What appears to have happened is that GParted has resized the actual partition correctly (1GB seems excessive but that is your choice) but has failed to expand the actual fat32 filesystem it contains.

There is a program called fatresize that might be of use to you (it is in the Ubuntu repos, I'm not sure of its availability elsewhere) which could do the trick. Image your ESP partition first.

http://manpages.ubuntu.com/manpages/...tresize.1.html

https://unix.stackexchange.com/quest...thin-partition

As an aside, an experience with GParted I had in my early Linux days led me to the strategy of using GParted/GParted Live for any ext or other Linux-related filesystem partition resizes or moves, and MiniTool Partition Wizard, a Windows program run off boot media, for any fat/ntfs resizes or moves. Although it may appear a bit long-winded, I've never had any problems since I began that strategy. I didn't mention that in order not to complicate things, because I thought that my problems had been particular to me and that I was being over-cautious with this strategy. Given however what you experienced, you might consider it too. For the current issue though, use fatresize.

RoqueOne · 07-03-2017, 10:56 AM

Thank you again hydrurga.

Yeah, I should most probably have used GParted Live instead of SystemRescueCD for such operations but then again I did try to expanding the ESP partition using the GParted provided for in SystemRescueCD.

I suppose as with the original resizing, fatresize will not allow me to perform a resizing of the FAT32 filesystem. I will most probably have to resort to using a "live" cd where I'm allowed to install packages (assuming the "live" cd does not include it) to help with me with it. A "live" cd like the Debian 9 "live" images or one of the *buntu ones or Arch-based ones - yes, fatresize ported over from Ubuntu is in AUR.

hydrurga · 07-03-2017, 11:44 AM

Quote:

Originally Posted by RoqueOne

Thank you again hydrurga.

Yeah, I should most probably have used GParted Live instead of SystemRescueCD for such operations but then again I did try to expanding the ESP partition using the GParted provided for in SystemRescueCD.

I suppose as with the original resizing, fatresize will not allow me to perform a resizing of the FAT32 filesystem. I will most probably have to resort to using a "live" cd where I'm allowed to install packages (assuming the "live" cd does not include it) to help with me with it. A "live" cd like the Debian 9 "live" images or one of the *buntu ones or Arch-based ones - yes, fatresize ported over from Ubuntu is in AUR.

Depending of course on which version of SystemRescueCD you were using, and the version of GParted it included, I don't think there would be too much of a difference between using the latest version of GParted found on there and the one on GParted Live. You could check out the version numbers out of interest.

Personally, I would give fatresize a go "online", but the safer option might be, as you suggest, to do it offline. Either way, image the ESP first just in case.

Another option would be to use an offline Windows-focussed tool such as MiniTool Partition Wizard to very slightly reduce the partition size and see if it auto resizes the filesystem to fill that partition. If it does, then you can always then enlarge the partition back to its original size.

RoqueOne · 07-03-2017, 09:55 PM

Quote:

Originally Posted by hydrurga

Depending of course on which version of SystemRescueCD you were using, and the version of GParted it included, I don't think there would be too much of a difference between using the latest version of GParted found on there and the one on GParted Live. You could check out the version numbers out of interest.

Personally, I would give fatresize a go "online", but the safer option might be, as you suggest, to do it offline. Either way, image the ESP first just in case.

Another option would be to use an offline Windows-focussed tool such as MiniTool Partition Wizard to very slightly reduce the partition size and see if it auto resizes the filesystem to fill that partition. If it does, then you can always then enlarge the partition back to its original size.

Yup, will image the ESP partition and will opt for the offline resizing. I did tried giving it a go while still booted into my Debian a short while ago.

Code:

fatresize /dev/sda7 -s 1000M

This was the returned:

Code:

fatresize 1.0.2 (01/27/16)
Error: Partition /dev/sda7 is being used.  You must unmount it before you modify it with Parted.

The Windows and MiniTool Partition Wizard route probably would have been a far easier route but that will entail me having to slap that 128MB SSD on which Windows 10 is installed back onto this laptop.

A "live" cd has an advantage in the sense that it allows one to install packages that may come in handy for use in a variety of situations. So I'll definitely use it over a non-"live" one. It's just that the SystemRescueCD was staring at me in the rack I have in front of me and somehow I gave in and used it instead. Sometimes I really need to not give in to impulse.

For whom it may concern something interesting showed up when I typed man fatresize i.e.

Code:

BUGS
       You can't resize FAT32 partition lesser than 512Mb because Windows(R) doesn't work properly with small FAT32 file system. Use FAT16.

While I may not have Windows on this particular HDD and my ESP partition (i.e. /boot/efi on dev/sda7 is 1000MB) hence the bug concerns me not, its existence is a known issue and may be related to something I found on one of my recent googling that affects those dual booting with Windows https://superuser.com/questions/1034...d-fat32-as-raw
.