From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XlX0e-0007Rr-Fp for mharc-grub-devel@gnu.org; Tue, 04 Nov 2014 00:50:28 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlX0X-0007Qs-Bq for grub-devel@gnu.org; Tue, 04 Nov 2014 00:50:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlX0R-0007Rp-M9 for grub-devel@gnu.org; Tue, 04 Nov 2014 00:50:21 -0500 Received: from mail-lb0-x22b.google.com ([2a00:1450:4010:c04::22b]:56487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlX0R-0007Rf-4s for grub-devel@gnu.org; Tue, 04 Nov 2014 00:50:15 -0500 Received: by mail-lb0-f171.google.com with SMTP id b6so2574465lbj.16 for ; Mon, 03 Nov 2014 21:50:13 -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=4QBNzOP64gpKLq9VyxRbLJCvMZOaPSidTpMcf4N2K4M=; b=aWhO6z0mggRAWcrXkby63Tqdqr/FAQ89xtLo3nNmDl/fKgegp8q7aq4FuRliHAfs2J +0DFcgFdo3r9R4epyLacGAvXeTPq6mchw1oX9Nbhj4ftPfjguEf7ufAby2EdHFEq+JBW RsnRwRM3JAnialJsoT6qrHwvzd0toGj4qGkSr031hYMiTifQrqsgb9MwdcYwh0v9K4ik W1oTj/HdiebRQDQwguy73wMU3OJEbLtAbw0M3h2gFp4LjsCdhBherQR+nsAzqbZK7PGv QgFCRI8wioWWvDlbbwdDWr+5vF0H30DXkGPD2pX0aCf7zLDaOkZ/yqXMMkJf07fgCS/T wVww== X-Received: by 10.112.169.106 with SMTP id ad10mr56437753lbc.13.1415080212897; Mon, 03 Nov 2014 21:50:12 -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 z10sm8769529lbo.33.2014.11.03.21.50.11 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 21:50:11 -0800 (PST) Date: Tue, 4 Nov 2014 08:50:10 +0300 From: Andrei Borzenkov To: Chris Murphy Subject: Re: workaround install boot on btrfs with windows partition scheme Message-ID: <20141104085010.20a1a04a@opensuse.site> In-Reply-To: <783F70DC-0992-4337-859B-82963BB48838@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> <20141103232951.0cd1b111@opensuse.site> <783F70DC-0992-4337-859B-82963BB48838@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::22b 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: Tue, 04 Nov 2014 05:50:27 -0000 =D0=92 Mon, 3 Nov 2014 14:05:24 -0700 Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > On Nov 3, 2014, at 1:29 PM, Andrei Borzenkov wrote: >=20 > > =D0=92 Mon, 3 Nov 2014 12:36:24 -0700 > > Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >=20 > >>=20 > >> On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov wr= ote: > >>=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 = wrote: > >>>>>=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= problem, we already have multiple MBR gaps and hence multiple core.img ins= tances. > >=20 > > 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. >=20 > Which is fragile, BTW, because if Linux /boot becomes corrupt, now I don'= t even get a GRUB menu and can't boot any other OS on the same system, e.g.= Windows or a 2nd Linux instance. GRUB as installed to a device should be c= ompletely self contained, it means fewer single points of failure. It is self contained if you treat /boot/grub as bootloader partition. You are free to create separate filesystem for it and keep it unmounted by default. >=20 >=20 > > How can > > multiple core.img refer to the same 0xEA partition to be sure they read > > (and write!) the same grubenv? >=20 > There's no assurance they do this now. Multiple core.img can have multipl= e roots on multiple devices, so each may point to different grubenv anyway.= We can't be sure they all point to the same grubenv in any case. >=20 > HOWEVER, I understand the confusion, it's my fault. 0xEA proposed by Boot= loaderspec is FAT32 to be used for Linux /boot and shared. That has all sor= ts of problems that aren't relevant in this thread, but it's not the equiva= lent of BIOSboot on GPT, which is an unformatted partition. >=20 > I'm suggesting an MBR partition type, equivalent to the BIOSboot partitio= n, for embedding core.img instead of the MBR gap, so that there is always a= reliable location for GRUB. If devs want it FAT32 like on UEFI, fine. If y= ou want it unformatted like BIOSboot, fine. I have nothing to say about tha= t. I just want to see the primary use case for installing GRUB on MBR parti= tion drives to actually be the primary use case, rather than seemingly alwa= ys having to fallback on special cases. >=20 > For example on Fedora, since the installer change, they no longer use gru= b-install --force to install GRUB to ext4 /boot and this has really made a = lot of users angry and most of them refuse to learn how to install it manua= lly instead they claim to have moved to different distributions that still = use --force by default.=20 >=20 > For example, opensuse's GUI installer still uses --force by default, whic= h by definition is a special case. Their *default* most common case, is now= using a workflow explicitly not recommended by GRUB upstream. And the reas= on why is because the simple case, installing to MBR gap, is unreliable. It= has been for a very long time. >=20 >=20 >=20 > >=20 > >> 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 sayin= g the primary workflow should be, primary, as in, consistent regardless of = the file system used. > >=20 > > Please explain how grub should know when to access /boot/grub/grubenv > > and when to access 0xEA partition. >=20 > Move core.img+grubenv+grub.cfg to the same partition. Do this for UEFI's = ESP, and BIOSBoot, and a suitable explicit partition as replacement for MBR= gap. >=20 How do you edit grub.cfg which is now in raw partition? > This is also easier to replicate across multiple disks, for raid1/5/6 boo= ting. >=20 Which of replica across multiple disks holds *the* authoritative copy of grubenv and grub.cfg? >=20 > Chris Murphy >=20