From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VvLQw-0000eP-FZ for mharc-grub-devel@gnu.org; Tue, 24 Dec 2013 01:25:38 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvLQp-0000e6-NK for grub-devel@gnu.org; Tue, 24 Dec 2013 01:25:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VvLQh-00080w-Rr for grub-devel@gnu.org; Tue, 24 Dec 2013 01:25:31 -0500 Received: from mail-ee0-x232.google.com ([2a00:1450:4013:c00::232]:51457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VvLQh-00080q-Hk for grub-devel@gnu.org; Tue, 24 Dec 2013 01:25:23 -0500 Received: by mail-ee0-f50.google.com with SMTP id c41so2648060eek.23 for ; Mon, 23 Dec 2013 22:25:22 -0800 (PST) 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; bh=nsnECB2DyOL65pvxANVhAfy7MGCSFZFbsTQJtCw3dpY=; b=D0UtAbDdbZK7jYNMSHPp8w688UVRz1tuoch/yPvMI38A8YlQNeSCway7wq/qI/KTeQ nMXCcfmaCsbTTjUxL7DLDEMS9oh8+CDB8K2hCb7aGXbD7bakWQYxH/aQlv70Su6/unBd WkrB8JYCn3I3//o2aKs3nR7DKgnKZ1Tc7ZIWsMNM2hRkv8fK8n4Kj0JM6DuRNpged06H ydvaAZDnYPBGtniBSplPWcEEiWZ9su3dNF88MDNLW3LNpmuxC7iua1D31wZ6RsjZckVF /WdmCLuRTMxffDd4kK01lmeRTrP3TXLpgdVh6FxC91eAc4nrpf5z1Hto9J5rU3mQuw0R mBlw== X-Received: by 10.15.65.1 with SMTP id p1mr367474eex.108.1387866322765; Mon, 23 Dec 2013 22:25:22 -0800 (PST) Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch. [178.196.188.85]) by mx.google.com with ESMTPSA id e3sm51994591eeg.11.2013.12.23.22.25.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Dec 2013 22:25:21 -0800 (PST) Message-ID: <52B928D0.5060405@gmail.com> Date: Tue, 24 Dec 2013 07:25:20 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: booting btrfs References: <0C284942-C2D0-4520-93B1-3982E6AA38DF@colorremedies.com> <525B2D55.8060502@gmail.com> <339EF7EB-F50A-47F6-99BA-F46ABFECCF74@colorremedies.com> <20131014092807.6917958c@opensuse.site> <3D77CF50-285F-42C2-9325-47AC5ACF5FDC@colorremedies.com> <525C4615.5080803@gmail.com> <4B3D9706-740B-49A2-8314-FF3893071A12@colorremedies.com> <20131016065045.51027e72@opensuse.site> <526DB36A.7090201@gmail.com> <20131219201350.289470c7@opensuse.site> <52B3376A.7030301@gmail.com> <52B4364F.9020900@gmail.com> <946948C6-BC06-4E4E-A22A-DF6EF86802DE@colorremedies.com> <2FA74EFF-1716-4BDA-A8CA-4C63B0682325@colorremedies.com> <52B90B83.3090104@gmail.com> <089F5D53-DF80-44BD-A163-2FB5D489C969@colorremedies.com> In-Reply-To: <089F5D53-DF80-44BD-A163-2FB5D489C969@colorremedies.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6He3fobg0jUQrg047briJ5hqmMAU6CGjP" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::232 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, 24 Dec 2013 06:25:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6He3fobg0jUQrg047briJ5hqmMAU6CGjP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24.12.2013 07:12, Chris Murphy wrote: >=20 > On Dec 23, 2013, at 9:20 PM, Vladimir '=CF=86-coder/phcoder' Serbinenko= wrote: >=20 >> On 24.12.2013 04:43, Chris Murphy wrote: >>> d point. Your snapshot tool could first create a read only snapshot, = then for no space >>> cost also create a rw snapshot of the read only one, then add the rw = snapshot to the grub.cfg. >>> The tool could give the user the option to always "revert" the change= s caused by booting a snapshot >>> - this would cause the rw snapshot being deleted and a new rw snapsho= t created from the read only one. >> I don't like the idea of constantly modifying grub.cfg. >=20 > OK. But in any case, is it valid that we want grub-mkconfig to still be= able to produce complete and valid grub.cfgs? We don't want it to revert= to a snapshot incapable grub.cfg. If the grub.cfg is corrupt or accident= ally deleted, or /boot must be restored, we'd probably want grub-mkconfig= to produce a fully correct and capable grub.cfg, yes? >=20 you can use source_extract / configfile_extract to take only entries. >> Points to consider: >> - core of GRUB be it in embedding area or efi executable isn't snapsho= ttable >> - core and modules version have to match. >> - translations should match originating strings. >> Three together imply that snapshotting $prefix/$cpu-$platform is usele= ss >> if not outright harmful. modules should reside either in .efi >> (mkstandalone way) or in a separate volume, never to be snapshotted. >> The path to this volume would be baked in core, so default volume >> changes won't create core/module mismatch. >=20 > Yeah I agree. There's a possible work around if someone can think of wh= y /boot should be snapshotable: Did I mention /boot at all? I spoke only about stuff under $prefix. > /boot is a subvolume and /boot/grub is also a subvolume; > if a snapshot is made of /boot it will not contain /boot/grub at all (t= he creation of a snapshot does not > recursively create snapshots of subvolumes within a subvolume). So in e= ffect if /boot/grub is a subvolume > that will make it immune to being dragged along in a snapshot unintenti= onally. *shrug* But I'm > still not imagining a significant advantage to snapshotting /boot. > /boot has to be snapshotted together with / to ensure coherency between kernel, modules and userland. Only $prefix needs exclusion with grub.cfg requiring special handling. >=20 >> The configuration of master GRUB could have a list of all >> snapshots/distros/w/e (alternatively they could be listed at runtime) >> and source a grub.cfg from this snapshot (either directly or after use= r >> has chosen the submenu) setting some variable to indicate the path to >> snapshot. This slave grub.cfg would contain only entries. >> >> Configuration like themes and timeouts would be set on master level. >> In case of submenu it's possible to change resolution/theme/font and s= o >> on but it seems like only waste of time. >> >> Init scripts will take care of creating rw clone of snapshot if necess= arry. >=20 > The user space tool that manages these snapshots, and whatever modifica= tions > need to be made to make them bootable, You need special init handling as you need ability to revert several times to a given snapshot every time branching to a new series. > should be able to give grub whatever > it needs to boot these snapshots. If it's possible that grub, via a mod= ule or > grub.cfg, can dynamically adjust the menu to show available snapshots t= o boot > from, without constantly modifying grub.cfg, I think that sounds much m= ore stable. > insmod regexp for x in /debian/*; do if [ -f $x/boot/grub/grub.cfg ]; then submenu "Debian (snapshot at $x)" "$x" { configfile_extract $1/boot/grub/grub.cfg } done >=20 >> >> In this scenario you don't care what the default volume is, and that's= >> the way it should be as single btrfs may contain several distributions= >> but only one can own the default. >=20 > Yes, I'm strongly leaning toward the user alone should own the default > subvolume. Consider that the user can still change the default subvolum= e, > and this can't be taken away from them. If a distro uses it, and succes= sful > boot depends on the correct subvolume being set as default, the user ca= n > inadvertently break boot by changing the set-default. It doesn't sound = OK > to put the user in that situation. > I don't see any usefullness in default subvolume for fstab-ed disks. Every fstab entry should contain explicit subvolume name, possibly derived from boot parameters. Default subvolume is mainly interesting for removable media. >=20 > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 --6He3fobg0jUQrg047briJ5hqmMAU6CGjP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlK5KNAACgkQmBXlbbo5nOsSqAD/VMwIIkI7eRdjkle1QeUrGfpJ FP+HX2NxPExuYxS5ghkA/1jjOmLa4M7Zf3qU/W8rSVjub3fOeUrlXEt3kN6EGBB3 =qUwl -----END PGP SIGNATURE----- --6He3fobg0jUQrg047briJ5hqmMAU6CGjP--