From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Z19cn-0002MO-1w for mharc-grub-devel@gnu.org; Sat, 06 Jun 2015 04:38:41 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z19ck-0002M2-4B for grub-devel@gnu.org; Sat, 06 Jun 2015 04:38:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z19cf-0005WU-9a for grub-devel@gnu.org; Sat, 06 Jun 2015 04:38:38 -0400 Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:36038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z19cf-0005WB-1f for grub-devel@gnu.org; Sat, 06 Jun 2015 04:38:33 -0400 Received: by lbbqq2 with SMTP id qq2so57616468lbb.3 for ; Sat, 06 Jun 2015 01:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=We/zoahD7xKhOu/1Eg9nmQV/f33HdvNuKIBuVIBquYY=; b=kSLNowA7zll3qcHFFCdkjuN0pDRSZrfwJWy8msPqxnTTeBpM/8o4B9aELAt9LRXXAD UqEh3iaEDmhOJPlxZEQBHFF1SJ/DiFDUGwdMixyxa4JFuk5r/Zh7GnkyVppJK7ZQT6Lg bcctQ6M3tytOP2dFWfE0/xGmAUypHnff/DmX1Iuz9qdyL2DVzl8tLWrbRNXRSNyeSftY vZPKjcxT1nc+5q6Zd8NiA/ODXoYjC2F1UxQkt5z/LnK9UrHt+emnWeZ1VWgNU+dHQ6MN gOp5rBuYQJibvpcjblvyCAVNWndqiAxfLlC3F7mjA2orGeEtMb9AlXzucDBouRxOrTWo 1CNQ== X-Received: by 10.152.1.40 with SMTP id 8mr1499905laj.56.1433579912313; Sat, 06 Jun 2015 01:38:32 -0700 (PDT) Received: from opensuse.site (ppp91-76-14-38.pppoe.mtu-net.ru. [91.76.14.38]) by mx.google.com with ESMTPSA id s8sm2381276las.29.2015.06.06.01.38.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jun 2015 01:38:31 -0700 (PDT) Date: Sat, 6 Jun 2015 11:38:31 +0300 From: Andrei Borzenkov To: Barry Jackson Subject: Re: grub-lnstall option (UEFI) for chainloading Message-ID: <20150606113831.44c54ebd@opensuse.site> In-Reply-To: <5571AA84.9060105@zen.co.uk> References: <5517EBD8.8070901@zen.co.uk> <20150329161224.5192abb7@opensuse.site> <5519183F.2040509@gmail.com> <5571AA84.9060105@zen.co.uk> X-Mailer: Claws Mail 3.11.0 (GTK+ 2.24.27; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22a Cc: grub-devel@gnu.org 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: Sat, 06 Jun 2015 08:38:39 -0000 =D0=92 Fri, 05 Jun 2015 14:56:20 +0100 Barry Jackson =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > 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 > > >=20 > Any progress on this? >=20 Not really, sorry. Do you have any suggestion how such option should be named?=20