Re: booting btrfs

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

> 
>>
>> 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
>

signature.asc
Description: OpenPGP digital signature