On Mon, Apr 11, 2022 at 1:21 PM Chris Adams <linux@xxxxxxxxxxx> wrote: > > Once upon a time, Peter Boy <pboy@xxxxxxxxxxxxx> said: > > I want to reiterate, it's not just about cloud platforms! if we remove BIOS boot (too early), we also kick Fedora servers, installed on hardware, out of these data centers. And the reason is not that this server hardware does not support UEFI, but the management infrastructure of the data centers. > > Speaking of servers... one thing I noticed is that a pure-Fedora system > only uses about 8M of /boot/efi. Even my dual-boot laptop with Win10 is > only using 35M. Is there a reason 256M was chosen for the default UEFI > system partition size (from the standard somewhere)? I guess that's > what Windows does too (since Win10 was on this laptop first). Any Microsoft produced ISO image (downloadable from microsoft.com, versus an OEM created image) creates 100 MiB EFI system partitions. OEM's are kinda all over the map. Fedora makes them 600 MiB these days. UEFI Spec 2.8, 13.3.1.1 says "The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system. What variant of EFI FAT to use is defined by the size of the media. The rules defining the relationship between media size and FAT variants is defined in the specification for the EFI file system." I've never been able to find a separate spec though. The UEFI spec itself defines the EFI file system earlier in this 13.3 section as "The file system supported by the Extensible Firmware Interface is based on the FAT file system." i.e. it is intended to be based on a frozen in time version of FAT. Further, "EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media." > I did notice that anaconda forces it to be at least 50M - again, is > there a reason? Anaconda folks prefer to use mkfs defaults. And dosfstools doesn't have an "EFI file system" specific flag to follow the UEFI rules, including feature freezing it in time. It just so happens FAT isn't changing much or at least not in a way that makes EFI firmware confused. But one day we might need an actual mkfs.efi utility to correctly make them. Per the spec the internal drive should be a FAT 32 file system, and either FAT 12 or 32 file system for removable drives. In practice, mkdosfs's size based logic won't make a FAT 32 volume unless the partition size is ~550 MiB (I'm not certain of the cutoff). When Anaconda was making ~250 MiB EFI system partitions, they were FAT 16. Now they are FAT 32 because the partition size is above mkdosfs's cutoff for FAT 16. I don't know if anyone ever ran into weird bugs related to the file system being 16-bit based, rather than 32-bit, but it would be hard to find out because - why would you even think to try a different FAT variant and see if what you think might be a bug still reproduces? I tried formatting a 2011 Apple Macbook as FAT 16 and FAT 12. FAT 16 was OK (although I didn't do any firmware updates which is the only reason the EFI system partition is used on Macs of this era). But FAT 12 was a bad experience - my vague recollection is I had to remove the drive from the laptop and reformat it FAT 32 because I couldn't get it to boot anything, not even from a CD or into the recovery mode. There can be pretty nasty bugs lurking around the corners of such a vast spec as UEFI, with the only requirement that involves any testing is Microsoft's hardware compatibility/certification program. -- Chris Murphy _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
