From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XlOGM-0002NL-R9 for mharc-grub-devel@gnu.org; Mon, 03 Nov 2014 15:30:06 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlOGH-0002Kg-2a for grub-devel@gnu.org; Mon, 03 Nov 2014 15:30:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlOGC-0002Uh-C2 for grub-devel@gnu.org; Mon, 03 Nov 2014 15:30:01 -0500 Received: from mail-lb0-x236.google.com ([2a00:1450:4010:c04::236]:60833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlOGC-0002Ua-1i for grub-devel@gnu.org; Mon, 03 Nov 2014 15:29:56 -0500 Received: by mail-lb0-f182.google.com with SMTP id f15so10841498lbj.41 for ; Mon, 03 Nov 2014 12:29:54 -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=ZlaOvQGyCjr8rTCMyH0v6n4B16SmcR7Qd73kQbc+ebI=; b=gwZYRtu8MJjGvaI2XOUQ+vnYjrBsdngJe7y+TCG6eyKnBg0isR8ZvamZ5kY7WLlb89 koPd1rQvpvbV3A9RnxrHcB9aWLegOwq3MDVPMK7iFjSayaz7okJWctNT6tUqsPFOKiZH 1N5SJW9NlOCaFSBAPNys6k162lyo0rRqUcD4CfUhu8CyP5lgZImo0lR/PB5j0vmgiNwI qnOG68JMy6j+Ol81J+vsMyxsFHZLzuv3au8LiambIokwncrGev3n/d5bcWTf48J/WNY6 UgBCC1jJ05Bf+eAnbS4jm7XMl072q+qGSGfanoUSxrE+JZaotzDTsJZAWuDytWzr0pQ5 HFqw== X-Received: by 10.112.130.41 with SMTP id ob9mr52834169lbb.74.1415046594327; Mon, 03 Nov 2014 12:29:54 -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 k7sm8354132lak.22.2014.11.03.12.29.53 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 12:29:53 -0800 (PST) Date: Mon, 3 Nov 2014 23:29:51 +0300 From: Andrei Borzenkov To: Chris Murphy Subject: Re: workaround install boot on btrfs with windows partition scheme Message-ID: <20141103232951.0cd1b111@opensuse.site> In-Reply-To: <1D5B0DD1-84FC-40CF-AC86-24157DB502BF@colorremedies.com> References: <20141030083243.GA7083@linux-dsax.tai.apac.novell.com> <128E41CD-F94A-4CAF-A90E-C6F007AFE28A@colorremedies.com> <20141102083701.56e93821@opensuse.site> <20141103083637.09a9ec80@opensuse.site> <1D5B0DD1-84FC-40CF-AC86-24157DB502BF@colorremedies.com> 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:c04::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 20:30:05 -0000 =D0=92 Mon, 3 Nov 2014 12:36:24 -0700 Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov wrote: >=20 > > =D0=92 Sun, 2 Nov 2014 15:19:43 -0700 > > Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >=20 > >>=20 > >> On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov wr= ote: > >>>=20 > >>> So far nobody suggested solution for grubenv on unwritable location. > >>> Not to mention implementation =E2=80=A6 > >>=20 > >> Put grubenv on 0xEA/BIOSboot as well.=20 > >=20 > > Please provide scheme how grub can reliably identify which of multiple > > grub partitions on multiple disks is *the* partition where grubenv is > > located.=20 >=20 > Why would the policy be any different than it is now? This isn't a new pr= oblem, we already have multiple MBR gaps and hence multiple core.img instan= ces. Exactly. We have multiple core.img but single location for grub state and configuration information. It does not matter which core.img is loaded as long as they all refer to the same /boot/grub. How can multiple core.img refer to the same 0xEA partition to be sure they read (and write!) the same grubenv? > There is no real change other than explicitly defining a suitably sized partition for GRUB's things to go in, rather than depending on an unreliable location, i.e. the MBR gap which often is either too small or could just as likely be used by something else since it's not reserved space for anyone. >=20 > >=20 > > And it still should work when embedding bootloader in partition. Both > > with and without blocklists. >=20 > I'm not asking for any one else's workflow to become broken. I'm saying t= he primary workflow should be, primary, as in, consistent regardless of the= file system used. Please explain how grub should know when to access /boot/grub/grubenv and when to access 0xEA partition. >=20 > >=20 > >> It's GRUB's partition it can put anything it wants there, exactly where > > it expects to always find it. No coordination with filesystem groups > > required. I don't see any of the fundamental behaviors about Btrfs > > you're referring to changing anytime soon because it's simply how the > > fs works, they aren't bugs. So either GRUB gets its own partition with > > exclusive domain, or it continues to be hobbled by filesystem > > dependencies like needing to be forced installed on ext, can't be > > installed at all to XFS, and barely fits in 64KB on the Btrfs pad. > >>=20 > >> It's not like there's a shortage of partitions. > >=20 > > There is in real life. >=20 > Not really. There's a shortage of primary partitions on MBR but *if* GRUB= boot.img is permitted on the MBR, which is the default use case, then prim= ary partitions aren't needed for core.img+grubenv+grub.cfg, those can go on= an extended partition. And then even if Linux /boot is corrupt, I could st= ill get a working GRUB menu that will permit me to boot e.g. Windows on the= same disk. Right now this fails. >=20 >=20 > Chris Murphy >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel