Re: booting btrfs

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

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

On 24.12.2013 07:12, Chris Murphy wrote:
> 
> On Dec 23, 2013, at 9:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> 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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]