[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: booting btrfs
Re: booting btrfs
Mon, 13 Jan 2014 09:34:55 +0400
On Mon, Jan 13, 2014 at 9:05 AM, Michael Chang <address@hidden> wrote:
> 2014/1/11 Andrey Borzenkov <address@hidden>:
>> В Tue, 24 Dec 2013 05:20:19 +0100
>> Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> пишет:
>>> 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
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
>> 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
> If the concept could work that's definitely more feasible solution to
> me as well, if the problems could be sorted out and fixed.
>>> 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 mailing list