grub-lnstall option (UEFI) for chainloading

grub-lnstall option (UEFI) for chainloading

[Barry Jackson]

Hello,
Currently when installing grub2 on UEFI, the running system's grub2 
writes an entry to the ESP making it the controlling grub.

Can an option to grub2-install be added that installs only to 
/boot/grub2 and creates core.efi, but does *not* write into the ESP?

This would provide similar functionality to the --no-bootsector option 
used in PC-BIOS systems for using a Master grub partition that 
chainloads into multiple operating systems.

Re: grub-lnstall option (UEFI) for chainloading

[Andrei Borzenkov]

В Sun, 29 Mar 2015 13:11:04 +0100
Barry Jackson <zen25000@zen.co.uk> пишет:

> Hello,
> Currently when installing grub2 on UEFI, the running system's grub2 
> writes an entry to the ESP making it the controlling grub.
> 
> Can an option to grub2-install be added that installs only to 
> /boot/grub2 and creates core.efi, but does *not* write into the ESP?
> 
> This would provide similar functionality to the --no-bootsector option 
> used in PC-BIOS systems for using a Master grub partition that 
> chainloads into multiple operating systems.

Yes, for a long time I cherish idea of "only update /boot/grub and
create core.img" option. May be something like generic

--no-platform-setup

that will simply exit after image is created. --no-nvram is too
specific name to roll this into it. We can then deprecate
--no-bootsector and --no-nvram (actually as --no-bootsector is new just
drop it).

Vladimir, will you agree to a patch?

Re: grub-lnstall option (UEFI) for chainloading

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 29.03.2015 15:12, Andrei Borzenkov wrote:
> В Sun, 29 Mar 2015 13:11:04 +0100
> Barry Jackson <zen25000@zen.co.uk> пишет:
>
>> Hello,
>> Currently when installing grub2 on UEFI, the running system's grub2
>> writes an entry to the ESP making it the controlling grub.
>>
>> Can an option to grub2-install be added that installs only to
>> /boot/grub2 and creates core.efi, but does *not* write into the ESP?
>>
>> This would provide similar functionality to the --no-bootsector option
>> used in PC-BIOS systems for using a Master grub partition that
>> chainloads into multiple operating systems.
>
> Yes, for a long time I cherish idea of "only update /boot/grub and
> create core.img" option. May be something like generic
>
> --no-platform-setup
>
> that will simply exit after image is created. --no-nvram is too
> specific name to roll this into it. We can then deprecate
> --no-bootsector and --no-nvram (actually as --no-bootsector is new just
> drop it).
>
GRUB already has --no-nvram for EFI.
--no-nvram has different meaning than what you describe. --no-nvram 
still copies all the files to their target destinations, in EFI case to 
ESP, just doesn't register them in NVRAM. It's useful if you want to fix 
GRUB setup on another computer by plugging its disk in USB enclosure.
I'm unclear about which semantics you want. Should --no-platform-setup 
still put boot.img to $prefix/i386-pc ? Probably yes, but it's already 
part of platform-dependent install. Should we split the switch 
(platform) in grub-install to 2 switches then ?
> Vladimir, will you agree to a patch?
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: grub-lnstall option (UEFI) for chainloading

[Andrei Borzenkov]

On Mon, Mar 30, 2015 at 12:32 PM, Vladimir 'φ-coder/phcoder'
Serbinenko <phcoder@gmail.com> wrote:
> On 29.03.2015 15:12, Andrei Borzenkov wrote:
>>
>> В Sun, 29 Mar 2015 13:11:04 +0100
>> Barry Jackson <zen25000@zen.co.uk> пишет:
>>
>>> Hello,
>>> Currently when installing grub2 on UEFI, the running system's grub2
>>> writes an entry to the ESP making it the controlling grub.
>>>
>>> Can an option to grub2-install be added that installs only to
>>> /boot/grub2 and creates core.efi, but does *not* write into the ESP?
>>>
>>> This would provide similar functionality to the --no-bootsector option
>>> used in PC-BIOS systems for using a Master grub partition that
>>> chainloads into multiple operating systems.
>>
>>
>> Yes, for a long time I cherish idea of "only update /boot/grub and
>> create core.img" option. May be something like generic
>>
>> --no-platform-setup
>>
>> that will simply exit after image is created. --no-nvram is too
>> specific name to roll this into it. We can then deprecate
>> --no-bootsector and --no-nvram (actually as --no-bootsector is new just
>> drop it).
>>
> GRUB already has --no-nvram for EFI.
> --no-nvram has different meaning than what you describe. --no-nvram still
> copies all the files to their target destinations, in EFI case to ESP, just
> doesn't register them in NVRAM. It's useful if you want to fix GRUB setup on
> another computer by plugging its disk in USB enclosure.
> I'm unclear about which semantics you want. Should --no-platform-setup still
> put boot.img to $prefix/i386-pc ?

Yes. It should copy modules to /boot/grub, run usual $prefix
detection, create core.img (whatever name for the current platform it
has) but stop here. In particular, it should not copy it into ESP on
EFI :)

>                                                Probably yes, but it's already part of
> platform-dependent install.

I do not insist on this name. I just cannot think about better alternative.

>                                         Should we split the switch (platform) in
> grub-install to 2 switches then ?

Not sure I understand it, sorry.

There main use case is master bootloader that chainloads (in broad
sense) bootloader for each installed system. In this case we do NOT
want core.img to be copied anywhere, because master bootloader will
load it. We DO want it to be fully functional core.img though,
including working reference to $prefix.

Re: grub-lnstall option (UEFI) for chainloading

[Barry Jackson]

On 30/03/15 10:58, Andrei Borzenkov wrote:
> On Mon, Mar 30, 2015 at 12:32 PM, Vladimir 'φ-coder/phcoder'
> Serbinenko <phcoder@gmail.com> wrote:
>> On 29.03.2015 15:12, Andrei Borzenkov wrote:
>>>
>>> В Sun, 29 Mar 2015 13:11:04 +0100
>>> Barry Jackson <zen25000@zen.co.uk> пишет:
>>>
>>>> Hello,
>>>> Currently when installing grub2 on UEFI, the running system's grub2
>>>> writes an entry to the ESP making it the controlling grub.
>>>>
>>>> Can an option to grub2-install be added that installs only to
>>>> /boot/grub2 and creates core.efi, but does *not* write into the ESP?
>>>>
>>>> This would provide similar functionality to the --no-bootsector option
>>>> used in PC-BIOS systems for using a Master grub partition that
>>>> chainloads into multiple operating systems.
>>>
>>>
>>> Yes, for a long time I cherish idea of "only update /boot/grub and
>>> create core.img" option. May be something like generic
>>>
>>> --no-platform-setup
>>>
>>> that will simply exit after image is created. --no-nvram is too
>>> specific name to roll this into it. We can then deprecate
>>> --no-bootsector and --no-nvram (actually as --no-bootsector is new just
>>> drop it).
>>>
>> GRUB already has --no-nvram for EFI.
>> --no-nvram has different meaning than what you describe. --no-nvram still
>> copies all the files to their target destinations, in EFI case to ESP, just
>> doesn't register them in NVRAM. It's useful if you want to fix GRUB setup on
>> another computer by plugging its disk in USB enclosure.
>> I'm unclear about which semantics you want. Should --no-platform-setup still
>> put boot.img to $prefix/i386-pc ?
>
> Yes. It should copy modules to /boot/grub, run usual $prefix
> detection, create core.img (whatever name for the current platform it
> has) but stop here. In particular, it should not copy it into ESP on
> EFI :)
>
>>                                                 Probably yes, but it's already part of
>> platform-dependent install.
>
> I do not insist on this name. I just cannot think about better alternative.
>
>>                                          Should we split the switch (platform) in
>> grub-install to 2 switches then ?
>
> Not sure I understand it, sorry.
>
> There main use case is master bootloader that chainloads (in broad
> sense) bootloader for each installed system. In this case we do NOT
> want core.img to be copied anywhere, because master bootloader will
> load it. We DO want it to be fully functional core.img though,
> including working reference to $prefix.
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

Any progress on this?

Re: grub-lnstall option (UEFI) for chainloading

[Andrei Borzenkov]

В Fri, 05 Jun 2015 14:56:20 +0100
Barry Jackson <zen25000@zen.co.uk> пишет:

> On 30/03/15 10:58, Andrei Borzenkov wrote:
> > On Mon, Mar 30, 2015 at 12:32 PM, Vladimir 'φ-coder/phcoder'
> > Serbinenko <phcoder@gmail.com> wrote:
> >> On 29.03.2015 15:12, Andrei Borzenkov wrote:
> >>>
> >>> В Sun, 29 Mar 2015 13:11:04 +0100
> >>> Barry Jackson <zen25000@zen.co.uk> пишет:
> >>>
> >>>> Hello,
> >>>> Currently when installing grub2 on UEFI, the running system's grub2
> >>>> writes an entry to the ESP making it the controlling grub.
> >>>>
> >>>> Can an option to grub2-install be added that installs only to
> >>>> /boot/grub2 and creates core.efi, but does *not* write into the ESP?
> >>>>
> >>>> This would provide similar functionality to the --no-bootsector option
> >>>> used in PC-BIOS systems for using a Master grub partition that
> >>>> chainloads into multiple operating systems.
> >>>
> >>>
> >>> Yes, for a long time I cherish idea of "only update /boot/grub and
> >>> create core.img" option. May be something like generic
> >>>
> >>> --no-platform-setup
> >>>
> >>> that will simply exit after image is created. --no-nvram is too
> >>> specific name to roll this into it. We can then deprecate
> >>> --no-bootsector and --no-nvram (actually as --no-bootsector is new just
> >>> drop it).
> >>>
> >> GRUB already has --no-nvram for EFI.
> >> --no-nvram has different meaning than what you describe. --no-nvram still
> >> copies all the files to their target destinations, in EFI case to ESP, just
> >> doesn't register them in NVRAM. It's useful if you want to fix GRUB setup on
> >> another computer by plugging its disk in USB enclosure.
> >> I'm unclear about which semantics you want. Should --no-platform-setup still
> >> put boot.img to $prefix/i386-pc ?
> >
> > Yes. It should copy modules to /boot/grub, run usual $prefix
> > detection, create core.img (whatever name for the current platform it
> > has) but stop here. In particular, it should not copy it into ESP on
> > EFI :)
> >
> >>                                                 Probably yes, but it's already part of
> >> platform-dependent install.
> >
> > I do not insist on this name. I just cannot think about better alternative.
> >
> >>                                          Should we split the switch (platform) in
> >> grub-install to 2 switches then ?
> >
> > Not sure I understand it, sorry.
> >
> > There main use case is master bootloader that chainloads (in broad
> > sense) bootloader for each installed system. In this case we do NOT
> > want core.img to be copied anywhere, because master bootloader will
> > load it. We DO want it to be fully functional core.img though,
> > including working reference to $prefix.
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> 
> Any progress on this?
> 


Not really, sorry. Do you have any suggestion how such option should be
named? 

Re: grub-lnstall option (UEFI) for chainloading

[Barry Jackson]

On 06/06/15 09:38, Andrei Borzenkov wrote:
> В Fri, 05 Jun 2015 14:56:20 +0100
> Barry Jackson <zen25000@zen.co.uk> пишет:

>> Any progress on this?
>>
>
>
> Not really, sorry. Do you have any suggestion how such option should be
> named?
>

Sorry for delay - this got lost in the noise.

Well something like --no-id-or-nvram ??

Not really bothered about the name! :)

Re: grub-lnstall option (UEFI) for chainloading

[Andrei Borzenkov]

On Tue, Sep 8, 2015 at 12:39 AM, Barry Jackson <zen25000@zen.co.uk> wrote:
> On 06/06/15 09:38, Andrei Borzenkov wrote:
>>
>> В Fri, 05 Jun 2015 14:56:20 +0100
>> Barry Jackson <zen25000@zen.co.uk> пишет:
>
>
>>> Any progress on this?
>>>
>>
>>
>> Not really, sorry. Do you have any suggestion how such option should be
>> named?
>>
>
> Sorry for delay - this got lost in the noise.
>
> Well something like --no-id-or-nvram ??
>
> Not really bothered about the name! :)

I was about to suggest a patch when I realized that this probably is
currently useless on EFI. I.e. to actually chainload grub on EFI it
must reside on a partition accessible by firmware which practically
means it should be ESP.

Unless someone submits patch to make grub2 EFI core.img multiboot2
compliant with tag to skip ExitBootServices.

Does chainloading from /boot/grub actually work for you on EFI? Could
you explain your configuration in more details?

Re: grub-lnstall option (UEFI) for chainloading

[Daniel Kiper]

On Mon, Oct 12, 2015 at 12:31:54PM +0300, Andrei Borzenkov wrote:
> On Tue, Sep 8, 2015 at 12:39 AM, Barry Jackson <zen25000@zen.co.uk> wrote:
> > On 06/06/15 09:38, Andrei Borzenkov wrote:
> >>
> >> ?? Fri, 05 Jun 2015 14:56:20 +0100
> >> Barry Jackson <zen25000@zen.co.uk> ??????????:
> >
> >
> >>> Any progress on this?
> >>>
> >>
> >>
> >> Not really, sorry. Do you have any suggestion how such option should be
> >> named?
> >>
> >
> > Sorry for delay - this got lost in the noise.
> >
> > Well something like --no-id-or-nvram ??
> >
> > Not really bothered about the name! :)
>
> I was about to suggest a patch when I realized that this probably is
> currently useless on EFI. I.e. to actually chainload grub on EFI it
> must reside on a partition accessible by firmware which practically
> means it should be ESP.
>
> Unless someone submits patch to make grub2 EFI core.img multiboot2
> compliant with tag to skip ExitBootServices.

Relevant patches waiting for review for months. I am working on v3.
If they are upstreamed I will be happy too.

Daniel

Re: grub-lnstall option (UEFI) for chainloading

[Andrei Borzenkov]

12.10.2015 19:39, Daniel Kiper пишет:
> On Mon, Oct 12, 2015 at 12:31:54PM +0300, Andrei Borzenkov wrote:
>> On Tue, Sep 8, 2015 at 12:39 AM, Barry Jackson <zen25000@zen.co.uk> wrote:
>>> On 06/06/15 09:38, Andrei Borzenkov wrote:
>>>>
>>>> ?? Fri, 05 Jun 2015 14:56:20 +0100
>>>> Barry Jackson <zen25000@zen.co.uk> ??????????:
>>>
>>>
>>>>> Any progress on this?
>>>>>
>>>>
>>>>
>>>> Not really, sorry. Do you have any suggestion how such option should be
>>>> named?
>>>>
>>>
>>> Sorry for delay - this got lost in the noise.
>>>
>>> Well something like --no-id-or-nvram ??
>>>
>>> Not really bothered about the name! :)
>>
>> I was about to suggest a patch when I realized that this probably is
>> currently useless on EFI. I.e. to actually chainload grub on EFI it
>> must reside on a partition accessible by firmware which practically
>> means it should be ESP.
>>
>> Unless someone submits patch to make grub2 EFI core.img multiboot2
>> compliant with tag to skip ExitBootServices.
>
> Relevant patches waiting for review for months. I am working on v3.
> If they are upstreamed I will be happy too.
>

Your patches implement "client side" support (loading MB2 images); but 
EFI grub is not MB2 and has no provision for being loaded this way. Also 
it is PE, not ELF.

Actually chainloading probably could be made to work on arbitrary 
filesystem if argument parsing is added (to pass along cmdpath).

Re: grub-lnstall option (UEFI) for chainloading

[Daniel Kiper]

On Mon, Oct 12, 2015 at 11:08:24PM +0300, Andrei Borzenkov wrote:
> 12.10.2015 19:39, Daniel Kiper пишет:
> >On Mon, Oct 12, 2015 at 12:31:54PM +0300, Andrei Borzenkov wrote:
> >>On Tue, Sep 8, 2015 at 12:39 AM, Barry Jackson <zen25000@zen.co.uk> wrote:
> >>>On 06/06/15 09:38, Andrei Borzenkov wrote:
> >>>>
> >>>>?? Fri, 05 Jun 2015 14:56:20 +0100
> >>>>Barry Jackson <zen25000@zen.co.uk> ??????????:
> >>>
> >>>
> >>>>>Any progress on this?
> >>>>>
> >>>>
> >>>>
> >>>>Not really, sorry. Do you have any suggestion how such option should be
> >>>>named?
> >>>>
> >>>
> >>>Sorry for delay - this got lost in the noise.
> >>>
> >>>Well something like --no-id-or-nvram ??
> >>>
> >>>Not really bothered about the name! :)
> >>
> >>I was about to suggest a patch when I realized that this probably is
> >>currently useless on EFI. I.e. to actually chainload grub on EFI it
> >>must reside on a partition accessible by firmware which practically
> >>means it should be ESP.
> >>
> >>Unless someone submits patch to make grub2 EFI core.img multiboot2
> >>compliant with tag to skip ExitBootServices.
> >
> >Relevant patches waiting for review for months. I am working on v3.
> >If they are upstreamed I will be happy too.
> >
>
> Your patches implement "client side" support (loading MB2 images);

OK but they provide what you need here. So, it does not fully invalidate
what I said earlier.

> but EFI grub is not MB2 and has no provision for being loaded this
> way. Also it is PE, not ELF.

MB2 header may live in PE, ELF or even in file which does not have commonly known format.

> Actually chainloading probably could be made to work on arbitrary
> filesystem if argument parsing is added (to pass along cmdpath).

So, it looks that MB2 with my extensions should make it work.

Daniel

Re: grub-lnstall option (UEFI) for chainloading

[Barry Jackson]

On 12/10/15 10:31, Andrei Borzenkov wrote:
> On Tue, Sep 8, 2015 at 12:39 AM, Barry Jackson <zen25000@zen.co.uk> wrote:
>> On 06/06/15 09:38, Andrei Borzenkov wrote:
>>>
>>> В Fri, 05 Jun 2015 14:56:20 +0100
>>> Barry Jackson <zen25000@zen.co.uk> пишет:
>>
>>
>>>> Any progress on this?
>>>>
>>>
>>>
>>> Not really, sorry. Do you have any suggestion how such option should be
>>> named?
>>>
>>
>> Sorry for delay - this got lost in the noise.
>>
>> Well something like --no-id-or-nvram ??
>>
>> Not really bothered about the name! :)
>
> I was about to suggest a patch when I realized that this probably is
> currently useless on EFI. I.e. to actually chainload grub on EFI it
> must reside on a partition accessible by firmware which practically
> means it should be ESP.
>
> Unless someone submits patch to make grub2 EFI core.img multiboot2
> compliant with tag to skip ExitBootServices.
>
> Does chainloading from /boot/grub actually work for you on EFI? Could
> you explain your configuration in more details?
>

Sorry for the long delay I missed your reply. We could really do with a 
patch for this as Mageia 6 is in freeze. ;)

Yes it works fine from a separate small grub2 partition.

The grub2 install to the small dedicated grub2 partition is installed by 
my script here: https://wiki.mageia.org/en/User_talk:Barjac

This is my current grub.cfg created by the script:

set default="0"
set timeout=10

if loadfont unicode ; then
   set gfxmode=1024x768x32
   insmod all_video
   insmod gfxterm
   set locale_dir=/locale
   set lang=en_GB
   insmod gettext
fi
terminal_output gfxterm
insmod part_gpt
insmod ext2

# Theme
insmod gfxmenu
loadfont /grub2/themes/maggy/MageiaLogo-Bold-16.pf2
loadfont /grub2/themes/maggy/MageiaLogo-Bold-20.pf2
loadfont /grub2/themes/maggy/MageiaLogo-Bold-28.pf2
loadfont /grub2/themes/maggy/MageiaLogo-Regular-20.pf2
insmod png
set theme=/grub2/themes/maggy/theme.txt
export theme

menuentry 'Mageia 6 on /dev/sda7' {
search --no-floppy --fs-uuid --set=root 
"a5ea7e67-7d24-4ecd-8271-fe662c87f258"
chainloader /boot/grub2/x86_64-efi/core.efi
}

menuentry 'Mageia 5  on /dev/sda4' {
search --no-floppy --fs-uuid --set=root 
"6e0e6790-c318-4bbe-b3cf-e925391b4d16"
chainloader /boot/grub2/x86_64-efi/core.efi
}

menuentry 'Mageia 6  on /dev/sda5' {
search --no-floppy --fs-uuid --set=root 
"18c8d8d4-dee6-4219-9dbf-a96d439ea76e"
chainloader /boot/grub2/x86_64-efi/core.efi
}