On Mon, Dec 30, 2013 at 3:28 PM, Vladimir 'φ-coder/phcoder' Serbinenko
<phco...@gmail.com> 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 <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.
>>
> No. Just add $btrfs_subvol into paths that you want modified.
I do not think that even this is required. We already have
${config_directory} so configuraton simply can be done relative to it.
>>
>> 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.
>>
> Not necessarry.Read my e-mail for explanation on how to do sanely and
> raise any problems you see with it.
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
