Re: booting btrfs

[Chris Murphy]

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?

> 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: /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.


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


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


Chris Murphy