Re: booting btrfs

[Michael Chang]

On Mon, Dec 23, 2013 at 08:43:34PM -0700, Chris Murphy wrote:
> 
> On Dec 23, 2013, at 7:26 PM, Michael Chang <address@hidden> 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
address@hidden
SUSE