On Mon, Dec 23, 2013 at 08:43:34PM -0700, Chris Murphy wrote: > > On Dec 23, 2013, at 7:26 PM, Michael Chang <mch...@suse.com> wrote: > > > 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? > > My vague recollection is that it did used to work this way before 2.00, but > maybe was unintended?
It used to follow relative path of set-default volume, but was reverted to always use absolute path of real root. It's similar to my question but mine is to have a path intepretation per any subvolume set via environment variable or so. It will work like this way. set btrfs_subvol=.snapshot_1 <All path intepretation by the .snapshot_1 subvolume ..> set btrfs_subvol=.snapshot_2 <All path intepretation by the .snapshot_2 subvolume ..> But this would bring ambiguous path back that I'm not sure a good idea or not to have such feature. > > > 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. > > OK in that case the tool creates the snapshots, modifies its fstab, and > updates grub.cfg so they're displayed. > > Direct editing of grub.cfg is fragile in that the user could run > grub-mkconfig at any time. It's better for the tool to use an existing entry > as a template, and add snapshot entries to 40_custom, then run grub-mkconfig. Yes. I think this is suggested approch for modifying grub configs. What bothers me in hooking into grub-mkconfig is it takes time to finish the "entire" config and will slow down snapshot tools in creating the snapshot if we hook grub-mkconfig into it's post processing scripts. Does offer an option like `--run-script=90_btrfs_snapshot` to grub-mkconfig feasible or not? My apologies if this is off topic here. Regards, Michael > > Another thing to note is that there are UEFI computers shipping that don't > have USB initialized by the firmware by default at boot time. So the user > couldn't use this menu on such systems - which some have suggested will > become increasingly common. This implies a snapshot tool that provides the UI > to choose snapshots prior to rebooting into that snapshot. > > > 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 understand. I mean it's eventually feasible for a single Btrfs volume to > contain multiple distributions in their own subvolumes, because Btrfs volumes > are designed to be large, and easily extend to multiple devices. > > It's essentially the same as multiboot without Btrfs at all, the core.img > would point to a stable "master" grub.cfg that in turn uses configfile to > point to the grub.cfg for each distribution. Each distribution maintains its > own grub.cfg without modifying the "master" that core.img is pointing to. It > would be nice if distributions made this configuration easy for users to > implement. > > I think this might be better than doing it with set-default and leave that > strictly a user domain function/short cut to being able to mount without -o > subvol= option. > > > > >> > >> 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 /. > > Yes good point. Your snapshot tool could first create a read only snapshot, > then for no space cost also create a rw snapshot of the read only one, then > add the rw snapshot to the grub.cfg. The tool could give the user the option > to always "revert" the changes caused by booting a snapshot - this would > cause the rw snapshot being deleted and a new rw snapshot created from the > read only one. > > > Chris Murphy > -- Michael Chang Software Engineer Rm. B, 26F, No.216, Tun Hwa S. Rd., Sec.2 Taipei 106, Taiwan, R.O.C +886223760030 mch...@suse.com SUSE _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
