On Friday, 23 February 2024 00:28:59 GMT Grant Edwards wrote: > 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).
The UEFI firmware of the MoBo contains its own bootloader and a boot manager with its own boot menu, initialised and running from the MoBo's EEPROM. Unlike conventional/legacy bootloaders stored in the first sector of a disk (MBR), the UEFI firmware is stored in the MoBo's EEPROM, a larger equivalent to the old CMOS. However, this comes with the caveat the UEFI 'bootloader' can only load .efi executables which have already been placed in the FAT32 formatted EFI System Partition (ESP). Unlike GRUB's MBR Stage 1 bootloader code, the UEFI firmware is large enough to contain its own fs driver to be able to read the ESP fs content and identify and run all .efi applications. Kernel images which have been built with the EFI stub and therefore masquerade as .efi compatible files can be loaded directly by the UEFI firmware without the need of an additional bootloader. > > 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). Legacy GRUB on an MBR partitioned disk, writes its Stage 1 bootloader code in the first sector and Stage 1.5 with the fs drivers in sector 34, before the first partition. GRUB2 on a UEFI system installs the file /efi/<distro>/grubx64.efi in the ESP, an equivalent of the Stage 1 and Stage 1.5 of legacy GRUB. The Stage 2 /boot/ grub/ files can be installed either in the ESP, or on a different partition. > 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. It doesn't really matter if the grubx64.efi executable is overwritten, as long as the OS_PROBER is not disabled in /etc/default/grub. Re-running grub- mkconfig will re-scan the ESP and any drive/partitions, pick up any OS kernel images known by GRUB and add them to GRUB's boot menu. The problem starts if/when kernel images are overwritten by successive Linux OS distros. This is likely when derivatives of the same main distros e.g. Ubuntu all create a directory called /EFI/ubuntu/ in the ESP and drop their kernels & initrd images in there potentially overwriting other distro's files. > 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. The concept of one bootloader/manager ruling them all is broadly the same whether you use rEFInd or GRUB, as are the hoops you have to jump through to accommodate distros' automated/hardcoded installation scripts. When using a distro's installer menu on a legacy BIOS MoBo you can select a partition (PBR) to install GRUB, but GRUB will complain and suggest you could use blocklists but it is unreliable. Last time I received an error like this, I installed grub in a PBR manually with the '--force' option, without using the installer GUI. After that, whenever I updated GRUB it complained again about blocklists, but it worked fine. > 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. Try using '--force' to make GRUB install its image in some distro's boot/root partition PBR instead of the disk MBR, but you'll probably have to perform this outside the installer script. I've done this with VMs. > 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. These days I use disks with GPT even on MoBos with legacy BIOS. Instead of backing up and restoring the MBR/BIOS Boot Partition you could just reinstall grub and run grub-mkconfig, as long as the latter involves fewer key-presses. ;-) It goes without saying a backup before messing up with GRUB will save the day in case files are inadvertently overwritten.
signature.asc
Description: This is a digitally signed message part.
