On 2024-02-23, Michael <confabul...@kintzios.com> wrote: > 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.
Yes, that's the problem that I've read about when trying to multi-boot with UEFI. I usually have 3-4 different Ubuntu installations and 3-4 different RedHat installations. Ubuntu in particular causes a log of complaints about overwriting ESP files belonging to other Ubuntus. > When using a distro's installer menu on a legacy BIOS MoBo you can > select a partition (PBR) to install GRUB, You used to be able to. I can no longer find the option to do that in Ubuntu or RedHat. I've been told that Suse still allows it. > 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. Using --force will work fine as long as the grub 1.5 files don't get moved afterwards. That's why I lock them in place. Locking them will cause future upgrades to Grub for that distro to fail, but that doens't happen very often. When it does, you unlock them, updated grub, re-install using --force, and lock them again. >> 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. Yes, in my OP describing what I'm doing now it explains that's what I do. Then I lock the Grub files that are located using the blocklists created by the --force option. >> 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. Same here -- except for this one machine. I think I'll switch it over soon. > 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. ;-) I don't use grub-mkconfig for the "main" grub. It has a fixed grub.cfg file that does nothing but chainload the user-selected partition. Currently, backing up MBR+gap only happens once when I install/setup the main grub. Restoring BMR+gap is one command (which is actually in a shell script) that's run after any new distro is installed. MBR+Bios-boot-partition would work pretty much the same way. -- Grant
