On 2024-02-22, Wol <antli...@youngman.org.uk> wrote: > On 22/02/2024 21:45, Grant Edwards wrote: >> I've been reading up on UEFI, and it doesn't seem to be any >> better. People complain about distro's stomping on each other's files >> in the ESP partiton and multiple distro's using the same name in the >> boot slots stored in NVM. And then the boot choice order changes >> (though it may not be apparent to the naked eye) when one of the >> distros decides to update/reinstall its boot stuff. > > At least if you use UEFI *as* your bootloader, then that won't > happen. That assumes you're using UEFI, though!
According to what I've read UEFI isn't a bootloader. It's a boot manager which can load and run EFI bootloaders (of which there can be multiple installed). > In which case, <distro>'s bootloader doesn't get a look-in. Yes, AFAICT, it does (sometimes?). When you install <distro> under UEFI it installs EFI bootloader files (either kernels wrapped in EFI bootloader executables or the grub EFI bootloader) in the EFI Systgem Partition (ESP), and then adds one or more entries in the EFI NVM that points to those files (or something like that). The Linux UEFI systems I have all still use grub2 (which gets written to the ESP). It's entirely possible for one distro to overwrite files in the ESP that belong to other distros. I've read multiple complaints about exactly that when trying to do multi-boot with UEFI. In practice it's just like the fight over who owns the MBR and the DOS disklable gap. One recipe I read about for doing what I wanted to do with UEFI involved installing a Linux distro (didn't really matter which), then installing rEFInd. After that, some manual renaming and deleting of the files in the ESP was required. Then he started installing various distros. After each distro installation, the author had to re-install rEFInd, and after many of them he had to manually remove or rename files in the ESP (or adjust the rEFInd config file). And in the end, he ended up with multiple menu entries (for different installations) that had identical names. It was more complicated and difficult than my current scheme. > As for "<distro>'s obviously superior bootloader", well <other distro> > is using the exact same boot-loader, and when IT installs, how is it > going to be able to boot <distro> if it can't call <distro>'s boot > loader because it's just trashed it by overwriting it? In my experience, <distro>'s bootloader does not boot other installations by calling other bootloaders. It does so by rummaging through all of the other partitions looking for kernel images, intird files, grub.cfg files, etc. It then adds menu entries to the config file for <distro>'s bootloader which, when selected, directly load the kernel image and initrd from those other partitions. Sometimes, it works -- at least until those other installations get updated without the knowlege of the distro that currently "owns" the MBR's bootloader config. Then it stops working until you tell that bootloader to re-do it's rummaging about routine. > To me, you seem to be describing the *default* installer setup, that's > been there for ever. Last I installed SUSE, iirc I had to specify > "advanced bootloader installation", most of who's options I didn't even > understand!, but it did do what I told it to (apart from not recognising > my weird disk stack!). So SuSe still allows you to install grub to a partition instead of MBR? That's encouraging. RH and Ubuntu used to allow that, but AFAIK, now they do not. > If you can find, and understand!, that advanced options, I think > you'll find you can do what you want. I'd welcome pointers to where those advanced options are in the RH and Ubunutu installers -- I've searched everywhere I can think of. Various things Google has found lead me to believe that they no longer support installing grub in a partition. I guess I'll stick with my current setup. Or perhaps I'll switch from a DOS disklabel to a GPT disklabel. Instead of backing up and restoring the MBR and the gap, I would backup and restore the MBR and the BIOS boot partition. And I could use UUIDs and partition labels.
