2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>:
> On 20.12.2013 15:54, Michael Chang wrote:
>> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>:
>>> On 20.12.2013 10:46, Michael Chang wrote:
>>>> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>:
>>>>> On 19.12.2013 17:13, Andrey Borzenkov wrote:
>>>>>> В Mon, 28 Oct 2013 01:44:26 +0100
>>>>>> Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> пишет:
>>>>>>
>>>>>>> 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.
>>
>> That means we need to modify the grub,cfg in snapshot to make files
>> used by config refer to new path output by grub-mkrelpath (relative to
>> real root), right ? That could be difficult to manage especially if
>> you have a lot of snapshots and the update takes time to finish.
>>
>> Compare to use path relative to snapshot's fs root, we can leave the
>> grub.cfg in snapshot unmodified and by setting snapshot id or name in
>> a master config to switch the snapshot we want to boot. That will make
>> things a lot easier.
>>
> This is not a reason to force part of path name to become part of device
> name. Also it leaves problem of passing right options to kernel to mount
> right root open.
OK.
> Because generated config in snapshot will reset $root, any attempt to
> alter its behaviour by setting $root will fail anyway.
> Sounds like this needs additional complications in generated grub.cfg
> when on btrfs (E.g. overrideable $subvolume variable) and attempts to
> change device naming schemes don't really solve any of problems but
> create bunch of new ones.
> The real solution for your problem has to involve sth like:
> if [ x$bootdir = x ]; then
> bootdir=<precomputed bootdir>
> fi
> if [ x$rootdir = x ]; then
> rootdir=<precomputed rootdir>
> fi
>
> ...
> search ....
> linux $bootdir/vmlinuz-.... root=.. subvol=$rootdir
> initrd $bootdir/initrd.img
Thanks. I will give this config a try.
>> Probably a case is in os-prober, we can use that feature to have
>> grub-mount test subvolumes without resorting to linux mount. But I
>> admit that the gain is little.
>>
> Why isn't the use of subvolume name appropriate?
OK. I realized that can use subvolume name in path and therefore don't
need the mount options.
Thanks,
Michael
> One of these days, just for the people who insist un numeric ids rather
> than names I should write a patch to Linux which ones files only by
> inode id and no file name.
>> Regards,
>> Michael
>>
>>>> Thanks,
>>>> Michael
>>>>
>>>>>> And continue to interpret old syntax as relative to default.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
