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?
next prev parent 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).