On 24.12.2013 07:12, Chris Murphy wrote: > > On Dec 23, 2013, at 9:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko > <phco...@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
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
