Bug 1047904

Is there any workaround on this?   Fedora 18 is end of life, so I'm running an unsupported operating system now.

"BIOS: Phoenix SecureCore Tiano Setup V1.10 (which seems to be BIOS-only, no options to choose between BIOS and UEFI)"

If you have to use 'noefi' then your firmware (not BIOS) is precisely the opposite: it is 'UEFI-native only', i.e. it does not give you an option to boot something in BIOS compatibility mode (or it does, but you just haven't found it yet). The fact that you see a 'linuxefi' command in teh bootloader configuration is further confirmation of this: you are *definitely* booting the installer in UEFI-native mode.

noefi is a possible workaround for this, but not really the best one. Though you're the second person to say it's broken, so I should take a look (though it's very unlikely we can change anything to make noefi magically work again for F20 installs).

Ideally you should find how to instruct your firmware to boot something in BIOS compatibility mode. If you really can't figure this out, you can try adding an entry to boot your installation medium in BIOS compat mode using 'efibootmgr'. If you can't figure THAT out, try writing an install medium that just isn't UEFI compatible at all - using 'livecd-iso-to-disk' without the '--efi' parameter will do this, or in a pinch, just wiping the \EFI directory from the medium.

Or, you know, just do a proper UEFI native install - what you need to make it succeed is an EFI system partition, a partition of type 'EFI system partition' with the mount point /boot/efi .

I have just added a patch to F21's installer that prints a more useful error message in this case ("For a UEFI installation, your layout must include an EFI system partition mounted at /boot/efi").

You may find https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ at this point, if you have an hour or two of reading time :)

OK, it looks like the kernel's behaviour changed between F19 and F20, rendering blivet's isEfi() check invalid for this case. It just does:

def isEfi():
    """
    :return: True if the hardware supports EFI, False otherwise.
    :rtype: boolean

    """
    # XXX need to make sure efivars is loaded...
    if os.path.exists("/sys/firmware/efi"):
        return True
    else:
        return False

But on F20 booted with noefi, /sys/firmware/efi does exist, it just has almost nothing in it:

[root@localhost tmp]# ls -R /sys/firmware/efi
/sys/firmware/efi:
efivars  systab

/sys/firmware/efi/efivars:
[root@localhost tmp]# 

On F19 booted with noefi, /sys/firmware/efi does not exist at all. I don't know the reason the kernel's behaviour changed, but it looks like we may need to tweak blivet's isEfi() check a bit.

On current F21, /sys/firmware/efi is even more populated in this case:

[root@localhost liveuser]# ls /sys/firmware/efi/ -R
/sys/firmware/efi/:
config_table  efivars  fw_vendor  runtime  systab

/sys/firmware/efi/efivars:
[root@localhost liveuser]#

It looks like just this would fix it for now:

    # XXX need to make sure efivars is loaded...
    if os.listdir("/sys/firmware/efi/efivars"):
        return True
    else:
        return False

but we might want to ask the kernel folks for a more reliable / Upstream Approved check to use. CCing a kernel folk.

For those who really want to use the noefi workaround on F20 right now, this updates.img should do the trick:

http://www.happyassassin.net/updates/updates-1047904.img

it adjusts anaconda's check as described in c#6. I've tested it, and it works here: if you boot with 'noefi inst.updates=http://www.happyassassin.net/updates/updates-1047904.img' , anaconda will consider you to be doing a BIOS-mode install.

OK, thanks, I'll try it out the coming weekend.

This is ultimately a kernel problem -- it shouldn't break user-space apps. There may also be other things that depend on this.

bcl: well, I don't know if the kernel has exactly declared "the existence of /sys/firmware/efi is a reliable indicator of whether the system is booted in UEFI mode or not" as part of its API, has it? That's why I wasn't sure whether the kernel was wrong to change this, or whether it's up to blivet to make sure its check works.

If the kernel folks have an Officially Approved Method of determining this status, that would obviously be the best thing for everyone.

The kernel's behaviour has changed, but this is arguably a good thing. The right thing for Anaconda to do in the noefi case is to do an EFI install - noefi changes the behaviour of the kernel, not the firmware, and we're installing something that the firmware has to boot. noefi means we can't set any boot variables, but we can still install the efi fallback loader. So, arguably:

1) /sys/firmware/efi doesn't exist: system booted via BIOS, Anaconda should install a BIOS bootloader
2) /sys/firmware/efi exists but is empty: system booted via EFI with noefi passed. Anaconda should install the fallback EFI bootloader and skip configuring boot variables
3) /sys/firmware/efi exists and is populated: system booted via EFI. Anaconda should install the EFI bootloader and configure boot variables.

Sounds reasonable, note comment 5, /sys/firmware/efi/ is populated, but /sys/firmware/efi/efivars/ is empty. Is that a good indicator of the state of things?

Yes, that sounds right.

"The right thing for Anaconda to do in the noefi case is to do an EFI install"

I don't want to dispute this with mjg59, but if I may, I'd just respectfully note than in the Real World, people are already telling each other to 'just use noefi' if they want to do a BIOS compat mode install on a UEFI system and don't want to / can't figure out how to boot the install media in BIOS native mode.

What would be the actual use case for the behaviour you describe? (Genuine question, not snark - I wish to know). Who would want to boot in UEFI native mode, pass 'noefi', and have the installer do what you suggest?

(I found this bug and investigated it as a result of two different people complaining that noefi "didn't work" in F20, in the sense that they expected it to do a BIOS-type install but it didn't).

The system performed a UEFI boot. We have no guarantee whatsoever that the system even has a CSM. Since we know the system can boot via UEFI, we should do a UEFI install. The alternative is to risk leaving the system in a broken state.

noefi is there to prevent the kernel from performing runtime UEFI calls. You might want to do that because of various kinds of breakage in your firmware or the kernel. It doesn't necessarily follow that you want a BIOS bootloader.

Yeah, I thought of the 'no CSM' case right after posting that comment.

Does it still really make sense to do a UEFI fallback install, though? Alternatively, couldn't we just say 'noefi does not mean what you think it means. Go and boot without it, you silly person', or something? It's the idea that we should just go ahead and do a UEFI native install using the fallback path that's kinda sticking in my craw, because I'm not entirely sure that's what people are actually expecting if they pass 'noefi' to the installer.

Given that people are currently using it to do BIOS installs, I kinda feel like it might be safer to just make this 'not supported behaviour' and just bail out with an error message telling them what they probably really wanted to do, or something.

Can you think of an actual use case for the noefi path you describe, or were you just considering what the most sensible possible behaviour would be *assuming we actually wanted to perform an install* in that case?

The use case is as I described - runtime UEFI calls don't work on the system.

Hm, yeah, I guess you could wind up in that case in some way other than passing 'noefi'.

I guess we could actually check the cmdline for 'noefi' and at least warn about what that will actually result in the installer doing, but I may be just worrying too much.

It's very early, but I'm marking this as ReleaseNotes so I don't forget about it for next release - we should do something to let people know that 'noefi' is not a short-cut to a BIOS-mode install, and the fact that it used to be was not by design.

Just my 2 cents, to explain the background (this is all my view on it, I know very little about UEFI apart from the very few things I read while trying to solve this problem).

The way I got into this situation is because when I installed Fedora 18 a year ago, it didn't work either at first, giving me the following error:

you have not created a bootloader stage1 target device
sda must have a gpt disk label

Since the laptop came with Windows 7 installed on a MBR-style partitioned disk, and I didn't want to lose the Windows 7 installation, I couldn't just repartition the disk in GPT-style.   I found eventually (after long searching on the web) that I could circumvent that by passing 'noefi' on the command line.

So for me the 'noefi' option means: yes, that's an MBR-style partitioned disk, please install on it and boot from it.   Without the option that doesn't work on this laptop.  Only now for Fedora 20 it isn't even working with the option.

That's not an easy case to handle. We have no idea whether the disk in a system is bootable, so we can't assume that just because there's an MBR-labelled disk with a BIOS bootloader that the system is capable of booting it.

The problem is that you're booting via UEFI and then attempting to install onto a disk that's booting via BIOS. The correct thing to do is to boot via BIOS instead, but without seeing your system there's no way for me to know how you do that.

If what you want is "Do a BIOS-based install no matter how I booted", noefi isn't the way to achieve that. We could add an additional argument to Anaconda that did this. It would be a workaround and it would break things if used in the wrong circumstances, but it appears to be what you're asking for in this case.

I can confirm that the workaround using the updates-1047904.img works for me.   Thanks!

As far as I see, I really have no choice at boot between UEFI and BIOS.   I'm attaching screenshots of the Phoenix SecureCore boot screens.

Created attachment 858310 [details]
Phoenix SecureCore setup, information page

Created attachment 858311 [details]
Phoenix SecureCore setup, main page

Created attachment 858312 [details]
Phoenix SecureCore setup, security page

Created attachment 858313 [details]
Phoenix SecureCore setup, boot page

Are those with the Fedora installer DVD/USB stick/whatever attached? The one that boots in UEFI mode if you 'just go ahead and boot it'? But this system has a BIOS-native install of Windows on it?

(this isn't 100% entirely on-topic, but I *am* interested in seeing real-world examples of idiotic firmwares...)

Man, Acer deserves some kind of booby prize: their firmware updates come with no kind of changelog or, you know, useful information of any sort. When I look at the support site for your laptop, I see a 1.22 firmware, a 2.17 version described as "BIOS - UEFI for Windows 8 (Not for Upgrades)", and a 2.18 version which has a changelog crammed into the description. That hardly makes it clear whether you can/should install the 2.xx version on your system :/ and it also doesn't provide us with any useful hints about its capabilities at *all*.

My very rough guess is they did earlier shipments of this model with a BIOS Windows 7 install and the 1.xx series firmware, and later shipments with a UEFI Windows 8 install and the 2.xx series firmware, and perhaps the 1.xx series firmware is supposed to just use BIOS compatibility mode but has some kind of bug where it boots UEFI-capable removable media in UEFI native mode and because the UI is expecting it to just use BIOS compat mode, there is no way to stop it doing that. Which would, of course, be complete idiocy on Acer's part, but hardly the first time we've seen firmware idiocy. But that is just a guess based on incomplete information ATM.

Google results indicate the 2.xx firmware does have BIOS compat boot options, and so you may *possibly* be able to update to the 2.xx firmware and still boot your BIOS Windows installation and then get a BIOS Fedora install done using the extra options it gives you, but I certainly wouldn't guarantee that in any way at all, I'm still guessing.

Regarding your question: yes, that's correct.  The Fedora installer DVD boots it in UEFI mode apparently, but indeed it has a BIOS-native install of Windows on it.

A quote from here:
http://www.bios-mods.com/forum/Thread-Request-Acer-Aspire-V3-571G-unlock-and-Update-to-UEFI

"You can't upgrade from 1.x to 2.x. You know Acer specifically states 1.x is for their Laptops that were manufactured with Windows 7, and 2.x is for their Laptops that were manufactured with Windows 8 at start. It doesn't matter if you upgrade to Windows 8 from 7, you won't be able to install 2.x Bios on your laptop. I have no idea why, and I wish I can help. No one has released an unlocked bios. Maybe it's not possible, or takes to much hard work."

I haven't found an official Acer page to back that statement though.  Further on in that thread, somebody actually tried it anyway, but ran into trouble, so I'm not going to attempt that...

Everything I read so far leads me to the conclusion that I should have bought a different laptop ;-)

Ug, well that's just terrible :/

You might try the 1.22 update at least; perhaps somewhere between 1.10 and 1.22 they fixed it to boot UEFI-capable media in BIOS compat mode, which really is the *only* sensible thing to do if the system has a BIOS OS on it already and they're not going to give the user a choice.

OK, I'll have a go at that.

There's this also:
http://catchtito.blogspot.be/2013/05/how-to-update-to-2x-bios-from-1x-bios.html

but I'm not really adventurous...

yeah, I really wouldn't want to advise you to get too heroic with firmware messing about. you certainly can get in a lot of trouble. for now, your situation seems like an appropriate one in which to use the 'noefi' trick with my updates.img , indeed. for future Fedoras, if BIOS 1.22 doesn't fix it, you may have to try the trick of writing the installer to a USB stick in such a way that it's not UEFI bootable - e.g. by using livecd-iso-to-disk without passing --efi .

This doesn't work.  It asks for the URLs for the install repos and can't find them, nor the install ISO which it just booted from.

Anaconda is broken.  It fails and there is no way to bypass the stupidity.  I manually formatted a new ext4, but can't get it to install there, it just getst permanently stuck.  I can't install Fedora.  Why do you force things to be broken if the conditions aren't perfect.

And apparently the stupidity continues as there is now no way to manually just install to a known area of the disk.

Fedora is getting as bad as Ubuntu.

(In reply to Adam Williamson from comment #8)
> For those who really want to use the noefi workaround on F20 right now, this
> updates.img should do the trick:
> 
> http://www.happyassassin.net/updates/updates-1047904.img
> 
> it adjusts anaconda's check as described in c#6. I've tested it, and it
> works here: if you boot with 'noefi
> inst.updates=http://www.happyassassin.net/updates/updates-1047904.img' ,
> anaconda will consider you to be doing a BIOS-mode install.

"It asks for the URLs for the install repos and can't find them, nor the install ISO which it just booted from."

That has nothing to do with this bug. I'm going to ignore the rest of your rant, as there's nothing useful in it.

Hi! I encountered the same issue on my Asus R252B (also known as 1225b) with American Megatrends Aptio BIOS (firmware version 207) when I unsuccessfully attempted to install Fedora 20 64-bit. My laptop shipped with Windows 7 64-Bit(which I intend to keep in a dual boot manner), but a Windows 8 version is available as well. My BIOS has no option to switch between UEFI or Legacy mode either, Win 7 boots in BIOS mode (I checked C:\Windows\Panther\setupact.log), and I have MBR on my single HDD. So I believe that it is safe to assume that my computer would not support any UEFI operating system. I used the Fedora LiveUSB Creator utility, so I had no option to choose BIOS mode before I found this fix, which I will try later. I have also noticed that despite all this, I do have a hidden 16 MB EFI partition at the end of my hard drive, of unknown origin, and the Fedora Live USB is listed in my boot order as 'UEFI: Fedora Live', both of which seem quite odd to me. (The UEFI Fedora and my HDD are the only possible boot entries, so there isn't any option to change there either.)

leperspells: you need to find a way to get the firmware to boot the Fedora USB in BIOS mode, not UEFI mode (and you should also complain to Asus, because shipping a system with a BIOS-native OS but configured to boot USB sticks in UEFI mode by default is awful design). If the firmware doesn't offer you the option, you'll have to create a stick that's not capable of UEFI booting, and that should work around the problem; https://fedoraproject.org/wiki/Unified_Extensible_Firmware_Interface#Booting_the_Fedora_installer_or_live_image_in_UEFI-native_and_BIOS-native_modes has some suggestions.

(In reply to Adam Williamson (Red Hat) from comment #39)
Thank you, Adam! I will try writing a bootable media with one of those methods. Still, I hope that future distributions will improve their recognition and handling of this problem.  I completely agree that Asus is also at fault here, especially as they failed to supply any documentation on the BIOS matter. I'll try asking them, but lacking a local dealer, I don't have high hopes for their customer support.

Sorry for the noise, ends up the thing to do here is just skip running efibootmgr when noefi is on the cmdline so that's purely an anaconda change.

comment 12 is how things will work as of anaconda 22.9

Just to be clear for those who come later and don't want to read the whole thread:

noefi is NOT how you make Anaconda do a BIOS installation. You need to switch your firmware to boot in CSM mode.

All this fix does is skip running efibootmgr when noefi is passed.