Re: grub-lnstall option (UEFI) for chainloading

[Andrei Borzenkov]

В Fri, 05 Jun 2015 14:56:20 +0100
Barry Jackson <address@hidden> пишет:

> On 30/03/15 10:58, Andrei Borzenkov wrote:
> > On Mon, Mar 30, 2015 at 12:32 PM, Vladimir 'φ-coder/phcoder'
> > Serbinenko <address@hidden> wrote:
> >> On 29.03.2015 15:12, Andrei Borzenkov wrote:
> >>>
> >>> В Sun, 29 Mar 2015 13:11:04 +0100
> >>> Barry Jackson <address@hidden> пишет:
> >>>
> >>>> 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
> > address@hidden
> > 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?