2014/1/13 Andrey Borzenkov <arvidj...@gmail.com>: > 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.
OK. To be more verbose, the question of mine is that I'm uncertain if we don't explicitly install to a partition using blocklists, the /fs/core.img would still automatically get blocklists of itself updated on it's own diskboot.S header or stay with default? > >> 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 :) Oh. OK. > >>> >>>> (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. For your reference, there's reports on openSUSE that os-prober entries should only be created once and not updated with every grub-mkconfig. They wanted to update os-prober entries manually since no notification about foreign os changes thus manual work is more reasonable (to them). They wanted to avoid the unneeded calls form being taken place on purpose that is ideally isolated. I think the problem could be solved more generally by introducing this change. > >>> >>> 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. You meant fixing 30_os-prober or getting btrfs snapshot booting to work ? You already know I've been working on the latter. :) Thanks, Michael > >>> >>>> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
