|
|
|
|
|
|
by Nextgrid
2221 days ago
|
|
|
Well first of all the goal is that there would be no debugging required if the system works well, and in my opinion less moving parts (like GRUB) means less chance that something breaks. The UEFI boot entries can be configured by the operating system with the "efibootmgr" command (http://manpages.ubuntu.com/manpages/bionic/man8/efibootmgr.8...) so if a more user-friendly version of it is required then a GUI can be written around that. Whether it's necessary or not is another matter because as far as I know there is no GUI around the GRUB configuration either and it mostly works. Speaking of GRUB, how it works in Ubuntu land is that there are a couple of scripts that read different configuration files to generate the final GRUB configuration file which is actually a bash-like script (yes, GRUB implements a scripting language) and if you look at it you'd be horrified. The UEFI way of doing things is much simpler. So the idea would be to 1) check whether the installer is booted in UEFI or BIOS, if UEFI then check if an existing OS is installed and whether it boots in BIOS or UEFI mode (whether the drive is partitioned in MBR or GPT), and then decide whether to skip GRUB (for UEFI-capable configurations) or keep it (for BIOS systems). |
|
|
There are many bootloaders you could choose from efistub (which you mention), gummiboot, refind ... . Having one with a user visible interface is useful if you either dualboot or want to expose things like previous kernels or filesystem snapshots.
> So the idea would be
Sure you could do that, or you could set grub timeout to zero if multi booting, larger timeout if not and present the same familiar interface no matter whether you use UEFI or BIOS.