From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1XlAJx-0006gk-1u for mharc-grub-devel@gnu.org; Mon, 03 Nov 2014 00:36:53 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlAJr-0006ge-6y for grub-devel@gnu.org; Mon, 03 Nov 2014 00:36:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlAJm-00059b-Hr for grub-devel@gnu.org; Mon, 03 Nov 2014 00:36:47 -0500 Received: from mail-lb0-x22b.google.com ([2a00:1450:4010:c04::22b]:60531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlAJl-00059O-V8 for grub-devel@gnu.org; Mon, 03 Nov 2014 00:36:42 -0500 Received: by mail-lb0-f171.google.com with SMTP id b6so711166lbj.2 for ; Sun, 02 Nov 2014 21:36:40 -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=OcymfFSzSZ10ZLI+IcF4wvTaEuI0s8fetmTkMFDRgNA=; b=tGnluJ6jEuhkmjUcGFKm08VWpypYMOMBufOzthKW1YrLKV7A8+sHwwpeaI8SBmgjsQ cfL+MoRwbUzYFw/vUh6dry4n0/SAdwh5I7MdPDnYddmVpnHpknXiFtwbA90IDgxKXwW2 1LFbn4xSfXk9JvzSLQHARsGoFWYhgk8E6d23t182AzVfciouqO0+gjTsmvUyM1aBUFpc c/+kyTGSiE+IcEmKRCE7V/b38E9fYhXMU+C/GeNpHC+l11HiWwmNdjpMLGymgJ6Kzago PpQwyHRZ3TRDpINCqKWDGQR4lkXpkb48hqifPXhk/gVZvXmQSURfFF9dGxRGR5H4sglv oTkw== X-Received: by 10.152.18.166 with SMTP id x6mr47144079lad.18.1414993000268; Sun, 02 Nov 2014 21:36:40 -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 nb7sm7496342lbb.43.2014.11.02.21.36.38 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Nov 2014 21:36:39 -0800 (PST) Date: Mon, 3 Nov 2014 08:36:37 +0300 From: Andrei Borzenkov To: Chris Murphy Subject: Re: workaround install boot on btrfs with windows partition scheme Message-ID: <20141103083637.09a9ec80@opensuse.site> In-Reply-To: References: <20141030083243.GA7083@linux-dsax.tai.apac.novell.com> <128E41CD-F94A-4CAF-A90E-C6F007AFE28A@colorremedies.com> <20141102083701.56e93821@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: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: Mon, 03 Nov 2014 05:36:52 -0000 =D0=92 Sun, 2 Nov 2014 15:19:43 -0700 Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov wrote: >=20 > > =D0=92 Sat, 1 Nov 2014 19:34:56 -0600 > > Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >=20 > >>=20 > >> On Oct 30, 2014, at 6:42 AM, Andrei Borzenkov wr= ote: > >>>=20 > >>> I still believe this is more flexible; in particular, /boot/grub on > >>> btrfs has problems with unwritable grubenv (quite a few people are hit > >>> by this now, when openSUSE defaults to single btrfs partition) so > >>> having separate /boot as ext2 makes sense. > >>=20 > >> Hmm, interesting. What's the nature of this problem with grubenv on bt= rfs? Is the current grubenv code expecting the file to be contiguous, and d= ue to COW on btrfs it ends up not being contiguous? Does setting xattr +C o= n grubenv fix the problem? > >>=20 > >=20 > > btrfs code does not execute hooks so block list collection always gives > > empty block list and file size 0. That's unfortunate, because it also > > means e.g. progress display is not possible. > >=20 > > btrfs data is checksummed so overwriting it would involve recomputing > > checksums and replacing them. It is not possible to do in place because > > checksums are checksummed themselves ... you get the idea. > >=20 > > btrfs can be on multiple devices so we cannot even expect grubenv to be > > located on single disk; and blocklists simply do not support it. > >=20 > > btrfs can be compressed so you cannot even expect that new data will > > fit into existing space. >=20 > All the more reason for it to go in its own partition, rather than in som= e tiny area, or multiple tiny areas in filesystems. It's taken years to coo= rdinate these things. >=20 >=20 > >=20 > >> Having separate /boot on ext was fine as a short/medium term work arou= nd, but /boot on btrfs has use case benefits so it really needs to work eve= ntually. > >>=20 > >=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 Please provide scheme how grub can reliably identify which of multiple grub partitions on multiple disks is *the* partition where grubenv is located.=20 And it still should work when embedding bootloader in partition. Both with and without blocklists. >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. There is in real life. > And for future proofing this, enable GRUB to use more than one such partition. So if there's a 1MB 0xEA/BIOSboot and one day more space is needed, just add another one. >=20 >=20 > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel