В Tue, 24 Dec 2013 05:20:19 +0100 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@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. >
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
