Re: F39 proposal: BiggerESP (Self-Contained Change proposal)
Hi!
Sorry for the late reply, esp. that I need to grumble a bit. I missed
the thread and only came here via the fesco ticket.
On Mon, Apr 24, 2023 at 12:15:12PM -0400, Ben Cotton wrote:
== Feedback ==
There is no alternative -- the ESP has to scale up if we want firmware
updates to continue to work and to support UKIs for next-generation
bootloaders.
Nitpick: this isn't actually true. UKIs can (and should) be loaded just
fine from the "other boot partition", i.e. /boot a.k.a. XBOOTLDR [1].
[1]
https://uapi-group.org/specifications/specs/boot_loader_specification/#ty...
== Summary ==
This change will increase the minimum size of the ESP to be 500MB,
which is also the same value used by Microsoft for Windows 10 and
newer.
This is both too much and not enough. Essentially, this grows the ESP,
but also leaves the XBOOTLDR partition large. Overall, the users pays
twice, and on some systems 1.5GB is not insignificant. OTOH, 500 or
512 MB seems not enough: three big UKIs and a rescue kernel and and
some Windows blobs and a firmware update would likely overflow.
If we want to change the default here, let's do some proper cleanup:
1. the split between ESP and XBOOTLDR is only useful in the case where
ESP already existed and was small. If the installer is *creating*
an ESP, it should just make it large enough.
2. having a second partition with a second (different) file system
implementation just increases the footprint and attack surface for
no gain. If we create XBOOTLDR, make it like the ESP (i.e. VFAT
in almost all realistic scenarios).
3. if there are bootloaders that don't read one or the other partition
as they should, fix them.
Then we can make the ESP 1 GB *and* save space compared to current
defaults.
(Point 2. is not really *necessary* for the size changes, but it'd be
nice to get rid of this anachronism if this area is being touched.)
Zbyszek