[systemd-devel] howto switch from grub2-bios to systemd-boot

[Alexander E. Patrakov]

On Sat, Sep 5, 2020 at 3:12 AM Lennart Poettering
<lennart at poettering.net> wrote:
>
> On Fr, 04.09.20 21:41, Dave Howorth (systemd at howorth.org.uk) wrote:
>
> > On Fri, 4 Sep 2020 17:44:23 +0200
> > Lennart Poettering <lennart at poettering.net> wrote:
> > > On Fr, 04.09.20 17:10, Reindl Harald (h.reindl at thelounge.net) wrote:
> > >
> > > > > No, that's not supported in sd-boot. A boot loader is a boot
> > > > > loader, it should contain a fragile storage stack. It's kinda
> > > > > what sd-boot is supposed to do better than grub.
> > > >
> > > > well, a boot loader should just *load* and not write anything so
> > > > RAID1 is technically no problem and it shouldn't matter which of
> > > > the 1, 2, 3 or 4 disks is there unless one survived.
> > >
> > > Robust boot loaders typically want to write boot counters to disk, so
> > > that they can automatically revert back to older versions of the
> > > OS/kernel if it doesn't boot. Thus some form of write access is
> > > necessary if you care about robustness.
> >
> > But surely a boot loader of all things should never try to write to the
> > place it is loading from? Booting should be idempotent (as long as it
> > works, for sure). The only sane policy would seem to be that the loader
> > had another path to a separate writable area?
>
> UEFI provides file system access. Both read and write. Typically for
> VFAT. Yeah, a boot loader should not modify the files it is itself
> loaded from and also keep writes generally at a minimum, but counting
> boots is generally the absolute minimum necessary, and can be
> implemented by single sector updates in file systems such as VFAT. So
> that's what sd-boot for example does.

May I know why this design has been chosen over keeping the boot
counts in UEFI variables?

-- 
Alexander E. Patrakov
CV: http://pc.cd/PLz7