Re: booting btrfs

[Andrey Borzenkov]

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
> 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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel