UEFI was shoved down our throat, but today I can't think of one example where UEFI is better than BIOS, other than the partition size limit.
There are plenty of other firmware systems that allow for the same thing, and I dislike UEFI as much as the next guy, but this is a feature that's been important at work.
There were tons of other ways this could have been accomplished for far less effort and with previously existing systems.
* Not having "extended partitions" as a concept to deal with
* OS booting not dependant on "load an MSDOS bootblock from LBA offset X"
What I dislike:
* Not having a minimal straightforward shell to troubleshoot from
* Not letting the UEFI variables be easily user accessible/fixable
You can BIOS boot from a GPT-partitioned disk just fine.
> OS booting not dependant on "load an MSDOS bootblock from LBA offset X"
The only offset that's hardcoded by the BIOS is LBA block 0. The rest is from your bootloader. And GPT partitioning allows you to put the bootloader code in a proper partition rather than in the void under the stairs: https://en.wikipedia.org/wiki/BIOS_boot_partition
> Not having a minimal straightforward shell to troubleshoot from
Download shellx64.efi from the (Intel) EFI development kit. When it's present in the root directory of your EFI System Partition, most firmwares will include an option to boot into that shell. Or is your objection that it's an DOS-inspired command prompt rather than a Unix shell?
> Not letting the UEFI variables be easily user accessible/fixable
Don't know about this one. The linux kernel supports reading and writing EFI variables through efivarfs, but I don't know if that is predicated on firmware support and whether it includes access to all variables.
There is a shell for UEFI. It feels a lot like a reimplementation of MS-DOS shell, with "FS0:" to change drives etc, but it has directory listings, file copying, etc.
The interface is standardized and there's an open source implementation in EDK2.
If you build Linux kernels as "EFISTUB", they're simply executables in the UEFI shell.
https://github.com/tianocore/tianocore.github.io/wiki/ShellP...
I'm working on that for one of my projects. A BIOS can use GPT partitions to have LBA48, but MBR partitions standards could laso be changed to use LBA48 instead of LBA32 which cause the limit
You could even use the CHS fields to have even more space if needed: there are 3 bytes for the CHS start, 3 others for the CHS end, both are often wasted by storing 0 for LBA32.
That said, I still consider UEFI to be better for at least 1) multiplatform support (have different /EFI/BOOT paths to payloads named by their architecture) 2) fallbacks (shell + startup.nsh) 3) defining how the persistence of settings work (efivars)