Re: Grub2, can the following be done

[Xen]

Andrei Borzenkov schreef op 12-04-2017 5:26:

> For PCBIOS having each distribution install its GRUB in own partition
> and chainloading it is well understood and established practice, but it
> makes it rather hard to auto-detect and incorporate such boot blocks.

You mean autodetecting Grub boot records in partitions is not the 
friendliest thing to do and you would much rather have a process of 
adjusting their actual boot menus or do you mean to generate these 
yourself?

There are two options:
- take existing menus and filter them
- regenerate new ones for the master installation

Did you want to keep chainloading from the master into the individual 
grubs, or do you plan to have separate master grubs that each can also 
give access to the other OSes?

Seeing you speak of 5 different systems I assume the goal is for them to 
be able to operate independently, ie. either EFI or BIOS can select them 
as primary boot device?

So you now want to source a master copy but do you not ideally want to 
source an authoritative boot line for that specific system?

But in sourcing you try to prevent the other 4 systems so to speak to be 
updated...

Ideally then each system has a "self" boot entry that needs to be there?

I mean it's very simple, if you can't autodetect, then you'll need a 
configuration file that does it for you.

So really what you need is a configuration snippet for each system that 
can be included but perhaps ideally not as a grub-mkconfig run but as a 
live thing...?

But that would mean sourcing from 5 different disks so to speak at each 
boot.

Would it not be possible to extract a system's main configuration entry 
(boot entry) and place it in a file in /boot, or /boot/grub,

then, convoluted as it may be, run an automatic chrooted update script 
on the 4 other systems? Each update script either runs grub-mkconfig 
without probing for other systems, or just runs it and source the 
configuration snippets from the other systems 'manually'. This way there 
won't "be" a master grub configuration as each system is responsible for 
sourcing its own boot entries. The boot entries you source from other 
systems only require a configuration as to where to find its /boot 
directory, in essence.

So either you prevent grub-mkconfig from auto-generating by detection, 
or your update script finds and replaces existing entries for the same 
devices. Typically "full generation" is a better solution as you only 
need one generator path, so it would seem the grub-mkconfig invocation 
would need to generate the "self" entry on disk as well as not 
auto-detect as well as be followed by inclusion of "self" snippets from 
the other systems.

This does require updating every system on every change but it means 
chrooting into every other system in turn and running an identical 
update script from each system.

But maybe you already have this lol.

You now want these self entries to be collected in one place and for 
Grub to source this as an inclusion file while recognising any duplicate 
and letting it be superseded by the self configuration already present 
prior to inclusion.

> > > Current-Setup
> > > =============
> > > SYSTEM-A Grub2 >-----+ Points to A,B,C,D,E
> > >                      +-->SYSTEM-B Grub2 Points to B,A,C,D,E
> > >                      +-->SYSTEM-C Grub2 Points to C,A,B,D,E
> > >                      +-->SYSTEM-D Grub2 Points to D,A,B,C,E
> > >                      +-->SYSTEM-E Grub2 Points to E,A,B,C,D
> > >
> > > Problem
> > > =======
> > > any update to A,B.C.D.E needs a recreation of grub.cfg for each (all)
> > > the others
> > >
> > >
> > > Is it possible to do the following?
> > >
> > > SYSTEM-A Grub2 >-----+A,[MASTER=Grub2]
> > >                      +-->SYSTEM-B Grub2 Points to B,[MASTER=Grub2]
> > >                      +-->SYSTEM-C Grub2 Points to C,[MASTER=Grub2]
> > >                      +-->SYSTEM-D Grub2 Points to D,[MASTER=Grub2]
> > >                      +-->SYSTEM-E Grub2 Points to E,[MASTER=Grub2]
> > >
> > > [Master-Grub2]
> > >      Copy of all Grub.cfgs, neatly organized?
> > >
> > > Any update of any system must also update MASTER-GRUB2

Personally I always feel "distributed" equal-importance solutions are 
better, in the sense of letting each system take care of itself.

If each system is going to update master-grub2 config you better ensure 
they all do the same thing.

Anyway, good luck.