So in simpler terms, a number of glaring problems have now been resolved.

When will ARM platforms adopt this? It would make support much easier

trsttteWhen will ARM platforms adopt this? It would make support much easier

Server ARM platforms do support UEFI by default (such as Ampere's products).
For SBCs, since they have their own custom firmware, you usually need to build your own bootloader and then you're free to boot something like edk2 on top of it for UEFI support.

lexluthermiesterSo in simpler terms, an number of glaring problems have now been resolved.

A shame they don't improve multi-boot OS scenarios and bootloaders nuking each other. Whilst for sure, there is a large responsibility for OS installers to get it right, UEFI implementations with inconsistent approaches to how they list boot entries is still (for many motherboards and OEM system makers) a bit of a joke.

VinceroA shame they don't improve multi-boot OS scenarios and bootloaders nuking each other.

Agreed. That is a problem that needs to be resolved.

VinceroA shame they don't improve multi-boot OS scenarios and bootloaders nuking each other.

Not aware of this, would you mind expanding, thanks. FWIW I've only seen "Windows attempting repairs" do something like this, destroying other systems on the UEFI system drive and then saying it wasn't able to fix it, FUBAR. Not always like that but always scares me when Windows gives that message! Now Windows has it's own system drive, not shared.

:D:DNot aware of this, would you mind expanding, thanks. FWIW I've only seen "Windows attempting repairs" do something like this, destroying other systems on the UEFI system drive and then saying it wasn't able to fix it, FUBAR. Not always like that but always scares me when Windows gives that message! Now Windows has it's own system drive, not shared.

Yeah, to be fair the problem isn't Windows as an OS, but the decisions made for that repair process - it basically assumes a) the user isn't aware of other OS on the system, and b) any EFI components not meant to be there are, well, just not meant to be there. It's a bad/obnoxious way to operate, but I guess for 99% of the user scenarios out there its the right one, and that other 1%.... well I guess MS knows we love them like that weird uncle who's now in prison that was always a bit too handsy when we were growing up.

To be fair, the GRUB and Windows Boot Manager installation routines do try to co-exist with other OS on the same drive - you can have Windows correctly identify and list a non-MS OS in it's boot screen and the same with GRUB listing Windows. It's just a shame that with Windows EFI, the boot options are only shown once Windows has part loaded most of the OS to show the boot options - picking another OS basically restarts the system and loads that one.
GRUB is more like the older NT4/2K/XP boot manager methodology where it will display the OS options as soon as the boot loader runs, and picking an OS then just starts that OS.

My bigger issue is how the BIOS will hande the EFI options. The BIOS will scan the EFI partition and boot whatever it finds, but the implementation and management of this on various BIOS UEFI implementations is literally all over the place. I've seen some hard-coded to only accept 'Windows Boot Manager' (admittedly old systems), some which will list out multiple EFI options but list them all as 'Windows Boot Manager' or some such even though one may be windows and another may be Linux (e.g. Ubuntu will normally appear as 'ubuntu' on an EFI list when done properly).
Worse still, on some BIOS UEFI implementations, if you wipe the system drive and install a new OS, the existing EFI boot options are still in the list (admittedly, now lower in order) so you just have duplicate entries that are pointless.

But due to that behaviour of newer EFI Windows OS and multiboot - where you need to wait for Windows to part boot before being able to choose the OS you want and it then restarts to finally load that other OS - not one system / motherboard vendor that I'm aware of (out of the big mainstream vendors) seems to have added an option to display an EFI boot loader choice at boot-up, with it fail-over to the last choice used if no input within xx seconds (which would make sense if doing updates on a remote/headless box).
People shouldn't need to look at using and manually tinkering with something like Clover, GRUB or other options to achieve this. If BIOS vendors have enough ROM space for LED light control, fan profiles, and storing multiple OC/fan and BIOS settings in different profiles, I think they can crack this problem.

And don't get me started on TPM and the alien concept of having more than one OS on the same system...

VinceroI've seen some hard-coded to only accept 'Windows Boot Manager' (admittedly old systems), some which will list out multiple EFI options but list them all as 'Windows Boot Manager' or some such even though one may be windows and another may be Linux (e.g. Ubuntu will normally appear as 'ubuntu' on an EFI list when done properly).

I faced that once, had a B550 motherboard (don't remember if it was an Asrock or MSI one) that only wanted to boot the Windows' bootloader EFI file it if was present by any reason.
I had a leftover windows .efi from years ago in a disk that didn't even had windows, and found it weird why I wasn't able to boot by any means, until I noticed the firmware was straight away ignoring the options I had set for boot order and whatnot. Removing the windows .efi did the trick, but also if I just renamed my systemd .efi to match the windows one (EFI/Microsoft/Boot/bootmgr.efi) it would always force boot it no matter what.

VinceroWorse still, on some BIOS UEFI implementations, if you wipe the system drive and install a new OS, the existing EFI boot options are still in the list (admittedly, now lower in order) so you just have duplicate entries that are pointless.

Yeah, that's likely bad handling of the nvram, could be either the firmware itself or the software installing stuff.

Vinceronot one system / motherboard vendor that I'm aware of (out of the big mainstream vendors) seems to have added an option to display an EFI boot loader choice at boot-up

Usually you can select the boot order in your UEFI settings, and those are often the different .efi files found across your FAT32 partitions across your disks, but yeah, no such thing at boot-up unless you go directly into the efi shell

@Vincero I have an old X99 system and the last BIOS was about 6 or 7 years ago I think. Sure, has some problems. For one it adds an entry for BOOTX64.EFI each reboot resulting in multiple instances so ended up renaming it BOOTX64.EF as not used.

Once the windows boot manager is loaded then the ball is in Microsofts court. Did have a problem with {bootmgr} entry having wrong device info which resulted in windows adding an extra entry to nvram that didn't do anything. Deleting it from nvram only saw it return again once Windows OS ran. The volume doesn't tie in with DISKPART either so assigned a letter to that system drive temporarily to use with bcdedit to correct it, problem solved.

Sometimes I temporarily remove drives so would want nvram to keep boot entries for it. They are not shown on the BBS but return when disk is attached which personally I like. Can result in having to reselect default boot if that was on the removed drive though.

I guess Microsoft have a reason to reboot when the default isn't selected but if you want to restart to a different windows OS the advanced option "shift + restart" or "shutdown /r /o" can be used and "use another operating system" selected for alternate windows OS's. For other non windows BBS entries the "use a device" option can be had. If wanting to boot the last selected windows each time then perhaps auto running bcdedit at start with /default {current} option.

It's not perfect but some stuff can be worked around.