F43 Change Proposal: Anaconda Drop Support UEFI on MBR (self-contained)

Disallow UEFI on MBR for x86 in Anaconda

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.

Wiki
Announced

:link: 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.

:link: Owner

:link: 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 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.

:link: Feedback

:link: 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.

:link: Scope

  • Proposal owners: The upstream PR is ready

  • Other developers:

  • Release engineering: #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:

:link: 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.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? Y/N

:link: How To Test

After 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.

:link: User Experience

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) 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), Yes/No

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Last edited by @amoloney 2025-07-03T19:03:16Z

Last edited by @amoloney 2025-07-03T19:03:16Z

1 Like

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

Is there at all any kind of a performance difference (any scenario) between MBR and GPT?

I haven’t looked into perf, but I’m interested in improvements anywhere to that first before reducing burden. But this likely falls under rarely-used config and I don’t really require this.

Why wouldn’t it be viable long-term?

Wholeheartedly agree with the change.

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.

(see introduction above)

If it exists now, that implies it can work and was tested. If I was using it and it worked, it’d probably be reliable and supported by my firmware.

It sounds like if it works now then there’s no technical reason why it would become unreliable, unless Fedora changes how its packaged to make it less-functional. So if the argument is Fedora can make it unreliable in future updates, couldn’t that go for any software? Or is there a technical reason for random unreliability like MBR might randomly write improper bytes somewhere with a certain filesystem?

I agree with the proposal, but I’m curious about the ease of MBR to GPT conversion, particularly for users setting up dual-boot systems with Windows. Obviously, MBR is antiquated, but I’d like to know that we have a good migration path from it for potential users.

The reason I know is that on MBR you have partition restriction and the extended partition which makes thins ugly.

Window, Apple and Linux propose to use GPT >> https://www.howtogeek.com/193669/whats-the-difference-between-gpt-and-mbr-when-partitioning-a-drive/#gpt-39-s-advantages

Fedora performs QA for UEFI+GPT configurations and not UEFI+MBR configurations, so while it is working now, no one would be the wiser if it stops working in the future until it reaches an end user. I’d say it’s better to just disallow those so users won’t attempt it and be bitten by such bugs in the future.

Given how niche this setup is (e.g. Windows not supporting it), system firmware providers might not test it either, and could break it in an update (very unlikely, admittedly).

3 Likes

Is UEFI on MBR even supported by the Windows installer?

This is a pretty obscure setup, I can’t imagine this effects a huge number of installs.

I migrated Windows 10 from mbr to gpt using Windows tools from microsoft. A web search will find them for you.
Windows 11 does not support mbr.
After the migration to gpt I upgraded Windows 10 to Windows 11.

2 Likes

It exists for two reasons, one of which is no longer valid:

  • Back when we made only a single cloud image for all cloud providers, AWS did not support UEFI at all and choked on legacy boot with GPT, so the cloud image needed to be MBR to work. This is not true anymore (AWS supports UEFI, and all providers support legacy boot with GPT now)
  • Non-x86 architectures (particularly ARM) have platforms that have buggy or nonexistent support for GPT and need MBR to work, even with UEFI.

There are basically no performance implications since all GPT disks have a protective MBR that allows the legacy boot jump sequence to work. Most features in the UEFI spec are optimized around GPT, but basic UEFI features are expected to work with MBR as well.

However, UEFI+MBR is a buggy combination on x86 systems because a lot of UEFI implementations skipped or incorrectly handled an MBR system volume due to a misinterpretation that UEFI requires GPT. Since most UEFI implementations for ARM and RISC-V are based on relatively recent EDK2 code, this kind of problem doesn’t really exist there.

6 Likes

And, as I recall, some of the earliest ARM SBCs loaded their initial boot image (often a u-boot spl/bin) from a fixed location on the disk, and that location was sometimes in the middle of what would have been a GPT header, forcing one to use MBR (even if one would end up using u-boot in efi mode). The ARM ecosystem has made some interesting choices along the way.

I haven’t looked on the process for linux, but there is a way on Windows. But it isn’t without risks. Reinstalling the OS because it didn’t work doesn’t sound like a fun weekend.

It affects me! It is not officially supported on the win11 iso. But can still be installed anyways without issues. Win10 it is officially supported. Seeing as win11 is basically win10 service pack 4, I’d say it is still officially supported :slight_smile:

If this passes, I’ll stop using Fedora. If things go sideways, and a reinstall is needed, I won’t be converting my windows to GPT (chance it might not work) and reinstalling Fedora. While I have all my files backed up, re-doing everything for 2 operating systems would take days. Not wanting to do that.

Are you booting in EFI mode or in CSM (legacy) mode? As far as I know of, the Windows installer will not let you install on MBR in EFI mode and would require you to boot using legacy mode. So I can hardly say that this is a “supported” configuration by any means on Windows.

From Windows Setup: Installing using the MBR or GPT partition style | Microsoft Learn

When installing Windows on UEFI-based PCs using Windows Setup, your hard drive partition style must be set up to support either UEFI mode or legacy BIOS-compatibility mode.

For example, if you receive the error message: “Windows cannot be installed to this disk. The selected disk is not of the GPT partition style”, it’s because your PC is booted in UEFI mode, but your hard drive is not configured for UEFI mode. You’ve got a few options:

  1. Reboot the PC in legacy BIOS-compatibility mode. This option lets you keep the existing partition style. For more info, see Boot to UEFI Mode or Legacy BIOS mode.
  2. Reformat the drive for UEFI by using the GPT partition style. This option lets you use the PC’s UEFI firmware features.You can do this yourself by reformatting the drive using the instructions below, or if you need to preserve the data, use a third-party utility to convert the drive to GPT format.

This proposal only affects systems which boots using EFI (non-CSM/legacy) mode, and does not have any effects on systems using CSM (legacy) mode.

I really don’t think it is. This proposal is not to remove MBR support. It is to remove UEFI on MBR which is a really obscure use case in which you have an MBR drive with an EFI partition.

I’m pretty sure Windows requires converting to GPT for moving from legacy BIOS to UEFI boot? They even have an official process for converting from MBR to GPT included in Windows.

2 Likes

My understanding is that windows 11 mandates gpt partitions.
Microsoft provides tools to allow a windows 10 on mbr can be converted to windows 10 gpt.
Before I could update from windows 10 to 11 windows insisted on this change, which worked.

Windows 11 wants secure boot and that requires gpt as well as I understand it.