[Top][All Lists]

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

Re: grub-lnstall option (UEFI) for chainloading

From: Andrei Borzenkov
Subject: Re: grub-lnstall option (UEFI) for chainloading
Date: Mon, 30 Mar 2015 12:58:08 +0300

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.

reply via email to

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