Most firmware systems don't enable interrupts, support paging, SMP, or many other things, for a long list of reasons, while at the same time, in order to enable a full Linux environment, ExitBootServices must be called, which is going to make a mess anytime the booting kernel isn't the right one. Kexec breaks a fair amount of the time if the target kernel isn't exactly what was already booted (ex, see kdump failures). Nevermind if the target OS isn't linux.
And for what? So /boot can stick around? A legacy partition left over from the days of BIOS/MBR like systems that have to have a small partition at the beginning of the disk, formatted with something that supports linux file permissions?
No, the right solution is to just place the kernel(s), and a small signed initrd (s) in the ESP, and nothing else besides a boot selector, like say systemd-boot to allow the user to select the correct kernel/OS, and optionally edit debug/etc options. Then, when the correct kernel is booted, it can bring up the network, filesystem, and whatever is needed.
That solves an endless list of Linux and firmware interaction problems that Grub currently solves, without all the file system, network code, etc., that one finds in Grub, which mainly duplicates the functionality already provided by UEFI.
The problem with this solution is that it doesn't work on systems that aren't UEFI, to which I might suggest that those systems (cough, legacy IBM junk, or hyperscalers still using BIOS boot after it has been deprecated everywhere else) have either uboot-uefi or edk2 ported so they can conform to modern boot standards.
Most firmware systems don't enable interrupts, support paging, SMP, or many other things, for a long list of reasons, while at the same time, in order to enable a full Linux environment, ExitBootServices must be called, which is going to make a mess anytime the booting kernel isn't the right one. Kexec breaks a fair amount of the time if the target kernel isn't exactly what was already booted (ex, see kdump failures). Nevermind if the target OS isn't linux.
And for what? So /boot can stick around? A legacy partition left over from the days of BIOS/MBR like systems that have to have a small partition at the beginning of the disk, formatted with something that supports linux file permissions?
No, the right solution is to just place the kernel(s), and a small signed initrd (s) in the ESP, and nothing else besides a boot selector, like say systemd-boot to allow the user to select the correct kernel/OS, and optionally edit debug/etc options. Then, when the correct kernel is booted, it can bring up the network, filesystem, and whatever is needed.
That solves an endless list of Linux and firmware interaction problems that Grub currently solves, without all the file system, network code, etc., that one finds in Grub, which mainly duplicates the functionality already provided by UEFI.
The problem with this solution is that it doesn't work on systems that aren't UEFI, to which I might suggest that those systems (cough, legacy IBM junk, or hyperscalers still using BIOS boot after it has been deprecated everywhere else) have either uboot-uefi or edk2 ported so they can conform to modern boot standards.