/boot is a partition that your boot loader needs to know about ahead of time, and I still have to point my BIOS towards a disk that has the correct code embedded in a section at the beginning of the disk in order to execute it to read its config to know about /boot.
With UEFI, the pre-boot system can automatically detect OSes that are installed on any disks that exist, and can let you choose which ones to run before executing any other code.
This eliminates the issues of e.g. installing Windows (with its boot loader) and then Linux (with its replacement boot loader) overwriting that and then having to add an entry to boot the old OS, and so on. Now all OSes and boot loaders are accessible from the same level and OS installers don't have to worry about wiping out the other ones unless they're deleting partitions.
> again, grub handles this. in fact, it handles it much better than some firmwares
I have had significant issues with Grub when, for example, migrating from one disk to another, having to swap boot drives, change kernel boot parameters, run chroots, and so on, all to make sure that Grub puts the right code at the start of the right disk to point to the right partition ID to read the right config file to load the right kernel.
Nothing is perfect and foolproof, and Grub on UEFI is vastly better than Grub on BIOS/MBR/etc. in my experience.
> With UEFI, the pre-boot system can automatically detect OSes that are installed on any disks that exist, and can let you choose which ones to run before executing any other code.
the boot entries are stored in the firmware, not on the disk. therefore, any new disks can only boot the default binary (\EFI\BOOT\BOOTX64.EFI usually). so, if you regularly get new drives, you need to install a boot manager anyways, which is the same as the BIOS experience in the end, except with more chances for the shitty shitty vendor firmware to fuck something up.
> This eliminates the issues of e.g. installing Windows (with its boot loader) and then Linux (with its replacement boot loader) overwriting that and then having to add an entry to boot the old OS, and so on. Now all OSes and boot loaders are accessible from the same level and OS installers don't have to worry about wiping out the other ones unless they're deleting partitions.
1. grub 2 auto-detects Windows by default, and other boot loaders required you to manually write entries anyways; if you forget to add the Windows entry while you're in there anyways, that's your own problem (and no big loss anyways).
2. as I said, the firmware boot entry manager is often if not usually total shit. even better, Windows (or probably some poorly-written vendor drivers that assume you only have Windows) has been reported to fiddle with boot entries even after installation! at least in the BIOS system, I set it up and it worked. now I have to reconfigure it every time I boot into Windows?
> I have had significant issues with Grub when, for example, migrating from one disk to another, having to swap boot drives, change kernel boot parameters, run chroots, and so on, all to make sure that Grub puts the right code at the start of the right disk to point to the right partition ID to read the right config file to load the right kernel.
If you configure your /etc/fstab correctly, none of these steps are necessary. literally no configuration is necessary if you just use the "dd" command. if you use "cp", obviously you will need to reinstall the boot loader. this is the only thing that the ESP does better (as long as you remember to copy the ESP contents and not just the main filesystem, but that's not too hard).
With UEFI, the pre-boot system can automatically detect OSes that are installed on any disks that exist, and can let you choose which ones to run before executing any other code.
This eliminates the issues of e.g. installing Windows (with its boot loader) and then Linux (with its replacement boot loader) overwriting that and then having to add an entry to boot the old OS, and so on. Now all OSes and boot loaders are accessible from the same level and OS installers don't have to worry about wiping out the other ones unless they're deleting partitions.
> again, grub handles this. in fact, it handles it much better than some firmwares
I have had significant issues with Grub when, for example, migrating from one disk to another, having to swap boot drives, change kernel boot parameters, run chroots, and so on, all to make sure that Grub puts the right code at the start of the right disk to point to the right partition ID to read the right config file to load the right kernel.
Nothing is perfect and foolproof, and Grub on UEFI is vastly better than Grub on BIOS/MBR/etc. in my experience.