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

[Mantas Mikulėnas]

On Sun, Sep 6, 2020 at 9:28 PM Alexander E. Patrakov <patrakov at gmail.com>
wrote:

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

I think it was considered but strongly rejected. The problem is that many
older firmwares are especially fragile when it comes to NVRAM writes
(remember Samsung in 2013?) On my older ASUS laptop I've already had
problems after merely adding/deleting boot entries too many times, and I
*would not* want a write to happen on every single boot.

As much as I distrust the FAT implementations in my computers' firmwares, I
still trust them a little bit more than their EFI variable NVRAM
management. (Partly because I don't *have* to trust them as much – if
everything goes bad I can at least wipe and re-mkfs the EFI system
partition from zero, I can't easily do the same with the NVRAM.)

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200907/3b3547fc/attachment.htm>