grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: booting btrfs


From: Chris Murphy
Subject: Re: booting btrfs
Date: Tue, 31 Dec 2013 14:20:10 -0700

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.


Chris Murphy


reply via email to

[Prev in Thread] Current Thread [Next in Thread]