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
