2013/12/24 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>: > 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
As a follow up to your previous example. If we want the grub.cfg unmodfied from it's snapshot source, we need to dynamically set it's new subvolume to boot. I suppose a more complete config would therefore like this. insmod regexp for x in /debian/*; do if [ -f $x/boot/grub/grub.cfg ]; then submenu "Debian (snapshot at $x)" "$x" { bootdir="$1" rootdir="$1" export bootdir export rootdir configfile_extract $1/boot/grub/grub.cfg } done Having a way to retain unmodfied copy of grub.cfg in snapshot is pretty important imho, not only because the snapshot could be read-only, but also we can diff with snapshots to track it's changes. And very thankful for the "$1" magic, it heals my headache of variable assignment per each (sub)menu entries. Regards, Michael > >> >>> >>> 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 >> > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel