Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 10, 2023 at 11:21 AM Simo Sorce <simo@xxxxxxxxxx> 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@xxxxxxxxx) 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/4b17aaa8b545260bf26ab081d10dfb6a674621b9

I would be wary of issues like this.




--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux