Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_Drop_Support_UEFI_on_MBR Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-anaconda-drop-support-uefi-on-mbr-self-contained/157261 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Enforce the use of GPT partition tables for all UEFI-based Fedora installations for x86 architecture. This removes support for installing Fedora in UEFI mode on MBR-partitioned disks on x86 systems. ARM and RISC-V remain unaffected. == Owner == * Name: Anaconda team ([[User:kkoukiou|Katerina Koukiou]]) * Email: kkoukiou@xxxxxxxxxx == Detailed Description == Anaconda will no longer support installing in UEFI mode on MBR-partitioned disks for X886. While the UEFI specification technically permits booting from MBR (msdos) disks, in practice this configuration is unreliable, inconsistently supported by firmware, and not tested in Fedora. Fedora’s GRUB2 bootloader documentation already assumes the use of a GPT partition table for UEFI installations. By enforcing GPT in UEFI mode, Anaconda will provide a more robust installation experience by avoiding bootloader crashes (e.g., efibootmgr failures). Support for UEFI on MBR was originally added in [https://github.com/storaged-project/blivet/pull/764 blivet#764] to accommodate cloud image use cases, such as AWS, which at the time did not support UEFI booting on GPT disks. These constraints no longer apply to modern cloud platforms, making MBR-based UEFI setups unnecessary for current Fedora deployments. This change only applies to x86 systems booted in UEFI mode. Other architectures (such as ARM and RISC-V) are not affected, as their UEFI implementations may still depend on MBR partitioning. == Feedback == == Benefit to Fedora == * Improved reliability: Eliminating support for MBR in UEFI installations prevents bootloader failures caused by firmware or efibootmgr being unable to register UEFI boot entries on MBR disks. * Reduced support burden: Dropping an untested and rarely used configuration makes Fedora easier to test and maintain. It also avoids misleading users into thinking MBR+UEFI is a viable long-term setup. == Scope == * Proposal owners: The [https://github.com/rhinstaller/anaconda/pull/6484 upstream PR] is ready * Other developers: * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: N/A (not needed for this Change) == Upgrade/compatibility impact == This change does not affect upgrades of existing Fedora systems, as it only impacts the Anaconda installation path in UEFI mode on MBR-partitioned disks. Systems that were previously installed with MBR and UEFI may continue to function and upgrade normally, but new installations via Anaconda will require GPT. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == After [https://github.com/rhinstaller/anaconda/pull/6485 Anaconda PR #6484] is merged, users can test this change by downloading a current Fedora Rawhide ISO and attempting to install Fedora in UEFI mode on an MBR-partitioned disk on a x86 system. The installer should fail gracefully with a clear error message indicating that GPT is required for UEFI installations. == User Experience == == Dependencies == == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-announce-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-announce@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ 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
