Re: booting btrfs

[Michael Chang]

2013/12/21 Chris Murphy <address@hidden>:
>
> 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 can't deny these problems. The snapshot booting is not possbile be
done solely by bootloader, some additional works in systems, be it
refining /etc/fstab or initrd moutning subvolues and whatever .. could
be necessary.

Now I tend to agree that supporting config for snapshot booting
shouldn't be upstream's consideration due to it's compliexity and
dependency to system, Despite on this, I still like to ask : Did
upstream think about any patch trying to provide relative path support
for btrfs subvolume name or id's a worthy work or not?

>
> 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.

Thanks.  It can be a solution for some use cases but for the one I
want to achieve it's insufficent. What I'm looking for is to list the
available snapshots in the boot menu for selecting and then booting to
it.

>
>
>> 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.

It's not a good idea for me either that making os installation to a
subvolume, and use set-default to make it default root. That's indeed
overly complicated. Meanwhile the snapshot is not for os installation,
people occasionally want to boot into it for special reasons like he
want to find from when his system performance start downgrading. I'd
consider such multiboot should not consider os installtion be in
snapshots .. because it makes no sense.

>
> 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.

I think that's like seed device and yes there should have such
handling in initrd to use a clone copy of read-only snapshots when
your kernel parameters are asking to mount it as /.

>
> 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.

That's definitely not GRUB should care about. :)

>
> 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.

Thanks for your ideas and feedbacks.

Regards,
Michael

>
> Chris Murphy