Re: booting btrfs

[Chris Murphy]

On Dec 20, 2013, at 7:54 AM, Michael Chang <address@hidden> 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. 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

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.

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