On Dec 20, 2013, at 7:54 AM, Michael Chang <mch...@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. 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
