Re: booting btrfs

[Michael Chang]

2013/12/24 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> On 24.12.2013 07:12, Chris Murphy wrote:
>>
>> On Dec 23, 2013, at 9:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko 
>> <address@hidden> wrote:
>>
>>> On 24.12.2013 04:43, Chris Murphy wrote:
>>>> d point. Your snapshot tool could first create a read only snapshot, then 
>>>> for no space
>>>> cost also create a rw snapshot of the read only one, then add the rw 
>>>> snapshot to the grub.cfg.
>>>> The tool could give the user the option to always "revert" the changes 
>>>> caused by booting a snapshot
>>>> - this would cause the rw snapshot being deleted and a new rw snapshot 
>>>> created from the read only one.
>>> I don't like the idea of constantly modifying grub.cfg.
>>
>> OK. But in any case, is it valid that we want grub-mkconfig to still be able 
>> to produce complete and valid grub.cfgs? We don't want it to revert to a 
>> snapshot incapable grub.cfg. If the grub.cfg is corrupt or accidentally 
>> deleted, or /boot must be restored, we'd probably want grub-mkconfig to 
>> produce a fully correct and capable grub.cfg, yes?
>>
> you can use source_extract / configfile_extract to take only entries.
>>> Points to consider:
>>> - core of GRUB be it in embedding area or efi executable isn't snapshottable
>>> - core and modules version have to match.
>>> - translations should match originating strings.
>>> Three together imply that snapshotting $prefix/$cpu-$platform is useless
>>> if not outright harmful. modules should reside either in .efi
>>> (mkstandalone way) or in a separate volume, never to be snapshotted.
>>> The path to this volume would be baked in core, so default volume
>>> changes won't create core/module mismatch.
>>
>> Yeah I agree. There's a possible work around if someone can think of why 
>> /boot should be snapshotable:
> Did I mention /boot at all? I spoke only about stuff under $prefix.
>> /boot is a subvolume and /boot/grub is also a subvolume;
>
>> if a snapshot is made of /boot it will not contain /boot/grub at all (the 
>> creation of a snapshot does not
>
>> recursively create snapshots of subvolumes within a subvolume). So in effect 
>> if /boot/grub is a subvolume
>
>> that will make it immune to being dragged along in a snapshot 
>> unintentionally. *shrug* But I'm
>
>> still not imagining a significant advantage to snapshotting /boot.
>>
> /boot has to be snapshotted together with / to ensure coherency between
> kernel, modules and userland. Only $prefix needs exclusion with grub.cfg
> requiring special handling.
>
>>
>>> The configuration of master GRUB could have a list of all
>>> snapshots/distros/w/e (alternatively they could be listed at runtime)
>>> and source a grub.cfg from this snapshot (either directly or after user
>>> has chosen the submenu) setting some variable to indicate the path to
>>> snapshot. This slave grub.cfg would contain only entries.
>>>
>>> Configuration like themes and timeouts would be set on master level.
>>> In case of submenu it's possible to change resolution/theme/font and so
>>> on but it seems like only waste of time.
>>>
>>> Init scripts will take care of creating rw clone of snapshot if necessarry.
>>
>> The user space tool that manages these snapshots, and whatever modifications
>> need to be made to make them bootable,
> You need special init handling as you need ability to revert several
> times to a given snapshot every time branching to a new series.
>> should be able to give grub whatever
>> it needs to boot these snapshots. If it's possible that grub, via a module or
>> grub.cfg, can dynamically adjust the menu to show available snapshots to boot
>> from, without constantly modifying grub.cfg, I think that sounds much more 
>> stable.
>>
> insmod regexp
> for x in /debian/*; do
>   if [ -f $x/boot/grub/grub.cfg ]; then
>     submenu "Debian (snapshot at $x)" "$x" {
>       configfile_extract $1/boot/grub/grub.cfg
>     }
> done

As a follow up to your previous example. If we want the grub.cfg
unmodfied from it's snapshot source, we need to dynamically set it's
new subvolume to boot. I suppose a more complete config would
therefore like this.

insmod regexp
for x in /debian/*; do
    if [ -f $x/boot/grub/grub.cfg ]; then
       submenu "Debian (snapshot at $x)" "$x" {
       bootdir="$1"
       rootdir="$1"
       export bootdir
       export rootdir
       configfile_extract $1/boot/grub/grub.cfg
    }
done

Having a way to retain unmodfied copy of grub.cfg in snapshot is
pretty important imho, not only because the snapshot could be
read-only, but also we can diff with snapshots to track it's changes.

And very thankful for the "$1" magic, it heals my headache of variable
assignment per each (sub)menu entries.

Regards,
Michael

>
>>
>>>
>>> In this scenario you don't care what the default volume is, and that's
>>> the way it should be as single btrfs may contain several distributions
>>> but only one can own the default.
>>
>> Yes, I'm strongly leaning toward the user alone should own the default
>> subvolume. Consider that the user can still change the default subvolume,
>> and this can't be taken away from them. If a distro uses it, and successful
>> boot depends on the correct subvolume being set as default, the user can
>> inadvertently break boot by changing the set-default. It doesn't sound OK
>> to put the user in that situation.
>>
> I don't see any usefullness in default subvolume for fstab-ed disks.
> Every fstab entry should contain explicit subvolume name, possibly
> derived from boot parameters. Default subvolume is mainly interesting
> for removable media.
>
>>
>> Chris Murphy
>> _______________________________________________
>> 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
>