On Sat, Sep 5, 2020 at 3:12 AM Lennart Poettering <lenn...@poettering.net> wrote: > > On Fr, 04.09.20 21:41, Dave Howorth (syst...@howorth.org.uk) wrote: > > > On Fri, 4 Sep 2020 17:44:23 +0200 > > Lennart Poettering <lenn...@poettering.net> wrote: > > > On Fr, 04.09.20 17:10, Reindl Harald (h.rei...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
