Grub2, can the following be done

Grub2, can the following be done

[Leslie Satenstein]

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

Re: Grub2, can the following be done

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

I documented this in the manual. See "standalone multi-OS setup"

On Wed, Apr 12, 2017, 09:27 Leslie Satenstein <leslie.satenstein@gmail.com>
wrote:

> 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
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2614 bytes --]

Re: Grub2, can the following be done

[Andrei Borzenkov]

12.04.2017 02:28, Vladimir 'phcoder' Serbinenko пишет:
> I documented this in the manual. See "standalone multi-OS setup"
> 

There is no such section. You probably mean Configuration - Multi-boot
manual config.

Unfortunately this is not as simple.

1. Sourcing full configuration file from another distribution is not
safe. It may refer to components (modules, fonts, themes, ...) not
present in "parent" grub. We do not change $prefix when executing
different config. And even if we did we cannot obviously load modules
from completely different build.

2. The most generic is to load another GRUB, but for now there is no
cross-platform method to do it. Chainloader, multiboot, efi - pick your
choice. We probably need platform independent "grub" loader that
resolves to whatever method is valid for current platform.

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.

For EFI the problem starts already with the fact that we are using
distribution name as \EFI subdirectory, so it is impossible to install
several instances of the same distribution side by side. Some (like
SUSE) expose GRUB_DISTRIBUTOR in system configuration tools, but as it
is also used to build menu, we get something like

openSUSE_1 with linux ...

which is not ideal either. We probably need to have separate
configuration option for subdirectory that can be then set to something
like \EFI\<distro>\<UUID> where UUID is machine UUID or even simply root
filesystem.

Of course existence of secure boot and shim do not make auto-detection
easier.


> On Wed, Apr 12, 2017, 09:27 Leslie Satenstein <leslie.satenstein@gmail.com>
> wrote:
> 
>> 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
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 

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.

Re: Grub2, can the following be done

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3494 bytes --]

On Wed, Apr 12, 2017, 13:26 Andrei Borzenkov <arvidjaar@gmail.com> wrote:

12.04.2017 02:28, Vladimir 'phcoder' Serbinenko пишет:
> I documented this in the manual. See "standalone multi-OS setup"
>

There is no such section. You probably mean Configuration - Multi-boot
manual config.

Unfortunately this is not as simple.

1. Sourcing full configuration file from another distribution is not
safe. It may refer to components (modules, fonts, themes, ...) not
present in "parent" grub. We do not change $prefix when executing
different config. And even if we did we cannot obviously load modules
from completely different build.

I'm working on proposal for a new config language to be used in addition to
current format to solve all of those problems.


2. The most generic is to load another GRUB, but for now there is no
cross-platform method to do it. Chainloader, multiboot, efi - pick your
choice. We probably need platform independent "grub" loader that
resolves to whatever method is valid for current platform.

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.

For EFI the problem starts already with the fact that we are using
distribution name as \EFI subdirectory, so it is impossible to install
several instances of the same distribution side by side. Some (like
SUSE) expose GRUB_DISTRIBUTOR in system configuration tools, but as it
is also used to build menu, we get something like

openSUSE_1 with linux ...

which is not ideal either. We probably need to have separate
configuration option for subdirectory that can be then set to something
like \EFI\<distro>\<UUID> where UUID is machine UUID or even simply root
filesystem.

Of course existence of secure boot and shim do not make auto-detection
easier.


> On Wed, Apr 12, 2017, 09:27 Leslie Satenstein <leslie.satenstein@gmail.com
>
> wrote:
>
>> 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
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Type: text/html, Size: 7128 bytes --]

Re: Grub2, can the following be done

[Xen]

Xen schreef op 12-04-2017 9:47:
> 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.

Pardon the confusion, I thought I was responding to Leslie.

If you can't autodetect other systems at config-generation very well 
then it seems simple:

- let each system autodetect itself, put a file representing that on 
disk, let the other installations know about this config file location, 
let them source it in while generating their own config.

If you want a more live updated system you will still need one master 
config that gets updated by all systems as Leslie proposes but this 
could imply a directory with "self" snippets.

Re: Grub2, can the following be done

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]

On Wed, Apr 12, 2017, 18:07 Xen <list@xenhideout.nl> wrote:

> Xen schreef op 12-04-2017 9:47:
> > 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.
>
> Pardon the confusion, I thought I was responding to Leslie.
>
> If you can't autodetect other systems at config-generation very well
> then it seems simple:
>
> - let each system autodetect itself, put a file representing that on
> disk, let the other installations know about this config file location,
> let them source it in while generating their own config.
>
> If you want a more live updated system you will still need one master
> config that gets updated by all systems as Leslie proposes but this
> could imply a directory with "self" snippets.
>
The new config incorporates those ideas. I'll share the proposal when it's
in a better shape.

>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2336 bytes --]

Re: Grub2, can the following be done

[Xen]

Vladimir 'phcoder' Serbinenko schreef op 12-04-2017 10:26:

> The new config incorporates those ideas. I'll share the proposal when
> it's in a better shape.

Alright thanks, sounds cool :).