grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Barry Jackson <zen25000@zen.co.uk>
Cc: grub-devel@gnu.org
Subject: Re: grub-lnstall option (UEFI) for chainloading
Date: Sat, 6 Jun 2015 11:38:31 +0300	[thread overview]
Message-ID: <20150606113831.44c54ebd@opensuse.site> (raw)
In-Reply-To: <5571AA84.9060105@zen.co.uk>

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


  reply	other threads:[~2015-06-06  8:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-29 12:11 grub-lnstall option (UEFI) for chainloading Barry Jackson
2015-03-29 13:12 ` Andrei Borzenkov
2015-03-30  9:32   ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-03-30  9:58     ` Andrei Borzenkov
2015-06-05 13:56       ` Barry Jackson
2015-06-06  8:38         ` Andrei Borzenkov [this message]
2015-09-07 21:39           ` Barry Jackson
2015-10-12  9:31             ` Andrei Borzenkov
2015-10-12 16:39               ` Daniel Kiper
2015-10-12 20:08                 ` Andrei Borzenkov
2015-10-12 20:59                   ` Daniel Kiper
2016-06-06 11:20               ` Barry Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150606113831.44c54ebd@opensuse.site \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    --cc=zen25000@zen.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).