grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub-lnstall option (UEFI) for chainloading


From: Barry Jackson
Subject: Re: grub-lnstall option (UEFI) for chainloading
Date: Fri, 05 Jun 2015 14:56:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]