<div dir="ltr"><div dir="ltr">On Sun, Sep 6, 2020 at 9:28 PM Alexander E. Patrakov <<a href="mailto:patrakov@gmail.com">patrakov@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Sep 5, 2020 at 3:12 AM Lennart Poettering<br>
<<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>> wrote:<br>
><br>
> On Fr, 04.09.20 21:41, Dave Howorth (<a href="mailto:systemd@howorth.org.uk" target="_blank">systemd@howorth.org.uk</a>) wrote:<br>
><br>
> > On Fri, 4 Sep 2020 17:44:23 +0200<br>
> > Lennart Poettering <<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>> wrote:<br>
> > > On Fr, 04.09.20 17:10, Reindl Harald (<a href="mailto:h.reindl@thelounge.net" target="_blank">h.reindl@thelounge.net</a>) wrote:<br>
> > ><br>
> > > > > No, that's not supported in sd-boot. A boot loader is a boot<br>
> > > > > loader, it should contain a fragile storage stack. It's kinda<br>
> > > > > what sd-boot is supposed to do better than grub.<br>
> > > ><br>
> > > > well, a boot loader should just *load* and not write anything so<br>
> > > > RAID1 is technically no problem and it shouldn't matter which of<br>
> > > > the 1, 2, 3 or 4 disks is there unless one survived.<br>
> > ><br>
> > > Robust boot loaders typically want to write boot counters to disk, so<br>
> > > that they can automatically revert back to older versions of the<br>
> > > OS/kernel if it doesn't boot. Thus some form of write access is<br>
> > > necessary if you care about robustness.<br>
> ><br>
> > But surely a boot loader of all things should never try to write to the<br>
> > place it is loading from? Booting should be idempotent (as long as it<br>
> > works, for sure). The only sane policy would seem to be that the loader<br>
> > had another path to a separate writable area?<br>
><br>
> UEFI provides file system access. Both read and write. Typically for<br>
> VFAT. Yeah, a boot loader should not modify the files it is itself<br>
> loaded from and also keep writes generally at a minimum, but counting<br>
> boots is generally the absolute minimum necessary, and can be<br>
> implemented by single sector updates in file systems such as VFAT. So<br>
> that's what sd-boot for example does.<br>
<br>
May I know why this design has been chosen over keeping the boot<br>
counts in UEFI variables?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>