On Thu, May 11, 2023 at 3:26 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Wed, May 10, 2023 at 11:54:50AM -0400, Neal Gompa wrote:
> On Wed, May 10, 2023 at 11:21 AM Simo Sorce <simo(a)redhat.com> wrote:
> >
> > On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
> > > On Di, 09.05.23 09:20, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl)
wrote:
> > >
> > > > > == 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.)
> > >
> > > I guess this might not be surprising, but this proposal makes a ton of
> > > sense to me and has my full support, FWTW
> >
> > It sounds reasonable for sure.
> > The only concern is, given Microsoft creates at most 500MB ESP
> > partitions, are we sure all UEFI systems out there will not choke on a
> > 1GB one?
> >
> > Can't we reduce the number of kernels by having *only* one UKI and a
> > rescue one that can be used to restore the previous working UKI from
> > /root if the active one fails?
>
> At least in the upstream kiwi project, we encountered problems making
> bigger ESPs because not all UEFI implementations handle FAT32 (despite
> it being part of the spec). In particular, there were a few server
> boards and especially AWS EC2 that couldn't handle it.
>
> Reference:
https://github.com/OSInside/kiwi/commit/4b17aaa8b545260bf26ab081d10dfb6a6...
Are there any more details about this? This commit just does a revert
and doesn't reference any discussion.
It was discussed in the project's Matrix room, if you want more
details, you probably will need to ask him there.
--
真実はいつも一つ!/ Always, there's only one truth!