On Thu, Oct 9, 2025, at 6:35 AM, Michael J Gruber wrote:
> Note that I'm not against a vfat /boot nor revamping things. But we have > to get our reasoning clearer. Right now we have a rushed change which > does not solve the reported problems (existing installs) and only delays > problems with fresh installs (until 2GB is not enough) - hopefully it > does not hurt anybody (I don't think it will). I agree. The change can't address existing installations. All it can do is help Fedora 43 users making new clean installations avoid the problem. We don't currently have a good way to fix this for existing users but to recommend reinstallation. I'm not imagining an atomic way of making this change, i.e no matter what the failure cause, we would either complete the switch or revert, without user intervention. In case of crash or power fail, the system would be left in a state other than the original or final states. We could make the change ensure the system still boots, but without some kind of journaling or detection of what changes have been completed, and what remains to be done, we can't resume. And without ability to automatically resume, I think it's difficult to take the risk attempting it. > If the SPEC is clear about "vfat only" then we should stick to the spec > or admit that we don't (and refrain from claiming we do). UEFI spec says the ESP must be formatted with the EFI file system [1] [2] [3] which is a variant of FAT. Fedora does not claim to comply with the Boot Loader Spec. It only ever intended to use the BLS drop-in snippet concept and format. > If we talk about changes for fresh installs (or reinstalls), we might as > well switch /boot to vfat now, though that is easier to to in-place than > resizing it. *shrug* GNU parted calls fatresize to do this. Current Fedora version of that package is fatresize-1.1.0-14.20221116gitab78c48.fc43.src.rpm This is upstream: https://github.com/ya-mouse/fatresize It's not a complicated file system. But I don't even think Microsoft supports FAT resize. If Fedora wants to move forward with full BLS spec (as written or as intended) then I think it's a flag day. I'm not sure we want to do this in stages because that means supporting those interim stages for at least a few releases. Telling people "oh just reinstall" is going to have deleterious effects, I think. And therefore, just rip off the bandaids. > But other than size and fs type of /boot (and, possibly, giving up on > the rescue entry), are there ways forward which would avoid the problem > all together and still support our typical use cases (including dual > boot, secure boot, encrypted root, bare metal firmware as well as > virtual)? Sure but it's going to take some work, and a lot of the boot chain isn't primarily Fedora's responsibility. Even if we had willing and experienced contributors, I'm not sure they'd get the commit privileges to do the necessary work. --- [1] Excerpt from the version 2.9 (2021 edition) of UEFI spec, 13.3 File System Format: "The definition of the EFI file system will be maintained by specification and will not evolve over time to deal with errata or variant interpretations in OS file system drivers or file system utilities. Future enhancements and compatibility enhancements to FAT will not be automatically included in EFI file systems. The EFI file system is a target that is fixed by the EFI specification, and other specifications explicitly referenced by the EFI specification." Removable media use FAT12/16, and system partitions use FAT32. We also don't strictly conform to this because mkdosfs uses FAT32 only at around 550 MiB and larger, and the installer only used mkdofs defaults. So quite a lot of Fedora clean installs use FAT16. [2] Distros use dosfstools. But it doesn't have a flag for ensuring we're formatting specifically with the EFI file system. Are we actually using the correct variant? [3] The kernel's FAT driver (vfat) likewise doesn't differentiate. And its the one doing all the reading and writing. -- Chris Murphy -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
