From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Z0sdE-0005uY-FO for mharc-grub-devel@gnu.org; Fri, 05 Jun 2015 10:30:00 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0sdB-0005tf-NY for grub-devel@gnu.org; Fri, 05 Jun 2015 10:29:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0sd6-0005fj-Jq for grub-devel@gnu.org; Fri, 05 Jun 2015 10:29:57 -0400 Received: from rgout0504.bt.lon5.cpcloud.co.uk ([65.20.0.225]:20729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0sd6-0005fR-CN for grub-devel@gnu.org; Fri, 05 Jun 2015 10:29:52 -0400 Received: from [192.168.1.65] (86.184.234.113) by rgout05.bt.lon5.cpcloud.co.uk (8.6.122.06) (authenticated as ashton.models@btinternet.com) id 55702DEA0044974D for grub-devel@gnu.org; Fri, 5 Jun 2015 14:56:12 +0100 Message-ID: <5571AA84.9060105@zen.co.uk> Date: Fri, 05 Jun 2015 14:56:20 +0100 From: Barry Jackson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: grub-lnstall option (UEFI) for chainloading References: <5517EBD8.8070901@zen.co.uk> <20150329161224.5192abb7@opensuse.site> <5519183F.2040509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: Quoted-Printable X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 65.20.0.225 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 14:29:59 -0000 On 30/03/15 10:58, Andrei Borzenkov wrote: > On Mon, Mar 30, 2015 at 12:32 PM, Vladimir '=CF=86-coder/phcoder' > Serbinenko wrote: >> On 29.03.2015 15:12, Andrei Borzenkov wrote: >>> >>> =D0=92 Sun, 29 Mar 2015 13:11:04 +0100 >>> Barry Jackson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> >>>> 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 opti= on >>>> 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 ju= st >>> drop it). >>> >> GRUB already has --no-nvram for EFI. >> --no-nvram has different meaning than what you describe. --no-nvram st= ill >> 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 se= tup 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 alternat= ive. > >> Should we split the switch (p= latform) 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?