On Sun 13 Feb 2022 at 19:26:51 (+0100), Andrei POPESCU wrote: > On Du, 13 feb 22, 11:01:48, David Wright wrote: > > > > Typically, one would have a primary, "master" linux system which would > > be used to write an MBR pointing to itself. The other, legacy system > > would have its grub.cfg kept up-to-date, but would never touch the > > MBR by running grub-install. > > Another option (at least with MBR, didn't try this with GPT) is to tell > the Installer to install GRUB in the partition instead of the MBR, and > then manually install another GRUB instance to the MBR with a > handcrafted config that is chain-loading the GRUBs in the partitions. > > This way each system's GRUB config is nicely following kernel upgrades > automatically.
There are implications in doing that. If you install Grub on a logical partition, then some sources suggest that you get the space for its core.img after the Extended Boot Record (EBR), but I don't see any firm evidence for that, particularly if the partitioning was done by non-Windows partitioners, and compounded by non-CHS disks. I can't examine a real example as I haven't created a logical partition since the last millennium. As for primary partitions after the first, there's no BR for there to be a gap after. So the core.img for Grub has to be placed in the filesystem itself, yet it's addressed by block addresses, which are not known to nor respected by normal filesystem utilities, and which therefore means they can get moved. As for GPT disks, where you have to use a BIOS Boot partition for Grub's core.img, there's no way to manage that space other than to juggle multiple such partitions so that each Grub instance is forced to use a different BIOS Boot partition instance. Cheers, David.