On Dec 22, 2013, at 9:52 PM, Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> 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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
