Description of problem: When installing on Apple Macs after 2018 (with the T2 security chip), the installer will use the wrong filesystem for the EFI system partition. The installer uses HFS+, which newer Macs will not boot from. A HFS+ ESP only works for older macs. On newer macs, the installer should use a FAT32 ESP. The installer should also behave the same as standard x86-65 UEFI computers. Version in both f36, f37, and rawhide. Also affects older versions. How reproducible: Always occurs. Steps to Reproduce: 1. Boot the fedora Live ISO on newer Macs, at least after 20 2. Start the installer 3. Select Automatic partitioning (or auto-create mount points in custom partitioning). 4. Finish the installation. Actual results: The EFI system partition, which is mounted to `/boot/efi` normally has the GPT type of `Apple HFS+ ESP` with a HFSplus file system. Expected results: The EFI System partition is `FAT32`, of the GPT type `EFI System`. Additional info: The bug occurs because in lines 240-243 in `anaconda/pyanaconda/modules/storage/platform.py` in the anaconda repo, any computer that blivet identifies as a intel mac uses a HFS+ EFI. Blivet reports any `apple` chassis as an Intel Mac, but Anaconda will always behave like it is a old mac. Newer macs also are "Intel Macs", but they need a FAT32 ESP. A solution would be to either make a new "platform" for newer Macs in anaconda and blivet, or to make anaconda use a FAT32 ESP automatically. If Anaconda would automatically detect and use the right filesystem, it could check if the first partition of the internal (macos) nvme drive is FAT32. If the macos ESP is FAT32, then anaconda can use FAT32, otherwise it should use HFS+.
A bit more context/detail: On Macs with the T2 security chip there's secure boot that only allows macOS and Windows. Users can disable this (set to "No Security"), but the firmware will still enforce secure boot on HFS and APFS partitions unconditionally, so Linux cannot boot when its EFI boot loader is on one of those partition types. When the bootloader is installed to a FAT partition, secure boot isn't enforced and Linux can boot. Because Fedora puts the bootloader on a HFS partition for all Apple computers, on T2 Apple computers users get sent into macOS Recovery and are unable to boot Fedora. Some things that could be used to detect T2 Macs are: The presence of any of these pcie devices: 04:00.0 Mass storage controller [0180]: Apple Inc. ANS2 NVMe Controller [106b:2005] (rev 01) 04:00.1 Non-VGA unclassified device [0000]: Apple Inc. T2 Bridge Controller [106b:1801] (rev 01) 04:00.2 Non-VGA unclassified device [0000]: Apple Inc. T2 Secure Enclave Processor [106b:1802] (rev 01) 04:00.3 Multimedia audio controller [0401]: Apple Inc. Apple Audio Device [106b:1803] (rev 01) The DMI product names mentioned here https://lore.kernel.org/all/9D46D92F-1381-4F10-989C-1A12CD2FFDD8@live.com/ Probably the presence of these efivars ("BridgeOS" is what the T2 chip runs): BridgeOSBootSessionUUID-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14 BridgeOSGestaltKeys-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14 BridgeOSHardwareModel-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14 BridgeOSNVRAMGeneration-94b73556-2197-4702-82a8-3e1337dafbfb BridgeOSPanicWatchdogEnabled-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14 BridgeOSVersion-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14 Also there is the 2017 iMacPro1,1 that has the T2 chip, and 2019 iMac19,1/iMac19,2 that don't have the T2 chip so setting all macs manufactured after 2018 as T2 probably won't get it right all the time.
Merging https://github.com/storaged-project/blivet/pull/1090 would solve this bug.
The fix was merged in the blivet 3.7 branch, can it be back ported to older versions. It doesnt need any changes, just git apply the patch for the commit.
Thank you for the fix, we plan to release blivet 3.7.0 in time for Fedora 38. We are usually not backporting bug fixes to older Fedora releases because installation media are not updated, but if you have a use case that needs backporting to 37 or 36 we can definitely do that.
For the hardware this affects, we have to build a kernel with out-of-tree patches anyways, so I manually added the patches to blivet. It doesn't really affect people using the default ISO because you cant install using it anyways, so I think we dont need to backport this.
Ok, thanks. I'm moving this back to POST for tracking -- I want to let Bodhi close this when we actually release and build the correct version of blivet for 38.
Blivet 3.7.1 is in Fedora 38 stable.