[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: booting btrfs

From: Michael Chang
Subject: Re: booting btrfs
Date: Mon, 13 Jan 2014 13:05:21 +0800

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

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.

>>                       (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

> 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?

>> 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.


>> 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
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]