Re: booting btrfs

[Chris Murphy]

On Dec 22, 2013, at 9:52 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
<address@hidden> wrote:

> On 23.12.2013 05:45, Chris Murphy wrote:
>> As for grub's part in the solution, it seems like it would need to 
>> understand absolute paths to subvol 5, as well as relative paths to the 
>> default subvol
>> (set with the 'btrfs subvol set-default' command).
> It doesn't seem to me at all that "relative" paths is a necessity and you 
> don't provide a usecase

OK it was Andrey who suggested booting snapshots by changing set-default rather 
than my more complicated example, which actually was a simple one. I don't 
think either of us is yet saying this is a necessity, that there's no other 
way. We're just discussing the possible approaches, and figuring out how 
fragile they are, and how much and where certain work would need to be done. 
Clearly it's not just a grub concern.

The use case is rolling back from failed system updates for example, to do that 
means booting a snapshot. Either /boot or rootfs on Btrfs (or both).

If relative paths are used, neither core.img nor grub.cfg needs to be modified, 
because merely a user space program changing the default subvolume would cause 
the existing core.img and grub.cfg to boot the snapshot.

If grub only supports absolute paths, then something must at least modify 
grub.cfg to point to the correct snapshot by changing 
root=<fullpathtosnapshotwenowwanttoboot>. If /boot is on Btrfs then 
additionally it means core.img needs to be replaced/modified so it will find 
the correct grub.cfg. That's a lot more complicated, enough that my crazy idea 
of just shuffling things around with mv and more snapshots like the simple 
example I posted previously is probably better.




>>>> except it is
>>>> not that straightforward in current btrfs because path names are
>>>> resolved relative to current root :)
>> Navigation of a currently mounted subvolume, yes, I can only navigate below 
>> that point. It's no different than being in chroot, or mounting a partition 
>> and being unable to navigate into other partitions.
> This analogies all share a common crucial point: GRUB neither supports nor 
> needs any of them.


That whole part is really off topic to grub and therefore isn't a good reason 
to categorically reject the idea of supporting paths relative to the default 
subvolume.