Re: Does GRUB btrfs support log tree?

[Andrei Borzenkov <arvidjaar@gmail.com>]

On Thu, Nov 14, 2019 at 12:50 AM Chris Murphy <lists@colorremedies.com> wrote:
>
> On Wed, Nov 13, 2019 at 6:54 PM Goffredo Baroncelli <kreijack@inwind.it> wrote:
> >
> > On 13/11/2019 18.00, Chris Murphy wrote:
> > >> The GRUB-fs should have the following main requirements:
> > >> - allow the atomicity guarantee
> > >> - allow molti-disk setup
> > >> - allow grub to update some file (grubenv come me as first)
> > >> - it should require a simple implementation (easy to porting to multiple system, which basically means linux, *bsd and solaris ?)
> > >> - the speed should be not important
> > > Plausibly we're most of the way there already, adapting the existing
> > > "BIOS Boot" partition.
> > >
> > Unfortunately the BIOS Boot partition (which means basically FAT), doesn't have support for "atomicity" nor multidisk..
>
> It's definitely not FAT. It's a blob of space owned by the bootloader.
> No file system at all. As far as I know only the BIOS variant of GRUB
> uses it.

And only on GPT.

> But GRUB does have a way of detecting core.img on it, and

No. GRUB does not "detect" core.img at all. On Legacy BIOS stage0 code
in MBR includes hardcoded absolute disk location of core.img (as list
of extents). Stage0 does not care whether this location is post-MBR
gap, BIOS boot partition or file inside another file system, it simply
loads absolute disk blocks and jumps to loaded code.

> avoids overwriting it by preferring to write in free space within that
> partition, ostensibly to support multiple instances of GRUB (multiple
> distributions),

Sorry? What are you talking about? grub itself (code executed at boot
time) does not write anything anywhere except very limited support for
environment block. grub-install simply writes either to post-MBR gap
or to BIOS Boot partition; it has absolutely no way to reliably detect
presence of "another" core.img there. BIOS Boot partition does not
have any metadata at all.

> and some degree of atomicity as the core.img is
> written first to this partition before the boot.img or "jump code" is
> written in the first 440 bytes of the MBR.
>

core.img must match block list recorded in MBR; as soon as core.img is
overwritten in-place you cannot guarantee that whatever stage0 will
read matches what has been written if stage0 update was aborted for
whatever reasons.

> Obviously this is BIOS specific, which is also x86 specific. So it
> needs to grow to be more arch and firmware agnostic. But it's so
> simple it might actually be more practical than alternatives like a
> new file system or building a transactional based FAT.
>
> I'm sorta annoyed with the UEFI spec using FAT, having not solved the
> problem of atomic updating of the EFI System partition. But we could
> agree to only use the EFI System partition for the sole purpose of the
> firmware loading an EFI file system driver, immediately allowing the
> firmware to read/write to a more reliable file system.
>

This is outside of scope of EFI, really. GRUB consists of two parts -
kernel (which is implicitly embedded in core.img/core.efi) and
loadable modules. They must match. So to ensure atomic update on any
architecture one has to

1. Write new core.img.
2. Write new /boot/grub/$platform content (new modules).
3. Switch boot information to use new version.

On EFI this would simple mean to write grubx64.efi with different name
or location on ESP and then update EFI boot variable to point to it.
Like

\EFI\vendor\image1\grubx64.efi
\EFI\vendor\image2\grubx64.efi

If you want make it alternate between two independent ESP for
additional redundancy.

/boot/grub/$platform is more involved, as a lot of code in grub2
assumes location is always under /boot/grub ($prefix more precisely).
SUSE had to introduce concept of "mounting" subvolumes on btrfs as
quick hack to overcome it.

On Legacy BIOS having two copy of core.img even more involved as it
likely really needs some primitive filesystem to manage multiple
copies.

> www.datalight.com/assets/files/secure/resources/Where%20Does%20FAT%20Fail%202016.pdf
> https://elinux.org/images/5/54/Elc2011_munegowda.pdf
>
> Those PDFs are kind interesting.
>