From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XlAFW-00069B-FT for mharc-grub-devel@gnu.org; Mon, 03 Nov 2014 00:32:18 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlAFQ-00068e-Cp for grub-devel@gnu.org; Mon, 03 Nov 2014 00:32:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlAFI-0004Cr-IU for grub-devel@gnu.org; Mon, 03 Nov 2014 00:32:12 -0500 Received: from mail-la0-x236.google.com ([2a00:1450:4010:c03::236]:50804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlAFI-0004Cj-8h for grub-devel@gnu.org; Mon, 03 Nov 2014 00:32:04 -0500 Received: by mail-la0-f54.google.com with SMTP id s18so3466480lam.41 for ; Sun, 02 Nov 2014 21:32:02 -0800 (PST) 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=MWkgW6ilUmntmvyhYu3Myupe8RJ+wuRKEvs9fufpRrw=; b=rrAThIDJHHHTvM+lEcnDGF2FSqDCFLa3lv0A7sG9DIvjpd/C1jsNlB1L63TKtAGM3G ot7RKrA7K0c/SbVQyCT0WAAkExeVScsC2Va51QuHAQCAzPwkC+BBsR2M8BT1xq5foCTB cnTDaJ3cZ2msTsJdeDmikg1urDxJsGjeqoELqc1y64F/Fa6PkrLtjLQFofG/4FUoVshY Sm8JEPKlk8N3zkKMQMOSHWy3gihVkUnusqHzJG7c1BWZ4bBb6BKxa6+jB+dCNZ5cIWE6 VKjuWaK3nq5JVYPktqIxDUY71S2JYOtD5rYlq5igdRuDCgk1EhWtMiR2991cfV7BoYpb RQhg== X-Received: by 10.152.1.130 with SMTP id 2mr48061726lam.89.1414992722104; Sun, 02 Nov 2014 21:32:02 -0800 (PST) Received: from opensuse.site (ppp91-76-139-38.pppoe.mtu-net.ru. [91.76.139.38]) by mx.google.com with ESMTPSA id i6sm7507466laf.47.2014.11.02.21.32.00 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Nov 2014 21:32:01 -0800 (PST) Date: Mon, 3 Nov 2014 08:31:58 +0300 From: Andrei Borzenkov To: Chris Murphy Subject: Re: workaround install boot on btrfs with windows partition scheme Message-ID: <20141103083158.6cff503b@opensuse.site> In-Reply-To: References: <20141030083243.GA7083@linux-dsax.tai.apac.novell.com> <20141102082707.68748fa5@opensuse.site> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; 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:c03::236 Cc: The development of GNU GRUB 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, 03 Nov 2014 05:32:17 -0000 =D0=92 Sun, 2 Nov 2014 15:11:29 -0700 Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > On Nov 1, 2014, at 11:27 PM, Andrei Borzenkov wrote: >=20 > > =D0=92 Sat, 1 Nov 2014 14:35:57 -0600 > > Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>=20 > >> Why not have a dedicated partition with MBR type code for core.img, eq= uivalent to BIOSBoot currently used on GPT? freedesktop.org has a proposal = to use type code 0xEA for this purpose (in part). The boot.img code in the = MBR can arbitrarily jump to any LBA, so 0xEA doesn't need to be a primary p= artition does it? > >>=20 > >=20 > > It is rarely needed in simple cases; in complicated cases (btrfs or > > LVM) we already have space dedicated for core.img. It seems more > > logical to use this space. >=20 > Well actually it isn't rare in simple cases. The most common case on Linu= x is booting from ext which grub won't embed to either without --force.xz_d= ec_lzma2 We are discussing installation in MBR here, not in partition.=20 > So we have to have core.img embedded somewhere else. UEFI it's a fixed location. BIOS+GPT it's a fixed location. Only on MBR is it in an unreserved location or forcibly embedded - that's really where the problem is. It seems a lot simpler to constrain the MBR options down to only a reserved partition just like elsewhere where it's now much simpler because it can only properly go in one location. >=20 >=20 > > Also you still need to tell grub-setup to use this special partition at > > which point why not extend it to support arbitrary location for > > core.img? It could be made check partition type and not refuse to > > install on raw partition for special 0xEA type then as a bonus. >=20 > I never tell grub-setup to use BIOSboot partition type. It always just fi= nds it automatically. >=20 I do not really trust anyone respect partition types on MBR to be honest. So I would rather avoid blindly overwriting anything without explicit user's consent.