Re: booting btrfs

[Michael Chang]

2014/1/1 Chris Murphy <address@hidden>:
>
> On Dec 31, 2013, at 12:50 AM, Michael Chang <address@hidden> wrote:
>
>> On Mon, Dec 30, 2013 at 03:52:36PM +0400, Andrey Borzenkov wrote:
>>> On Mon, Dec 30, 2013 at 3:28 PM, Vladimir 'φ-coder/phcoder' Serbinenko
>>> <address@hidden> 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.
>>>
>>> I do not think that even this is required. We already have
>>> ${config_directory} so configuraton simply can be done relative to it.
>>
>> Thanks for pointing me this. I think we can try to figure out
>> subvolume dynamically by combining it with ${prefix}. The script would
>> look like this.
>>
>> regexp --set=prefix_path "(/.*)" "$prefix"
>> regexp --set=config_directory_path "(/.*)" "$config_directory"
>> regexp --set=subvol "(.*)$prefix_path" "$config_directory_path"
>>
>> if [ -n "$subvol" -a -d "$subvol" ]; then
>>  rootflags="rootflags=subvol=${subvol}"
>> else
>>  rootflags=""
>>  subvol=""
>> fi
>>
>> linux ${subvol}/boot/kernel $rootflags
>> initrd ${subvol}/boot/initrd
>
> Don't those last two lines hardwire a /boot directory? To me this implies 
> /boot is assumed to be a directory on a Btrfs rootfs, and will be snapshot 
> along with rootfs.
>
> To keep /boot stable it seems it should either be in a boot subvolume so that 
> it's separate from rootfs, or maybe even in the short term could be an e.g. 
> ext4, partition.

We snapshot /boot for kernel and initrd, otherwise the rollback would
encounter problem of incompatible userland and kernel/kernel modules.
And we need the ability to rollback them in terms of usefulness.

Regards,
Michael

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