Re: booting btrfs

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4750 bytes --]

On 20.12.2013 15:54, Michael Chang wrote:
> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> On 20.12.2013 10:46, Michael Chang wrote:
>>> 2013/12/20 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>>> On 19.12.2013 17:13, Andrey Borzenkov wrote:
>>>>> В Mon, 28 Oct 2013 01:44:26 +0100
>>>>> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@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.
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
> 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?
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
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]