The 100 MB partition FAT32 for /boot/efi/ is fine for GRUB.
Note: 100 MB is too small when switching from GRUB to systemd-boot on the same partition without reinstalling OS in your future.
600 MB would be enough if you want to install 3 kernels (Each kernel has a default image and a fallback image) in the parition FAT32 for systemd-boot using /boot or /efi.
It is rather small, to be flexible enough.
Only grub as far as i know allows you to place your kernel(s) and ramdisk(s) in your Linux partition, any other bootloader needs to be able to access those from within the ESP.
Because you said:
I would highly advise you to re-partition your HD and start by creating an ESP of at least ~500MiB. (I personally use 1GB)
It will save you a lot of headaches in the long-run, especially when you will need to have alternative kernels for your Linux.
A good start is half of the efforts needed later on…
The ESP is mounted on /efi or /boot/efi never use the ESP on /boot…
It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. If $BOOT and the ESP are the same, then either a bind mount or a symlink should be established making the partition available under both paths.
(Mounting the ESP to /boot/efi/, as was traditionally done, is not recommended. Such a nested setup complicates an implementation via direct autofs mounts
Yea i noticed that change in the official docs also since last time i consulted it when it was still at systemd
But…their use of $BOOT and $ESP have different meaning…
They have always encouraged to mount the $ESP at /efi
It’s unfortunate that they used that sentence “If $BOOT and the ESP are the same” because:
The $ESP is supposed to hold binaries that are executable by the UEFI-BIOS (normally having .efi as extension) and not binaries that are OS specific (Those are meant to be in $BOOT)
But at least now i know who started this confusion
I might have influenced the decision to create such wording, because i might have posted about my setup using a bind-mounted sub-dir inside the /efi as /boot to put files that are normally put in /boot be placed in a sub-dir of the ESP per distro used in one of their github issues…
eg.: /efi/Manjaro ⇒ /boot for usage with systemd-boot …
I think systemd autofs/generator or whatever it’s called will mount it to /efi as well (I think I disabled that ).
The point is, if you use systemd-boot at least, this is the simplest thing to do. Create 1GB or whatever large ESP and mount it to /boot and you don’t have to deal with copying kernels or that extended boot partition and what not. And if you go by archwiki you’ll read the same thing.
I have it like that (on arch) and I threw some grml image there for rescue and I’m happy. Maybe next time I do the installation I’ll do it some other way. More I complicate things, more I’m clueless when something breaks…
UEFI-Shell’s and the like tools used directly from the UEFI can be and mostly are not using the subdir $ESP/EFI Most UEFI-BIOS’es that have an option to boot into an UEFI-Shell expect that binary at the root of the $ESP
To make it a little bit more clear: You can imagine/view the UEFI as an operating system on it’s own, that runs in background of your OS…
Just like the legacy BIOS used to be.
But i think we have fried many reader’s minds already enough with this off-topic debate sub-topic
I’m fairly certain you guys are somewhat horribly confusing poor OP…
Yes, if you use the Grub bootloader (as is at the time of writing normal on Manjaro as well as still on most any Linux distribution) then 100M will do; in that case only the main Grub executable and other bootloaders such as the Windows one reside on the ESP as such with what they load – in the case of Linux kernels and initramfs-en – on a different filesystem.
100M isn’t too roomy and nowadays you’d most typically see an ESP of around 500M – but it’s fine until it no longer is…