On Thu, May 11, 2023 at 3:26 AM Zbigniew Jędrzejewski-Szmek <zbys...@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 <s...@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 (zbys...@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/4b17aaa8b545260bf26ab081d10dfb6a674621b9 > > 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! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
