Re: booting btrfs

[Andrey Borzenkov <arvidjaar@gmail.com>]

В Fri, 20 Dec 2013 21:38:47 -0700
Chris Murphy <lists@colorremedies.com> пишет:

> 
> On Dec 20, 2013, at 7:54 AM, Michael Chang <mchang@suse.com> wrote:
> 
> >> Every volume has a name, even if you don't know it. Use grub-mkrelpath
> >> to find out.
> > 
> > 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.
> 
> 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 pointing to the wrong root snapshot. And it's a problem for the /etc/fstab on that root snapshot, which is likewise incorrect and will be asking for the wrong subvolumes to be mounted.
> 
> I really don't think snapshot management is GRUB's job. I think all of this snapshot management is a userspace tool, and it's going to have to figure out a way to deal with this.

Yes I completely agree here. Expecting to be able to boot from pure
btrfs snapshot is naïve. 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 ‘/boot/grub2/i386-pc/x’: Permission denied
linux-dwhw:~ # ls -l /var/spool
total 0
linux-dwhw:~ # touch /var/spool/x
touch: cannot touch ‘/var/spool/x’: Permission denied
linux-dwhw:~ # ls -l /var/log
total 0
linux-dwhw:~ # touch /var/log/x
touch: cannot touch ‘/var/log/x’: 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:
> 
> boot
> root
> home
>
> And their read only snapshots:
> 
> boot_ro.1
> boot_ro.2
> root_ro.1
> root_ro.2
> home_ro.1
> home_ro.2
> 
> The user uses a tool to indicate they now want to boot "the most recent snapshot", and the tool does:
> 
> 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.
> 
> 
> > 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

 
> That sounds something like the Bootloaderspec, which I like in principle in that it recognizes how hostile the distributions are at breaking the boot behavior of the prior OS, in multiboot contexts. But there's some other things that just don't seem workable, and it's also not even adopted upstream yet by GRUB and I don't know what the status of this whole idea is.
> 
> 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 appropriate 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 "cloned" copy of the rollback, leaving the original rollback in place. Otherwise the provenance of that <inserttime> snapshot is obliterated.
> 
> 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.
> 
> An FHS for Btrfs installation locations and shapshot behaviors is possibly needed, so the distributions aren't stepping all over each other in an even worse way that booting already is.
> 
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel