Re: dual booting, was Re: Stupid question
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.
Reply to: