grub-devel
[Top][All Lists]
Advanced

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

Re: booting btrfs


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: booting btrfs
Date: Fri, 20 Dec 2013 13:21:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

On 20.12.2013 10:46, Michael Chang wrote:
> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
>> On 19.12.2013 17:13, Andrey Borzenkov wrote:
>>> В Mon, 28 Oct 2013 01:44:26 +0100
>>> Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> пишет:
>>>
>>>> I changed in trunk to make / refer to real root and modified
>>>> grub-mkrelpath to follow the same convention, even if disk is mounted
>>>> with subvolid.
>>>>
>>>
>>> Can it cause compatibility issues? It means if config file that works
>>> for grub before this change will stop working after. So e.g. attempt to
>>> "configfile /file/from/partition/with/old/grub-mkconfig" will fail.
>>>
>> Normally I'd consider this a problem but the current behaviour is the
>> intended one, just back when the code was written thre were no changing
>> default yes
>>> May be subvolume support should use different syntax. Something like
>>>
>>> (hd0,1){sv=subvolume}/xxx
>>> (hd0,1){svid=NNN}/yyy
>>>
>> This would complicate the code a lot and commit us to maintaining it
>> long-term. Given that btrfs isn't clasified as stable, I consider this
>> behaviour change acceptable and it's better to handle this now rather
>> than perpetuating the issue.
> 
> Please consider the case if a snapshot was taken against real root fs
> tree to a subvolume with SNAPSHOT_ID. With syntax above providing
> mount option support we can possibly boot that snapshot with this
> config.
> 
>   set root=(hd0,1){svid=<SNAPSHOT_ID>}
>   set prefix=($root)/boot/grub2
>   normal
> 
> Without the syntax support it's almost impossible to do that. At lease
> I can't figure out any.
> 
Every volume has a name, even if you don't know it. Use grub-mkrelpath
to find out.
> Besides we may leverage that mount option support in grub-mount to
> test/develop and so on. For modern innovative file systems the mount
> option support is becoming necessary for dealing many different use
> cases.
> 
This is feature request without usecase. As such it's rejected
automatically.
> Thanks,
> Michael
> 
>>> And continue to interpret old syntax as relative to default.
>>>
>>>
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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