Bug 978430

*** Bug 978065 has been marked as a duplicate of this bug. ***

*** Bug 975970 has been marked as a duplicate of this bug. ***

parted is going to need a new partition flag (esp maybe?). pyparted, blivet and possibly anaconda will all need changes to support this.

Note that after discussions this morning, it sounds like our approach to this is simply going to be 'allow UEFI native installs to msdos-labelled disks', at least as a first try until we find out exactly how many firmwares fail to support that. As it will almost inevitably turn out that some will fail to support it.

The change isn't as simple as allowing installs on msdos labeled disks. We need to create an ESP on the disk, that's why these are failing to boot. Currently parted and pyparted do not have support for the 0xEF partition type needed to do this. So this is going to be a f20 change.

Sure, I just meant the fix is not going to be 'explain why we're not letting you do this' but 'let you do this'. I didn't mean it was literally a case of removing a check.

FC19 documentation & release notes explaining what works and what is not supported would be very helpful.  Is there a BZ for parted (etc) enhancement?
Thanks.

Hi,

I think just allowing UEFI install to a MBR disk isn't enough. It should also allow to do a legacy non-UEFI install to a MBR disk while the live media is booted via UEFI. I'll explain it on my case:

I want to install Fedora alongside Windows 7 Enterprise with bitlocker encryption on a new UEFI-capable Fujitsu laptop. The disk partitioning is MBR and the windows installation is NOT UEFI. The system's BIOS (or UEFI) is plain dumb - when it sees that a disk contains UEFI partition, it doesn't allow to boot it via legacy BIOS boot. So I only can boot Fedora Live medium via UEFI (haven't tried "nouefi" kernel option yet, that should be a workaround).

As the disk already contains two partitions (NTLDR+bitlocker on the first, windows itself on the second), I only can create two more partitions - two primary or one primary and one extended. If Fedora only allows an UEFI install to such disk, I would have to create a primary UEFI partition. And as I want to have a working legacy boot (grub has to be chainloaded from NTLDR and not the other way - bitlocker wouldn't work with TPM when chainloaded from GRUB AFAIK). So I would have to place the whole installation of Fedora (apart from /boot/efi) to a single partition, which is quite impractical.

Apart from that, If I succesfully installed the fedora in such UEFI+MBR configuration, I would have another problem. As I've said, the BIOS/UEFI is dumb, if it saw the Fedora-created UEFI partition, it would refuse to do a legacy boot of the NTLDR and I wouldn't be able to boot windows due to bitlocker.

Oh and by the way - I know it would be a nice workaround for me to simply go to the UEFI/BIOS setup and switch it to BIOS compatible mode (i.e. turn off UEFI part), but it is a corporate laptop and I do not have a UEFI/BIOS password, so that is a no-go in this situation.

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

jiri: that's out of scope for this bug. Please file separately.

It would be very useful to have fedup check for this condition and deliver a message as to why an F17 system can't be upgraded instead of doing a setup that has no chance of succeeding.  I went through several iterations of fedup, dracut, boot rescue, and restore rsync backup before I traced to this issue.

W.C.: this bug is specific to anaconda and would not affect fedup of an installed system at all. I don't know what the problem is in your case, but it's not this bug.

(In reply to Adam Williamson from comment #12)
> W.C.: this bug is specific to anaconda and would not affect fedup of an
> installed system at all. I don't know what the problem is in your case, but
> it's not this bug.

Sorry for an incorrect report.  Working through the known issues with fedup dropping to dracut on reboot and finding that I had none of those, I had an "aha" moment when I realized the disk was non-gpt and the partitions were all tagged "msdos".  Dracut has root mounted under /sysroot plain as day.  I'll open a separate bug.

it's possible fedup/dracut somehow have an issue with this configuration too, but this particular bug report is just for the code in anaconda, which is not relevant to a fedup run: fedup and anaconda are completely different codebases now.

bcl: did we do anything about this for F20?

No, but I'll make sure I get all the pieces working for F21. parted in rawhide has the new flag so it's blivet and anaconda work that needs to be done.

OK, I'll add it to F20 commonbugs.

*** Bug 891104 has been marked as a duplicate of this bug. ***

bcl: as I happen to be in this code at the moment, a drive-by note: it would probably be good for the storage sanity check to catch this case and warn that it is a non-standard configuration. The UEFI spec does not *specifically forbid* firmwares from supporting EFI system partitions on non-GPT disks, but it only *requires* that they support EFI system partitions on GPT disks.

It's likely that some people will manage to hit this case - UEFI native install to ms-dos labelled disk - just because they don't really know what they're doing, and it would probably be a good idea to raise a sanity check *warning* when we see it, as it is really pretty likely that some firmwares just won't handle it.

Note for Jiri and others in his situation - you can pass 'noefi' to the kernel, and it will drop all UEFI support, and in this case anaconda will think it's booted in BIOS compatibility mode and do a BIOS-native install. So if you really wanted to do a BIOS compat mode install, but you can't configure your firmware to boot in BIOS compat mode for some reason, that's a workaround. I've added that to the commonbugs notes.

suggested warning text: "You are performing a UEFI-native installation to a disk with an mbr/msdos (not gpt) partition table. This is an unusual and non-standard configuration which your system firmware may not be capable of supporting. If you know your firmware is capable of supporting this configuration, it is safe to proceed."

Why are you calling it a non-standard configuration?  As you said, the UEFI spec does not specifically forbid it.  In my case I was using a corp IT supplied laptop (Lenovo with Windows7/SSD hard drive).  All I wanted to do was shrink the Windows partition and install Fedora (duel boot).  After Anaconda got confused and Fedora failed to install I tried OpenSuse which installed cleanly.  The laptop has been happily dual booting ever since.

Note that I did not have to disable UEFI or add bootline options to trick the installer to install OpenSuse.

May I suggest the text: "You are performing a UEFI-native installation to a disk with an mbr/msdos (not gpt) partition table. Fedora may or may not handle this configuration correctly.  If you feel lucky proceed at your own risk.  Otherwise install a distro that handles this configuration."

Russ: it's not a question of Fedora handling it or not. It's about the firmware. The UEFI spec goes to a lot of trouble to set a baseline for what things above the firmware layer can trust the firmware layer to implement: you can trust that the firmware will be able to read EFI format executables from FAT formatted partitions on disks with GPT partition tables.

You *cannot* rely on any UEFI firmware being able to read anything other than the above, because the spec does not require it do. We are an operating system installer: we cannot know whether or not your firmware has capabilities outside the spec.

Maybe it does, and you're one of the unfortunates who owns a system that was *shipped with* a configuration that's entirely outside of the UEFI spec - a partition performing the function of an EFI system partition, on an MBR/msdos-labelled disk, and you want to install Fedora alongside that. OK, so we shouldn't forbid you from doing this.

But you may also just be some poor person who really doesn't know anything about UEFI or EFI system partitions or partition tables, and it's probably a good idea for us to let you know that you've just come up with a configuration that is definitely *not* guaranteed to work.

As a general note: it is a bad idea, when thinking about an operating installer, to only consider your own personal situation. You're considering your personal situation - you happen to own a system whose vendor has shipped it with an idiotic configuration, and you're annoyed that Fedora didn't expect that people would ship systems with this kind of idiotic configuration, and you just want Fedora to go ahead and install to the system because you know it'll work. Fine. But yours is not the *only* situation in which people might wind up trying to do a UEFI native installation to an msdos/MBR-labelled disk, so we can't *only* take your case into consideration in deciding how we should handle that situation.

Fedora's UEFI handling was initially designed to require the ESP to be on a GPT-labelled disk because that's the clear intent of the UEFI spec, and we really did not guess that some idiotic OEMs would go ahead and ship systems with UEFI native OS installs to non-GPT disks.

We accept that we have to handle that, and that's what this bug is about. But we can't just pretend it's always a perfectly safe configuration that will never cause any problems, because it isn't.

Admittedly I may "just be some poor person" and I certainly have learned more about the EFI spec than I ever wanted to know, including reading the darn thing.  And I still have the habit of calling it EFI instead of UEFI because it was just EFI back in IA64 days when I first started working with it.  Bad me.

Maybe it is an "idiotic configuration" but it's the idiotic configuration that came from corpIS (as did Jiri's above) and works quite well with Windows and OpenSuse.  And the Lenovo BIOS seems to handle it quite nicely.  It is certainly possible that corpIS's don't know what they are doing and are coming up with configurations "definitely *not* guaranteed to work" but somehow they do work for other OSes.  Maybe they are all just really lucky.

If Fedora doesn't want to support non-GPT that's Fedora's choice.  Just print out a message saying "Fedora does not support this configuration" and everyone goes on their merry way.  It certainly would have saved me days of my life trying to help debug the problem.

Since the EFI spec has been mentioned, it is worth noting Linus' comment:
http://marc.info/?l=linux-kernel&m=137008457505211&w=2

And here is Ingos:
http://marc.info/?l=linux-kernel&m=136999519324303&w=2

"Admittedly I may "just be some poor person""

That was a *general* you - "you, the user", not "you, Russ".

I really don't see why this is too difficult to understand.

Here is the set of things anaconda knows, during any given install attempt. Remember, all anaconda can count on is that it's installing to a system which claims to have a UEFI firmware.

* The UEFI spec says the system firmware *must* be able to read an EFI system partition on a GPT disk.
* The UEFI spec does *NOT* say the system firmware must be able to read an EFI system partition on an MBR disk. The *particular firmware implementation we are dealing with during any given install attempt* may do: it may not. We cannot possibly know.
* Whether the current installation attempt involves an EFI system partition on a GPT disk, or an MBR disk (or none at all).

1. If we see an EFI system partition on a GPT disk, that's good. That is a safe configuration. We can go ahead and install to it, with a reasonable expectation that it will work.

2. If we see no EFI system partition, that's bad. We know it's not going to work. We throw an error.

3. If we see an EFI system partition on an MBR disk, we are now in the Land Of Maybe. Maybe it will work. Maybe it won't. You are only thinking of *your specific case*, where you know that it will work. We cannot only think of your case. We *know* the UEFI spec does not require the firmware to understand MBR partition tables, so why is it a good thing for us to see an EFI system partition on an MBR disk and say "OK, sport, go right ahead!"? We *know* there is a reasonable possibility it will not work, because we *know* the UEFI spec does not require the firmware to support that configuration.

The appropriate behaviour in case 3) is not "deny". No-one is saying it is, but you seem to be arguing as if we were. What I'm saying is that the appropriate behaviour in case 3) is not "allow" either. It's "allow, but warn".

We *know* it is not a configuration that can be unproblematically expected to work. It *may* work, and we _now_ know there are cases where there's a sensible reason to try and use this configuration - like yours. But we also know it may *not* work, so it would be irresponsible for us to simply wave a green flag and say 'go ahead'.

I'm also trying to explain to you why our *initial* design was that the behaviour in case 3) should be "deny": because the spec is clearly written with the expectation that no jackass is going to ship a system with a UEFI native OS on an MBR partition. The whole point of the spec is to provide a nice solid reliable set of behaviours that everyone should agree on. But now we know that some jackass has gone ahead and written a firmware that can handle an ESP on an MBR disk and shipped systems like that, we have to deal with it. But we can't assume *every* UEFI system will work with that configuration, and so we should warn that it may fail when we see it.

If SUSE did not warn you about this layout I would suggest SUSE's behaviour is equally as broken as Fedora's current behaviour - it just happens to be broken in the other direction. We're too restrictive, they're too permissive. Imagine someone who has a firmware that doesn't support an ESP on an MBR disk - which is a perfectly UEFI-compliant firmware - installing SUSE, winding up with the ESP on an MBR disk, and finding the installed system doesn't boot. Do they think SUSE's installer did a good job?

Note: the check in question doesn't care if you *came into the installer* with this arrangement already present, or if you created it yourself. It also can't know if you came into the installer with this arrangement already present *and working*.

I suspect you're not properly considering all the possible cases. You're thinking of your case - where the configuration was a pre-existing one, and worked - and wondering why we have to 'check' it at all.

We could, in *theory*, only enforce this check on layouts created via anaconda, and assume that any configuration that existed before anaconda was started was 'valid' and give it a pass. But that would be a very messy design, and also, it's just wrong: people *can* and *do* run anaconda with an existing disk layout that is completely broken. We can't assume, just because you ran anaconda with an MBR-formatted disk with an EFI system partition on it, that that configuration actually works on your system. You (and again, I'm using a *general* you here) may just be a confused person who managed to create a nonsensical disk layout. This is something we see _all the time_.

> I really don't see why this is too difficult to understand.

I was thinking the same thing.

> * The UEFI spec does *NOT* say the system firmware must be able to read an
> EFI system partition on an MBR disk.

My initial response when that was first suggested was that supporting MBR
was so obvious that no one thought to explicitly state it in the spec.
Never occurred to me that anyone could possibly read it any other way.
Then I dug out the UEFI spec and found:

  2.6.2 Platform-Specific Elements
    [...] The following is a list of potential platform features and the
    elements that are required for each feature type:

    5. If a platform includes the ability to boot from a disk device,
       [...] In addition, partition support for MBR, GPT, and El Torito
       must be implemented.

Looks like an explicit requirement.

  5.1 EFI Partition Formats
  5.2 LBA 0 Format
    LBA 0 (i.e. the first block) of the hard disk contains either a legacy
    Master Boot Record (MBR) (see Section 5.2.1) or a protective MBR (see
    Section 5.2.2).
    5.2.1 Legacy Master Boot Record (MBR)
       A legacy master boot record may be located at LBA 0 (i.e. the first
       block) of the hard disk if it is not using the GPT partition scheme.
       The boot code on the MBR is not executed by EFI firmware. [...]

Looks like they expect support for MBR.

  9.3.6.1 Hard Drive
    The Hard Drive Media Device Path is used to represent a partition on a
    hard drive. Each partition has at least Hard Drive Device Path node,
    each describing an entry in a partition table. EFI supports MBR and
    GPT partitioning formats. [...]

Clearly "EFI supports MBR and GPT partitioning formats."

  12.3.1 System Partition
    A System Partition is a partition in the conventional sense of a
    partition on a legacy system. For a hard disk, a partition is a
    contiguous grouping of sectors on the disk where the starting sector
    and size are defined by the Master Boot Record (MBR), which resides on
    LBA 0 (i.e., the first sector of the hard disk) (see Section 5.2), or
    the GUID Partition Table (GPT), [...]

    A System Partition supports backward compatibility with legacy systems
    by reserving the first block (sector) of the partition for compatibility
    code. On legacy systems, the first block (sector) of a partition is
    loaded into memory and execution is transferred to this code. EFI
    firmware does not execute the code in the MBR. The EFI firmware contains
    knowledge about the partition structure of various devices, and can
    understand legacy MBR, GPT, and “El Torito.” [...]

Looks like a requirement.

  12.3.2 Partition Discovery
    This specification requires the firmware to be able to parse the legacy
    master boot record(MBR) (see Section 5.2.1), GUID Partition Table (GPT)
    (see Section 5.3.2), and El Torito (see Section 12.3.2.1) logical device
    volumes. [...]
    • if no GPT is present, each partition found in the legacy MBR partition
      tables.

You get the point.  I don't see your "Land Of Maybe".  There is a clear
description of how EFI should handle MBR.  You say "the spec is clearly
written with the expectation that no jackass is going to ship a system with
a UEFI native OS on an MBR partition." but I see a spec explaining in detail
how to handle MBR partitions.

If Fedora doesn't want to support MBR in EFI that is Fedora's call.  Other
OSes handle it quite nicely.  Most BIOSes handle it.  The UEFI spec handles it.

"If Fedora doesn't want to support MBR in EFI that is Fedora's call"

You keep saying this. It's not a question of whether *Fedora* supports it or not. The ultimate goal of the installer is to deploy a bootable system.

We could, trivially, offer to use an ext4 "EFI system partition". Or a btrfs one. Or stick it on RAID-on-LVM. The bit of work the operating system installer does with regard to the EFI system partition is trivial: we create one if it doesn't exist, and we stick our bootloader in it.

But we're not the one who has to *read* it. The firmware has to read it. It's the *firmware's* job to run the bootloader, not *Fedora's* job. You keep talking about what "Fedora supports"; the question is what UEFI firmwares support, as it's the firmware that reads and executes the bootloader. We *write* the bootloader, but we are not the one that reads it. At the phase we're talking about, the firmware is the only thing that's loaded. The operating system doesn't have a look-in.

Ergo, if our goal is to deploy a bootable operating system, then we should try to make sure that we use an EFI system partition (and bootloader, and so on) that we are reasonably sure the firmware can read.

A lot of the spec extracts you post are not requirements for the firmware to be able to perform native UEFI boot from a disk with an MBR. What they're about is saying that UEFI firmwares shouldn't barf when they see a disk with a *hybrid* MBR.

If you think about OS installers again for a minute: we need to be able to write media which are *both* UEFI-bootable *and* BIOS-bootable. If you look at a Fedora USB stick written with dd or livecd-iso-to-disk --efi, it basically has both an MBR and a GPT, to ensure it can be booted both ways. This is called a 'hybrid MBR', and what the UEFI spec is doing in several of the extracts you cite is saying firmwares shouldn't barf on these disks.

I'll have to look more closely at what the others actually require, and see if any of them are new (2.4a is a fairly new version of the spec; when the requirements for EFI system partitions in Fedora were put in place we were on 2.1 or 2.2 or something).

Looking at it again, y'know, I think you're right - I dunno why I missed it before, but a couple of bits of the spec taken together seem to pretty much require support for ESPs on MBR.

5.2.1:

"If an MBR partition has an OSType field of 0xEF (i.e., UEFI System Partition), then the firmware must add the UEFI System Partition GUID to the handle for the MBR partition using InstallProtocolInterface(). This allows drivers and applications, including OS loaders, to easily search for handles that represent UEFI System Partitions."

and then 12.3.1 taken as a whole. All the significant bits of both exist as far back as 2.1; the 2.0 spec download link gives a 404, now.

So, if we don't know of any in-the-wild firmwares that fail to support this, I'd agree that in fact the correct behaviour would be to allow the ESP to be on an MBR disk without a warning. Thanks for the correction.

And thanks to Russ and Adam for a lively discussion.  At some points I wished that bugzilla supports animated gifs.

the appropriate one at this point would involve me eating a large slice of delicious humble pie.

Thank you Adam for taking the time to read this.  Installer/early boot is an
ugly difficult area and I appreciate your effort.

So, afraid the story doesn't end there. We had a chat about this on IRC today with mjg59, UEFI expert extraordinaire, and he's of the opinion that we should not generally permit UEFI installs to MBR disks, even though it is indeed within spec.

The main case he's concerned about is an existing BIOS mode Windows install to an MBR disk; doing a UEFI native install of Fedora alongside that could render the Windows install unbootable, as we know there are firmwares which don't expose the necessary set of choices to boot both BIOS-native and UEFI-native OSes installed to the same disk, and we cannot boot a BIOS-native Windows install from a UEFI-native Fedora install's grub2 (you can't switch horses in mid-stream like that).

In theory we can try to detect and special case an existing UEFI-native install to an MBR disk, or we could add an override parameter, but it gets finicky and the anaconda devs are of the opinion we have enough codepaths already, so they're currently not interested in doing that. That may change if we find this is really a big problem, but so far what we've found doesn't really seem to indicate that it is.

I've just checked, and the Windows 8.1 installer does not allow you to do a UEFI native install to an MBR disk. If you feed it an empty MBR disk it silently reformats it to GPT; if you feed it an MBR disk with a partition, it pops up a "Windows can't be installed on this drive. (Show details)" message, and the "details" says "Windows cannot be installed to this disk. The selected disk has an MBR partition table. On EFI systems, Windows can only be installed to GPT disks".

There seems to be very conflicting information about whether previous Windows versions would do so, but at least current Windows definitely does not. We found various different bits of Microsoft documentation relating to Win7 which seemed to directly contradict each other - http://support.microsoft.com/kb/2481490 suggests that Win7 pops up this message but you can click through it, but http://msdn.microsoft.com/en-us/windows/hardware/gg463525.aspx and others say otherwise. I don't have a Win7 image handy, so I can't check.

Thanks for sorting this out guys. I'm going to close as wontfix. Reopen it only if we find large numbers of machines in the wild.

And just for the record, I'm right now in the middle of a patch that will explicitly note the ESP has to be on a GPT-formatted disk, when people run into this case in future, so at least it's clear what's going on.

Again for the record, I looked a bit further into Russ' case, and it looks like his Windows install is BIOS-native, not UEFI-native. I hope I helped him get a BIOS-native install of Fedora going, but haven't heard back yet.

*** Bug 1132849 has been marked as a duplicate of this bug. ***

UEFI on msdos labeled disks is not something we're going to support.

I did get my patch (from c#36) merged, again for the record, so at least some cases of this now print a more informative error message.

(In reply to bcl from comment #39)
> UEFI on msdos labeled disks is not something we're going to support.

Why is that? it is a common case, I think lots of people (most people) still use mbr, gpt is still less common,we need UEFI with mbr (msdos disk label).

Not on UEFI they don't. If they are switching to UEFI they need to reinstall anyway, you can't just plug in the old drive and expect it to work.

(In reply to bcl from comment #42)
> Not on UEFI they don't. If they are switching to UEFI they need to reinstall
> anyway, you can't just plug in the old drive and expect it to work.

You can reinstall on one partition, to switch the drive from msdos to gpt you must wipe it.
I'm not really sure but as far as I remember, lots of new laptops come with UEFI and Windows, but the disk label is msdos, people must have a way to install Fedora (dual boot) without deleting their OS.

There are not 'lots' of laptops like that, no. In fact we don't yet have a confirmed report of *any*, so far as I can remember. The cases where people claimed that's what they had all turned out to be something else on further investigation, IIRC.

This depends what is meant by "comes with UEFI and Windows but the disk label is msdos."  My Dell Latitude E7440 was configured for my institution to have Win7 installed on an MBR disk; nonetheless it "has UEFI" in the sense that you have the option of using any drive you want in UEFI mode with a GPT.  When you do a special boot option, you get the option of booting whatever device in either "Legacy" or UEFI.

It was important for me to install Fedora on the main MBR drive by means of "Legacy" booting the Live media.  If I UEFI booted the Live media then the install fails because the firmware won't allow the two things at once.  You must not have one device running in UEFI while another runs in MBR.

I think we just have to accept that Red Hat does not intend Fedora as a personal desktop OS but rather as an alpha-test platform for RHEL.  Ease of use and installation have steadily declined since F14, and the stripped-down Gnome 3 isn't helping, either.

(In reply to W.C. Epperson from comment #46)
> I think we just have to accept that Red Hat does not intend Fedora as a

Take your snark elsewhere please.

(In reply to Sean A. Fulop from comment #45)
> It was important for me to install Fedora on the main MBR drive by means of
> "Legacy" booting the Live media.  If I UEFI booted the Live media then the
> install fails because the firmware won't allow the two things at once.  You
> must not have one device running in UEFI while another runs in MBR.

Correct, your case isn't what this bug is about. You have a MBR labeled disk and booting in CSM mode will work for you.

There is an actual MBR partition type for the UEFI System Partition, rumor has it that systems exist but we haven't seen a single real one yet, and hopefully never will.

What seems to be common is bios that supports both "legacy" and UEFI.  That is the case with my Lenovo laptop.

What is also common is Windows installed on a MBR formatted hard drive, presumably using legacy boot.  That was how CorpIS installed Windows7 on my laptop.

All I wanted to do is shrink the Windows partition and install Fedora on the other half of the hard drive, to dual boot.  I didn't care if the Fedora install used EFI or legacy, or MBR or GPT.  I just wanted an install that worked.

If Fedora does not want to support UEFI with MBR, even though the spec allows it, then why not do a legacy install when MBR is detected?  OpenSuse installed and boots flawlessly on this configuration.

> Take your snark elsewhere please.

That wasn't snark.  Snark is "I'm going to close as wontfix. Reopen it only if we find large numbers of machines in the wild." when someone reports an Anaconda install problem and it works on a different distro.

There are a couple of different ways to fix this problem.  One would be do a legacy install when MBR is detected.  That's the way old Anaconda with legacy grub would have done it, and why this problem looks like a regression.

Another way would be Fedora to support EFI with MBR.  As documented above, the UEFI spec says "EFI supports MBR and GPT partitioning formats."  It was a design choice by Fedora to not support it.

A third alternative, as a bare minimum, would be for Anaconda to recognize and print out a useful message such as "Fedora chose to not support this configuration.  Try a distro that does."  That would have saved me a lot of time and frustration.

russ: because that's not the way around that things work. The firmware controls whether the system boots in UEFI mode or BIOS/CSM mode. The installer can't control that. Once anaconda is running, it's already decided.

anaconda could, theoretically, start trying to get clever about detecting whether you 'really' want a BIOS mode install, but history has shown that kind of heuristic to be a really bad idea. It never works right, there are always corner cases you didn't consider, and it always breaks in three years when the spec changes.

What we're saying is pretty simple. If you need a BIOS install of Fedora, boot the Fedora installer in BIOS mode. If you need a UEFI install of Fedora, boot the Fedora installer in UEFI mode.

Some firmwares make this easy to achieve, some make it hard and that sucks, but there is only so much an OS installer can sanely do about it. We're sorry about that. Truly we are. It's not like we wake up every morning looking forward to commenting on bug reports like that. But it's not a perfect world and we can't wave a magic wand and fix it so firmwares don't suck, or the world did a clean BIOS -> UEFI transition instead of implementing this whole BIOS compatibility mode mess in the first place. All we can do is try and deal with it.

"There are a couple of different ways to fix this problem.  One would be do a legacy install when MBR is detected.  That's the way old Anaconda with legacy grub would have done it, and why this problem looks like a regression."

No, it wouldn't. anaconda has always tried to do a UEFI native install if you do a UEFI native boot. All that's changed is that there are a lot more systems capable of doing UEFI native boots.

"A third alternative, as a bare minimum, would be for Anaconda to recognize and print out a useful message such as "Fedora chose to not support this configuration.  Try a distro that does."  That would have saved me a lot of time and frustration."

As I mentioned above I did get an improved error message merged which should make this clear, but lately people seem to be hitting some kind of error about not having any primary partitions available or something, which I suspect might get hit 'before' my message. I'd like to look into that, but I have 30 other things to do right now and 20 of them are on fire, so I can't really promise anything.

https://github.com/dwlehman/blivet/commit/c81cbd05a5e29b1c82706fc5a3b09424c087ba0d
https://github.com/dwlehman/blivet/commit/d0527ac76b46c82e50b1707c5443cea3fc3601fc
https://github.com/dwlehman/blivet/commit/34486fef9f6e6b6a7bc0777bc683582742d5d25c

Yet OpenSuse (yast installer) was able to install correctly without changing any BIOS settings.  Both were simply boot the install DVD and point at the partition to install on.  One worked, one didn't.

We've been around that rodeo - extensively - above. Nobody is arguing that that is not the case. It's a choice SUSE made. The anaconda devs are making a different choice. This is a thing that happens - it's why we have different distros in the first place. There are benefits and drawbacks to any of the choices that can be made in this area. We've discussed them all already, I believe.

(In reply to Russ Anderson from comment #53)
> Yet OpenSuse (yast installer) was able to install correctly without changing
> any BIOS settings.  Both were simply boot the install DVD and point at the
> partition to install on.  One worked, one didn't.

Sorry Russ, but I think this again depends on firmware.  I tried OpenSuse install from Live media booted in UEFI, and it failed miserably the same way as Anaconda.  The big difference was that the installer gave a much more helpful error message that helped me discover the nature of the problem.  OpenSuse said something useful like "there is no GPT partition table on the drive, and you are booted in UEFI mode."  Anaconda just gave weird uninterpretable behavior, like claiming that a 40 GB empty partition was actually unusable space.

It sounds as if your firmware allows you to have a UEFI device and a legacy device mounted at the same time.  Mine does not.

(In reply to Russ Anderson from comment #49)
> 
> That wasn't snark.  Snark is "I'm going to close as wontfix. Reopen it only
> if we find large numbers of machines in the wild." when someone reports an
> Anaconda install problem and it works on a different distro.
> 
Thanks.  That quote was an example of the attitude and approach that I was speaking of.  I was offering an honest insight, whether correct or not, and refrained from any ad hominem stuff.

But I'm sorry for any offense taken by BCL.

Today, I went to a computer store, lots of machines were running, and I checked some, about half of them were running Windows 8 on MBR disks, and they all support UEFI, so this is how they are installed from this shop, I think they come with DOS (FreeDOS), and people here install Windows 8 on that, so they don't use gpt.
My point is, even if manufacturers installed Windows on gpt partitions, some laptops (that come without Windows, or Windows is installed by the store itself), support UEFI, and their disks are using gpt.
Support for all of these is important, when I hand a Fedora copy to a friend and he needs to reinstall Windows in order to try Fedora, this is not right.

I also had a Lenoveo, looks like it says it has UEFI but it doesn't (or the implementation is crappy), and noefi doesn't work, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1047904
There is a tricky solution, and convincing my friends (Lenovo too) that this must not happen is hard.
By the way, as far as I remember, openSUSE handles this nicely.

Mustafa: we do support them. You just have to boot the installer in the correct mode.

The theoretical case that's not supported is installing alongside a *native UEFI Windows installation* on an MBR disk. This is the case we say we have never seen. Installing alongside a BIOS-native Windows install on an MBR disk on a UEFI-capable system works fine, as long as you boot the Fedora installer in BIOS native mode.

Here is how the Lenovo bios behaves:

http://www.lenovo.com/images/pdf/server/tech_resources/UEFI_on_TS430.pdf

 During a normal boot, boot options for a device will auto select based
 on the boot record(s) found on the device. For example, if a CD or DVD
 contains a UEFI boot record, the CD/DVD boots using UEFI. If the CD or
 DVD does not contain a UEFI boot record but instead contains an x86 boot
 record, the CD/DVD uses BIOS to boot (via the CSM). If both UEFI and x86
 boot records are found on the device, Legacy BIOS will boot by default.
 This automatic selection behavior can be overridden in the “Boot Options”
 screen (Figure 1) or the “Boot Manager” (Figure 3). Other devices that
 can contain two bootable partitions (MBR and GPT) include diskette
 drives and removable USB drives.

The interesting part is the contents of the CD/DVD determines which way
the CD/DVD is booted.  In my case I installed from DVD.  Maybe that is why
Fedora booted UEFI while SUSE did a legacy bios install???

This is also worth noting:

 A BIOS-bootable operating system can only be installed to a master boot
 record (MBR) partition. An EFI-bootable operating system can only be
 installed to a GPT partition. Therefore, if a selected partition is MBR,
 it is BIOS-booted; if it is GPT, it is EFI-booted.

Well, the second part there is saying what I said above, which you then pointed out isn't strictly true.

The first part says this:

"If both UEFI and x86 boot records are found on the device, Legacy BIOS will boot by default."

that sounds a lot like it's saying a medium that's both UEFI and BIOS bootable - like all Fedora media - should boot in BIOS mode by default, so either you changed some setting or they're wrong about how their own firmware behaves?

(In reply to Adam Williamson (Red Hat) from comment #61)
> Well, the second part there is saying what I said above, which you then
> pointed out isn't strictly true.
> 
> The first part says this:
> 
> "If both UEFI and x86 boot records are found on the device, Legacy BIOS will
> boot by default."
> 
> that sounds a lot like it's saying a medium that's both UEFI and BIOS
> bootable - like all Fedora media - should boot in BIOS mode by default, so
> either you changed some setting or they're wrong about how their own
> firmware behaves?

You are right, "*native UEFI Windows installation* on an MBR disk" is something I don't remember seeing.

I think there should be a clear error message saying something like:
"You booted in UEFI mode, but your hard disk label is msdos (mbr), either reboot into bios mode (legacy mode, or csm) or create a new gpt disk label (wiping your entire disk"

The reason of this bug report is to "Handle case", not to make installation happen, I think a clear messege will be good, and adding buttons for reboot and gparted (or another tool to create gpt disk label) is even better :)

on fedora 21 beta workstation x86_64 live install media, i still get a general error message instead of a proper, informative one:

the message now is that "No valid bootloader target device found. For a UEFI installation ...."

even if i have created /boot. Of course, i've found in BIOS that boot mode was "both EUFI and legacy" but still it took some time to search things over in order to understand what the issue is. if you think the error message is good enough, please leave this closed. if you feel there's room for improvement, please repoen :)

by the way, the above message had to be searched in ctrl-alt-f3, not in anaconda gui.

forgot to mention that the GUI said: fix this or pres done again to continue. after pressing done again and confirming re-creation of various file systems, i ended in the same error, where there was no option to press done again :)

On the other hand, after reading bits of this thread, i've fixed bios settings to legacy only and installer works now. of course, this was after finding a workaround for a parted gui (parted+anaconda crashes if they don't like the already existing partitions: #1161507)

who said linux is boring? :)

"the message now is that "No valid bootloader target device found. For a UEFI installation ....""

The bit you cut out with "..." there explains that you need a /boot/efi formatted as an EFI system partition. Just having /boot is not enough.

this is probably correct, but this is not the expected scenario, that the regular user will switch to a certain text console and parse a log hard to understand, right?

The message is displayed in the GUI, I think when you click on the red bar at the bottom of the Installation Destination screen.

*** Bug 1140025 has been marked as a duplicate of this bug. ***