Re: grub-lnstall option (UEFI) for chainloading

[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?