Linux 5.7 EFI Changes: "The GRUB Project Is Showing Signs Of Life Again"

[kreijack]

Even assuming you are formatting the ESP partition as FAT16, that's up to 4 GB of space. With FAT32 you can have up to 2TB.
I mean, it's just a partition on the drive, enlarge it.

It is a lot simpler having a small ESP partition which hosts the "bootloader", which in turn load the kernel/initramfs from the main partition...

[Neuro-Chef]

I haven't found this happen on my install.

Same. Might happen when you're multibooting different systems of the same drive, which to do was never worth the trouble .. if you could install more drives. Yes, I'm looking at you, shitty recent T series Thinkpads with one M.2 slot only

[starshipeleven]

It is a lot simpler having a small ESP partition which hosts the "bootloader", which in turn load the kernel/initramfs from the main partition...

No it is not, as if you do it like that your bootloader must have drivers for all filesystems you might want to use, RAID, LVM, encrypted partitions and so on, just like in MBR days.

GRUB checks all the boxes to be called an operating system, let that sink in.

If you drop your kernel/initramfs in the ESP you don't need a complex bootloader (technically speaking you don't need a "boot loader" at all, both refind and systemd-boot are "boot managers", plain UEFI applications), and whatever feature is used in the root filesystem/raid/LVM/encrypted setup becomes irrelevant.

[mppix]

It is a lot simpler having a small ESP partition which hosts the "bootloader", which in turn load the kernel/initramfs from the main partition...

starshipeleven explains why this is challenging.

GRUB makes it actually worse: the default setup of grub (in Debian, Fedora, ...) is that grub puts grub.efi in the FAT formatted esp partition mounted to /boot/efi. From there grub loads the kernels located in the ext2/3 formatted /boot. Then, the kernel mounts the partitions (often the root / and /home) in whatever format they are (encrypted, LVM, RAID, ...).

The above boot sequence is a pretty bad hack.
1, the ext2 /boot partition is redundant with efi.
2, only grub.efi can cross-load the kernel from an ext2 partition
3, distributions still need to use systemd-boot bootctl to set the EFI boot sequence to grub.
4, fwupd relies on efi to load firmware updates (essentially you reboot into the fwupd "os"
5. your efi needs to find your .efi file (be it grub, fwupd, or a kernel) so there is no reliability difference

[mppix]

Other than apple (which supports theirs own filesystem(s)), are there UEFI implementations that support something other than FAT* ?

Well if you count grub-efi as an elaborate efi filesystem driver, it supports a number of filesystems, mainly ext2.
grub-efi typically does not do much more than mounting ext2 /boot and start the kernel

[dragon321]

Windows doesn't do that. It's your (likely buggy or has some weird secure boot setup) UEFI's fault. Just enter UEFI setup and in some cases you can fix that by forcing the UEFI to trust Linux's efi files

I have Secure Boot disabled on my laptop (problematic when using external drivers like Nvidia blob).

[kreijack]

No it is not, as if you do it like that your bootloader must have drivers for all filesystems you might want to use, RAID, LVM, encrypted partitions and so on, just like in MBR days.

We are seeing the thing from two different prospective:
- my one is : because grub exists, I find using it in my setup a simpler solution
- your one is : in order to leave kernel/initramfs in the main extX/btrfs/... filesystem I need a complex bootloader that understand these filesystem

Fortunately grub existed before UEFI, so it is free to use. Using it doesn't adds any complexity.

G.

[kreijack]

starshipeleven explains why this is challenging.

GRUB makes it actually worse: the default setup of grub (in Debian, Fedora, ...) is that grub puts grub.efi in the FAT formatted esp partition mounted to /boot/efi. From there grub loads the kernels located in the ext2/3 formatted /boot. Then, the kernel mounts the partitions (often the root / and /home) in whatever format they are (encrypted, LVM, RAID, ...).

The above boot sequence is a pretty bad hack.
1, the ext2 /boot partition is redundant with efi.

I don't use a /boot dedicated partition. As told before, the biggest (in my case) advantage of a bootloader like grub is that I am not limited by the space of ESP. I can put many kernel I want without worrying of the space in my root filesystem.
Dedicating more space than 1GB to an ESP partition for me is a waste of space. And sometime my plethora of kernel/initramfs versions (even tough this is a my fault, because i never clean up :-) ) consumes more spaces.

[...]
3, distributions still need to use systemd-boot bootctl to set the EFI boot sequence to grub.

I think that most distribution uses 'efibootmgr'.

4, fwupd relies on efi to load firmware updates (essentially you reboot into the fwupd "os"

This point how is implied in systemd-boot vs grub

5. your efi needs to find your .efi file (be it grub, fwupd, or a kernel) so there is no reliability difference

[mppix]

I don't use a /boot dedicated partition. As told before, the biggest (in my case) advantage of a bootloader like grub is that I am not limited by the space of ESP. I can put many kernel I want without worrying of the space in my root filesystem.
Dedicating more space than 1GB to an ESP partition for me is a waste of space. And sometime my plethora of kernel/initramfs versions (even tough this is a my fault, because i never clean up :-) ) consumes more spaces.

I hear you, my boot if permanently full
I know grub can use custom paths but can it load LVM and/or encrypt drives?