Re: Does GRUB btrfs support log tree?

[Chris Murphy <lists@colorremedies.com>]

On Thu, Nov 14, 2019 at 9:19 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>
> On Thu, Nov 14, 2019 at 12:50 AM Chris Murphy <lists@colorremedies.com> wrote:
> > 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-install does this, at least it's what someone on grub-devel@ list
told me ages ago.


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

Yeah what I was told is grub-install tries not to overwrite core.img.
Obviously if it's unavoidable, the update can't be atomic.


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

The need to update modules is sort of a problem for atomicity too.


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

Yes, although I'm not a fan of writes to NVRAM. They really should be
minimized. It's not high wear NVRAM, and no way to replace it if it
starts crapping out.

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

GRUB Is just too complicated. i'd really like to see it simplified and
for sure no longer depend on os-prober. When distributions are
considering things like petiboot, and linux as a bootloader,
something's gotten too complicated.


-- 
Chris Murphy