From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YcW3v-0005Fw-RE for mharc-grub-devel@gnu.org; Mon, 30 Mar 2015 05:32:51 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcW3s-0005FH-Ci for grub-devel@gnu.org; Mon, 30 Mar 2015 05:32:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcW3o-0007LF-9z for grub-devel@gnu.org; Mon, 30 Mar 2015 05:32:48 -0400 Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:38618) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcW3o-0007Kw-31 for grub-devel@gnu.org; Mon, 30 Mar 2015 05:32:44 -0400 Received: by wibgn9 with SMTP id gn9so120251021wib.1 for ; Mon, 30 Mar 2015 02:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bYsvnQov0qG2F+hWFFgej6byq7Bf0psYY0L7c8mHpBs=; b=g9d2X6kXVWwnRIPHVK1O1G4xCkIMamqhWpwgkt48KtDaNprJFTdgqota/RwSpERZvP 20p3GMt7YuU28A543vOTm2rCtvsqZS7U9Ne3QTohA7pRnE+KRuFTR/q773ANkYxr3jKe 51p7vIK/ct25lpGl0s2u896P8JFKBBWuDi8dYlGBEPCTTaLXv9DsjY5JkMdFivmEXjlH QeQr+BeEu5ekOrOw1Ld/JTgys0y+Ys33zOhuXDIiKfnZmSJCL31QQ7Q8Tnvs0Ei0Q8nE cE2S7Ujg2MIdmfL50nzNtu39Tbx3bx9gYlEoBRBLqPUbCJ5WGFp/Yv3/ZuL5eFSRuOEG 63oQ== X-Received: by 10.194.20.67 with SMTP id l3mr60531821wje.94.1427707958435; Mon, 30 Mar 2015 02:32:38 -0700 (PDT) Received: from ?IPv6:2620:0:105f:fd00:863a:4bff:fe50:abc4? ([2620:0:105f:fd00:863a:4bff:fe50:abc4]) by mx.google.com with ESMTPSA id dx11sm14892142wjb.23.2015.03.30.02.32.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 02:32:37 -0700 (PDT) Message-ID: <5519183F.2040509@gmail.com> Date: Mon, 30 Mar 2015 11:32:47 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: grub-lnstall option (UEFI) for chainloading References: <5517EBD8.8070901@zen.co.uk> <20150329161224.5192abb7@opensuse.site> In-Reply-To: <20150329161224.5192abb7@opensuse.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22e 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: Mon, 30 Mar 2015 09:32:50 -0000 On 29.03.2015 15:12, Andrei Borzenkov wrote: > В Sun, 29 Mar 2015 13:11:04 +0100 > Barry Jackson пишет: > >> 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 ? Probably yes, but it's already part of platform-dependent install. Should we split the switch (platform) in grub-install to 2 switches then ? > Vladimir, will you agree to a patch? > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >