From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VuGpo-00074N-39 for mharc-grub-devel@gnu.org; Sat, 21 Dec 2013 02:18:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuGph-00073A-Bs for grub-devel@gnu.org; Sat, 21 Dec 2013 02:18:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuGpa-0004Lv-Dt for grub-devel@gnu.org; Sat, 21 Dec 2013 02:18:45 -0500 Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:38451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuGpa-0004LU-1m for grub-devel@gnu.org; Sat, 21 Dec 2013 02:18:38 -0500 Received: by mail-lb0-f169.google.com with SMTP id u14so1482435lbd.14 for ; Fri, 20 Dec 2013 23:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=kRQConLMBm5yTWglL7atTKtZhfYqQmBlcgOx+kV/AwI=; b=LZlZzXU946+9ogZb/zWXpaA2ogCIxRCuOC3xE4gj8nE9o/b+XLUgtnQQTTS35TAU0B e/5gyGambzaiHZfRMYcriloPV1LT0020pUyXKwvsS53YqCmuPgYai5Byedcq5nLqCh6k jP1phgxVhfmM1sEc2TBUI1xoD6tcn0PZcw8GUOeoyOg0Erw8xfvS8x96Nj4TD79HglUq Hr2lJDBhCxcCS4vll+ruq+tLMD35ibaAigt5toXnUCdh491s2U3cQNXaCe3LH0FOWu5w W1yfBu67huae1Pi12zuGnsw8GIkn+QxhN8QLgccJSkg0rpNJoQ5qIf4OwUr6W80e5k08 HOOQ== X-Received: by 10.153.7.106 with SMTP id db10mr5754935lad.9.1387610316394; Fri, 20 Dec 2013 23:18:36 -0800 (PST) Received: from opensuse.site (ppp91-76-134-134.pppoe.mtu-net.ru. [91.76.134.134]) by mx.google.com with ESMTPSA id mx3sm6412046lbc.14.2013.12.20.23.18.34 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 20 Dec 2013 23:18:35 -0800 (PST) Date: Sat, 21 Dec 2013 11:18:33 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: booting btrfs Message-ID: <20131221111833.41fca8f3@opensuse.site> In-Reply-To: <946948C6-BC06-4E4E-A22A-DF6EF86802DE@colorremedies.com> References: <0C284942-C2D0-4520-93B1-3982E6AA38DF@colorremedies.com> <525AF8CD.7050100@gmail.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> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; 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::229 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: Sat, 21 Dec 2013 07:18:50 -0000 =D0=92 Fri, 20 Dec 2013 21:38:47 -0700 Chris Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > On Dec 20, 2013, at 7:54 AM, Michael Chang wrote: >=20 > >> Every volume has a name, even if you don't know it. Use grub-mkrelpath > >> to find out. > >=20 > > That means we need to modify the grub,cfg in snapshot to make files > > used by config refer to new path output by grub-mkrelpath (relative to > > real root), right ? That could be difficult to manage especially if > > you have a lot of snapshots and the update takes time to finish. >=20 > This isn't just a problem for core.img looking for the wrong grub.cfg for= a /boot on Btrfs subvolume snapshot. It's a problem for that grub.cfg poin= ting to the wrong root snapshot. And it's a problem for the /etc/fstab on t= hat root snapshot, which is likewise incorrect and will be asking for the w= rong subvolumes to be mounted. >=20 > I really don't think snapshot management is GRUB's job. I think all of th= is snapshot management is a userspace tool, and it's going to have to figur= e out a way to deal with this. Yes I completely agree here. Expecting to be able to boot from pure btrfs snapshot is na=C3=AFve. Michael, here is what openSUSE does by default when you tell it to use btrfs: linux-dwhw:~ # btrfs subvolume list / ID 256 gen 47 top level 5 path boot/grub2/i386-pc ID 258 gen 18 top level 5 path home ID 259 gen 18 top level 5 path opt ID 260 gen 18 top level 5 path srv ID 261 gen 65 top level 5 path tmp ID 262 gen 52 top level 5 path usr/local ID 263 gen 18 top level 5 path var/crash ID 264 gen 67 top level 5 path var/log ID 265 gen 18 top level 5 path var/opt ID 266 gen 62 top level 5 path var/spool ID 267 gen 57 top level 5 path var/tmp ID 269 gen 59 top level 5 path .snapshots ID 270 gen 58 top level 5 path .snapshots/1/snapshot ID 271 gen 78 top level 5 path test linux-dwhw:~ # grep btrfs /proc/self/mountinfo 21 1 0:17 / / rw,relatime shared:1 - btrfs /dev/sda2 rw,space_cache "test" is snapshot of / which I set as default and am currently booted with it. linux-dwhw:~ # btrfs subvolume get-default / ID 271 gen 78 top level 5 path test And if I now try to access any other subvolumes ... linux-dwhw:~ # ls -l /boot/grub2/i386-pc/ total 0 linux-dwhw:~ # touch /boot/grub2/i386-pc/x touch: cannot touch =E2=80=98/boot/grub2/i386-pc/x=E2=80=99: Permission den= ied linux-dwhw:~ # ls -l /var/spool total 0 linux-dwhw:~ # touch /var/spool/x touch: cannot touch =E2=80=98/var/spool/x=E2=80=99: Permission denied linux-dwhw:~ # ls -l /var/log total 0 linux-dwhw:~ # touch /var/log/x touch: cannot touch =E2=80=98/var/log/x=E2=80=99: Permission denied So booting from this snapshot is rather useless. The point here is - creating of fully functional alternate boot environment involves a bit more than single "btrfs subvolume snapshot" invocation. Adding "grub-mkconfig" (or even grub-mkimage to record correct prefix) is really just the minor part of it. > And probably the simplest solution in the short term is for this user > space tool to rename the subvolumes. So e.g. subvolumes: >=20 > boot > root > home > > And their read only snapshots: >=20 > boot_ro.1 > boot_ro.2 > root_ro.1 > root_ro.2 > home_ro.1 > home_ro.2 >=20 > The user uses a tool to indicate they now want to boot "the most recent s= napshot", and the tool does: >=20 > mv boot boot_ro.0 > mv root root_ro.0 > mv home home_ro.0 > btrfs subvol snapshot boot_ro.1 boot > btrfs subvol snapshot root_ro.1 root > btrfs subvol snapshot home_ro.1 root > Do you need to reinvent the wheel? /Boot-Environments /Boot_Environment_1 /root /boot ... /Boot_Environment_2 ... The only thing you need to do to switch is equivalent of "btrfs set-default /Boot-Environments/Boot_Envirnment_2 ... except it is not that straightforward in current btrfs because path names are resolved relative to current root :) > The lack of -r makes the snapshots rw, the file system metadata contains = relationship information: each snapshot has a uuid, and a parent uuid. And = the parent contains information about each snapshot made of it. But all of = this is domain of the snapshot tool. That's a lot easier than having to go = find fstab, grub.cfg, and figure out how to get core.img to know what boot = subvolume was intended, etc. >=20 >=20 > > Compare to use path relative to snapshot's fs root, we can leave the > > grub.cfg in snapshot unmodified and by setting snapshot id or name in > > a master config to switch the snapshot we want to boot. That will make > > things a lot easier. > Michael, snapshot of *what*? Whatever means you will use (set-default, environment variable, mount options) can set only one single property - root of filesystem. You *STILL* need to describe relationships between different (snapshots of) multiple subvolumes. I.e. *which* snapshot of /boot/grub2/i386-pc are you going to access? Having grub to always use full pathnames makes it unambiguous. Otherwise it is unmanageable on grub level (*any* directory you access may potentially have multiple versions). This must really be solved on OS level by either - mandating single subvolume for your snapshottable OS, or - adding support to grafting individual subvolumes inside of btrfs. Normal mount will not solve this on bootloader level =20 > That sounds something like the Bootloaderspec, which I like in principle = in that it recognizes how hostile the distributions are at breaking the boo= t behavior of the prior OS, in multiboot contexts. But there's some other t= hings that just don't seem workable, and it's also not even adopted upstrea= m yet by GRUB and I don't know what the status of this whole idea is. >=20 > I think the idea of snapshots in the domain of a boot manager/boot loader= is really overly complicated. For another thing, it's not really appropria= te to do a rollback and then immediately start modifying it by booting from= it. What you'd want to do is snapshot the rollback, and then use that "clo= ned" copy of the rollback, leaving the original rollback in place. Otherwis= e the provenance of that snapshot is obliterated. >=20 > And with all of these snapshots being created, something to clean up all = these bouquets is necessary. Do we really want GRUB doing that also? I just= this this is out of scope for GRUB. >=20 > An FHS for Btrfs installation locations and shapshot behaviors is possibl= y needed, so the distributions aren't stepping all over each other in an ev= en worse way that booting already is. >=20 > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel