Re: booting btrfs

[Michael Chang]

On Mon, Dec 30, 2013 at 12:28:44PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 30.12.2013 11:18, Michael Chang wrote:
> > 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.
> > 
> No. Just add $btrfs_subvol into paths that you want modified.

OK. Good to know. Though I think it could provide usefulness in some
cases but now I am also convinced that having consistent path
outweights them.

> > 
> > 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.

Sorry I didn't make this clear. In openSUSE, we manage snapshots with
one tool called snapper. And it uses it's own metadata to describe the
snapshots (creation date, types, etc ..) and that script is actually
intended to get the snapshots named and organized from metadata
provided by snapper.

I thought this is not interested by upstream as it's not general and is
customed feature of downstream distribution, also that it would be
installed and maintained by snapper or any other package according to
feature requirments. It's submenu will be created side-by-side with
the default one we're discussing here (which's dynamically created) as
add-on to it to offer more choice.

That's why this is off topic in my mind as it seems to deviate the
discussion. :) I bumped to the issue of running grub-mkconfig slowing
down the creation process, although there could use other way to get
around it, I'd like to poke if any one has different ideas.

> > 
> Not necessarry.Read my e-mail for explanation on how to do sanely and
> raise any problems you see with it.
> 

Overall it works for me with your recipe config of dynamic entries.
The problem I had was extract_entries_configfile cannot execute
commnads due to they are jailed[1], so no entry could boot under it. 
OTOH the menu was correctly displayed.

I have no idea how to unjail the commands, subsequent tests using
configfile was successful, but not as ideal as having
extract_entries_configfile as it offers less risk on different menu
contexts, among other things.

[1]
error: setparams isn't allowed to execute in an extractor.
error: insmod isn't allowed to execute in an extractor.
error: insmod isn't allowed to execute in an extractor.
error: insmod isn't allowed to execute in an extractor.
error: insmod isn't allowed to execute in an extractor.
error: echo isn't allowed to execute in an extractor.
error: linux isn't allowed to execute in an extractor.
error: echo isn't allowed to execute in an extractor.
error: initrd isn't allowed to execute in an extractor.

Anyone can help to pointer me this?

Thanks,
Michael

> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel