On Sun, Jul 19, 2015 at 11:58 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
I understand the rationalization, it's easier to get to bootable snapshots and rollbacks this way. I just disagree with a.) taking the user's feature and control away from them, b.) making the boot process essentially invisible when it comes to what subvolume is being used.
You also need to a) somehow designate snapshot to be booted by default
That should be something the bootloader configuration understands. Snapshot doesn't change the need to define the bootloader's need to know what root is, to find the specific kernel + initramfs + root fs to pass off to the kernel. Now what's being done is to say, no we're giving up on all such specifics and we're going to hide it in fs metadata that is Btrfs specific. So the entire boot process has now changed, and only on Btrfs.
and b) handle path changes when snapshot is created (snapshot is different subvolume so any path inside grub.cfg needs adjustment).
This is no different than an LVM thinp snapshot where now it's a different device mapper path for boot and root. If you don't like things modifying grub.cfg, then we need to get serious about fixing whatever problems GRUB upstream has with the bootloaderspec. Either the original or mjg59's variant. And then whatever wants to change the boot process needs to add a new drop in script, rather than modifying bootloader files.
Using default subvolume appears to solve everything nicely ... with expense of need to maintain huge pile of distro-specific patches which make grub incompatible to upstream (and probably other distros as well - did not look at what fedora or ubuntu do).
It's totally incompatible with upstream which has definitively said all paths on btrfs are taken as relative to <FS_TREE>/subvolid 5. And on SUSE, because of this architectural dependency on default subvolume, has reverted those upstream patches, so that GRUB does paths relative to the default subvolume. Otherwise those 200 /boot/grub2/grub.cfgs are found on the same subvolume rather than relative to their separate subvolumes. Absolute paths make a lot more sense in that it's self describing. A human can read the path in both dmesg and journal and follow the boot process. That's not the case with default subvolume ID. A partial work around is to ask Btrfs upstream to print the subvolid, or maybe even the entire subvol ID's path relative to <FS_TREE> at mount time. That way anytime any btrfs file system is mounted (even subsequent mounts of subvolumes) that we get a kernel message with the absolute path of that subvolume. But this still takes away a feature meant for the user, and usurps it for a utility to manage behind the scenes. If there's concensus on doing it this way, then tools should do it through libbtrfs, and the user space tools should be changed to either disallow set-default or produce a warning and maybe even require a force flag for the user to change it.
I actually have design draft (from grub side) that requires minimal code changes (and some changes are what I believe should be included for other reasons) and solves all these issues. But it also means changes to installer, yast, snapper ... if anyone is willing to cooperate on fixing those, let's setup OBS project and try to implement it. Then it can be present as alternative solution; and I am pretty confident that GRUB changes that are required will be suitable for inclusion upstream.
Do you have a basic outline for this draft? I'm fairly dense when it comes to reading code. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org