EFI System Partition: Using it as /boot versus /boot/efi

This is a more generic Linux question. As I have an EFI motherboard with Secure Boot I need an ESP partition: I have one mounted as /boot/efi and it works fine on this installation. But I was wondering; Is there any disadvantage to making the entirety of /boot my ESP? That way I can make better use of the 4GB I assign to it, having it store grub and the kernel images too… they’re all loaded temporarily as part of the boot process so it makes sense to use this one little partition for everything! As long as it’s fat32 there shouldn’t be anything breaking the configuration right? Especially on a machine where I don’t plan to dual-boot, only one OS installed on the main drive so there would be no kernel image conflicts.

Just in case though I wanted to ask for opinions: Does anyone else place the entirety of /boot on the EFI partition instead of just /boot/efi? Does it work well for you, do you find it more optimal this way? As a bonus question; Is exfat (fat64) a newer and better partition format to use, or is it still a good idea to stick to fat32 exclusively for the ESP else the BIOS might complain?

Hi
Never tried it… no plans to, I have a separate boot, ideally it doesn’t need to be more than 260MB (FAT only), some manufacturers install efi utilities, BIOS updates, efi-shell (non-secure boot only), test utilities, never seen a need for any bigger…

Best to have a read here: https://uefi.org/specifications

I normally use 500M for the EFI partition. I’m inclined to think that 4G is too big.

The KaOS distro does this. I am not a big fan of that decision, but it has not caused any problems when I try KaOS.

Especially on a machine where I don’t plan to dual-boot, only one OS installed on the main drive so there would be no kernel image conflicts.

Yes, dual booting can be a potential problem with that scheme. But as long as you don’t dual boot, I am not aware of any particular problems.

I’m not sure whether “exfat” is compatible with the EFI specification. I think it isn’t.

Thanks for clarifying. The only notable issue someone brought up is that the FAT filesystem doesn’t allow symlinks; On openSUSE this may be a problem as the latest kernel is symlinked. Arch / Manjaro doesn’t appear to do this by comparison: I didn’t find any symbolic links within /boot so it should be good on at least some distros.

I there an advantage? Turn off secure boot. I never considered moving linux files to FAT. I never used a large EFI system Partition. 100 MB suffice for 10 distributions:

**3400G:~ #** df -h /boot/efi 
Filesystem      Size  Used Avail Use% Mounted on 
/dev/sda1       100M   34M   67M  34% /boot/efi 
**3400G:~ #**

Tumbleweed occupies 0.3 MB here:

**3400G:~ #** ll -h /boot/efi/EFI/tw-btrfs/grubx64.efi 
-rwxr-xr-x 1 root root 312K Mar 31 08:57 /boot/efi/EFI/tw-btrfs/grubx64.efi
**3400G:~ #**

IMHO you should keep the EFI partition as clean and lean as possible (see most advises above). It is not part of your openSUSE system. Better look at it as an extension of the BIOS, and you do not see the BIOS as part of openSUSE either I guess.
It is only mounted at /boot/efi to give access to it using your openSUSE system. Not to use it for anything else. Like you should only use any other non-Linux file system only for the direct exchange of data between a Linux system and a non-Linux system and never as an integrated part of your Linux system.

I’ve seen reports that mounting the ESP to /boot/ seems to be supported in Slackware. I tried doing it with a 15.3 test installation some weeks ago and failed to make it boot without moving the kernels & initrds back to a Linux native filesystem for /boot/ and mounting the ESP on /boot/efi/. It’s disappointing that a relatively modern specification like UEFI requires a crude and ancient filesystem. :frowning:

Of course when you mount something to /boot, it will make all that is there already unavailable.

Thus either you have organized all in /boot being in the root partition / and then mounting whatever file system (in your case the EFI FAT file system) over /boot will make the Grub configuration, the kernel and all what is in /boot unvisible to the ready system, or you have organized a separate file system for /boot, in which case it depends on what is mounted first on /boot, the boot file system or the EFI file system, the second mount will prevail in what is visible.

E in UEFI means Extensible. You may extend it via loading modules.

Loading modules via UEFI firmware (genericially speaking, BIOS), before Grub? The spec requires control switched from “firmware/BIOS” to code from some storage medium filesystem formatted only as some form of FAT, so FAT is the only place I can think of where additional modules might be available, at which point, boot process has been pushed over the cliff, too late for loading additional modules.

And where these modules are supposed to be loaded from?

UEFI can load code into RAM from some storage with FAT FS.
Try to use rEFInd: UEFI loads rEFInd executable, then, if used decieds, rEFInd loads another stuff.

GNU-EFI and TianoCore are supported as main development platforms for writing binary UEFI applications in C to launch right from the rEFInd GUI menu. Typical purposes of an EFI application are fixing boot problems and programmatically modifying settings within UEFI environment, which would otherwise be performed from within the BIOS of a personal computer (PC) without UEFI.[5]](rEFInd - Wikipedia)

You claimed before that storage with FAT FS is not needed because UEFI is “extensible”.

No. I wrote

E in UEFI means Extensible. You may extend it via loading modules.