On Wed, Dec 21, 2022 at 12:33 PM Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Mi, 21.12.22 07:40, Neal Gompa (ngompa13(a)gmail.com) wrote:
> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal. Luckily this is rarely a problem in practice because /boot
> > is rarely written to.
>
> We could just make those read-only from the bootloader side then. I
> have /boot on btrfs, which grub/efifs doesn't support writing to at
> all anyway. Write grubenv settings into the BIOS boot partition or ESP
> rather than /boot.
The ESP is more important for booting than /boot. It's a bit weird you
are fun with writes to the former, but have issues with the latter.
Generally: boot counting/assement/fallback data is best attached to
the resources it's supposed to cover, to make rotating/vacuuming of
that data obvious and robust. Otherwise if you remove a boot entry you
need to find the matching data at a completely different place and
remove that too, which is quite fragile.
sd-boot implements boot counting by stashing the counter inside the
UKI (or bootspec type #1 conf file) file name, so that the counter is
impossible to ever get lost, pile up or so.
Because the ESP is intended to be shared, and these days /boot is not.
Unshared boot content should not be in a shared space.
We can only really have one boot manager, especially with how broken
multiple ESPs on a system are.
--
真実はいつも一つ!/ Always, there's only one truth!