Re: booting btrfs

[Vladimir 'φ-coder/phcoder' Serbinenko]

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.

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.

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.

signature.asc
Description: OpenPGP digital signature