On Mon, Jan 13, 2014 at 9:05 AM, Michael Chang <mch...@suse.com> wrote: > 2014/1/11 Andrey Borzenkov <arvidj...@gmail.com>: >> В 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. > > My concern is on chainloading /fs/core.img appropriate ? It looked to > me would likely to fail because the installed lba address has been > hardcoded on it and would go back to the origin (stage1.5 per your > instance.) >
No. LBA is updated in image that is embedded - it is not the same as what is kept in core.img. grub-bios-setup modifies it in memory before writing into embedding area. > Or we need a way to control "boot" by jumping to it's loaded second sector. > >> >>> 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? :) > > For snapshot creation is possible to not update master config if it's > using "dynamic" way of syntax to find the snapshots, as Vladmir has > been demonstrated in it's examples. > I replied specifically to "configuration could have a list of all snapshots". It is not dynamic :) >> >>> (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". > > It seems like generating a slave config sourced by master in snapshot > is less work and intrusive to current grub-mkconfig. > > I like the idea of --split, and would be great to see the extending of > it with ability to update on specified configuration files. For > example, we don't forced to run os-prober or other scripts after new > kernel entries created. > > --split --run=10_linux,20_linux_xen > Yes, that would be of course interesting extension in this case. >> >> 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). > > Are you suggesting to use os-prober, instead sourced by master config > directly for inclusion of boot entries of snapshots ? Or I've > misinterpreted it? > Oh, sorry for confusion. I simply meant that current 30_os-prober is buggy and needs fixing. I think I have an idea how. >> >>> 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? > > If the concept could work that's definitely more feasible solution to > me as well, if the problems could be sorted out and fixed. > > Regards, > Michael > >> >>> 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. >>> >> >> _______________________________________________ >> 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
