From: Lennart Sorensen via Talk <talk@lists.gtalug.org>
I know Debian puts the kernel and initramfs in /boot and only puts grub on the UEFI partition. Why would any distribution put the kernel files on the UEFI partition? That sounds like a dumb thing to do.
I think I have read some distributions mount the UEFI partition as /boot and then dump crap in there, so I can see how that would be a problem.
Checking opensuse, I see kernel and such in /boot and the uefi partition with grub is mounted as /boot/efi.
GRUB has to understand all filesystem types that might contain the kernel and initramfs. This is goofy. Especially when you realize implementations may accidentally diverge. - filesystem code must be in the kernel AND in GRUB - GRUB gets larger and larger over time as potential filesystems get added - GRUB holds back filesystem and RAID etc progress. Just dump every file that GRUB must deal with into the ESP. Then GRUB only needs to handle DOS filesystem variants. And that code is already in the UEFI firmware so it need not understand any filesystem at all, it just needs to use the UEFI API for files. In fact, I think there is a move to package kernels as .efi files and let the UEFI firmware boot it directly. In an EFI world, what value does GRUB add? Anything beyond what an EFI shell would provide? As far as the size of the ESP, 100M is clearly too small. If you google, you will find that pure Win 11 systems are now banging into that limit. My default would be 1G because why not? I find it irritating that gparted won't resize a 100M ESP. And it won't move a Microsoft Reserved / Restoration partition. That's what I'm faced with on machines with pre-installed Windows. I could just throw away the Windows installation but I don't want to. <https://askubuntu.com/questions/1491415/gparted-always-fails-at-resizing-the-efi-boot-partition-how-can-i-fix-it>