Re: booting btrfs

[Andrey Borzenkov <arvidjaar@gmail.com>]

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

В Tue, 24 Dec 2013 05:20:19 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:

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

This is true if we mandate that embedded core image is *the*
bootloader. But it can simply chainload core.img from $prefix which will
guarantee that core.img always matches its modules. This would allow
snapshot $prefix on grub update (or any grub change for that matter) to
have fallback case if anything goes wrong.

So this is similar to stage1.5, which also in principle could be
installed once and never changed.
 
> The configuration of master GRUB could have a list of all
> snapshots/distros/w/e

That exactly means "constantly modifying grub.cfg" on every
snapshot creation, unless I'm mistaken? :)

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

This is a bit cumbersome today. Snapshot is done from master; and as
far as I understand from this discussion, most people like to avoid
special steps to prepare snapshot for booting. Which means that
snapshot contains exactly the same entries as master. We need to either
somehow filter entries, or change how grub configuration is generated.

Something like

grub-mkconfig --split

which creates separate configuration file for each script
in /etc/grub.d allowing master to selectively source (extract entries
from) only parts of it. Or always generate two different configs -
"master" and "slave".

BTW 30_os-prober will happily fetch boot entries from every existing
snapshot, presenting them all with identical names and "merging" all
boot entries from all snapshots because it generates the same menu id
(it includes only fs UUID, but no subvolume information).

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

Another possibility would be to a) snapshot /boot/grub together with the
rest of / and b) chainload grub from snapshot. Then nothing needs
changing at all (except some small magic to set BTRFS subvolume at
runtime). The only problem here is to pass $prefix on chainloaded grub.
For EFI we get this almost for free, but for other platforms I'm not
sure. Could we pass this information as parameter when multiboot'ing
core.img? 

> Init scripts will take care of creating rw clone of snapshot if necessarry.
> 
> 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.
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]