Bug 975537

Created attachment 762579 [details]
File: anaconda-tb

Created attachment 762580 [details]
File: anaconda.log

Created attachment 762581 [details]
File: backtrace

Created attachment 762582 [details]
File: environ

Created attachment 762583 [details]
File: ifcfg.log

Created attachment 762584 [details]
File: lsblk_output

Created attachment 762585 [details]
File: messages

Created attachment 762586 [details]
File: nmcli_dev_list

Created attachment 762587 [details]
File: packaging.log

Created attachment 762588 [details]
File: program.log

Created attachment 762589 [details]
File: storage.log

Original report based on Fedora-Live-Desktop-x86_64-19-Beta-1.iso
Is reproducible with Fedora-Live-Desktop-x86_64-19-TC5-1.iso

Component:
anaconda-19.30-8.1


Steps to reproduce:

1. Clear the NVRAM (as this is a Mac, it's easily done on startup with command-option-P-R).
2. Install TC5 = success.
3. Reboot installer, install TC 5 again, via guided partitioning and using Reclaim Space to select and delete all F19 partitions. Begin install.

Result:
At installing boot loader, crash. The installed system is not bootable.

Expected:
No crash. Proper installation of boot loader.

Additional info:
Attaching latest anaconda-tb

dmesg | grep efivars
[  390.883695] efivars: DataSize & Attributes must be valid!

[root@localhost tmp]# cat program.log | grep efibootmgr
15:31:42,425 INFO program: Running... efibootmgr
15:31:42,471 INFO program: Running... efibootmgr -b 0000 -B
[root@localhost tmp]# efibootmgr -v
BootCurrent: 0000
BootOrder: 0000
BootFFFF* 	ACPI(a0341d0,0)PCI(1d,0)USB(0,0)HD(3,2774,26a00,None)File(\EFI\BOOT\grubx64.efi)


Why is anaconda asking for the removal of 0000 instead of FFFF?

[root@localhost tmp]# efibootmgr -b 0000 -B
boot entry: 0 not found

Whereas:
[root@localhost tmp]# efibootmgr -b FFFF -B
BootCurrent: 0000
BootOrder: 0000


Proposing as a blocker based on beta criterion:"When using the guided partitioning flow, the installer must be able to:Reject or disallow invalid disk and volume configurations without crashing.

And also alpha criterion:"A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation."

Created attachment 762610 [details]
anacond-tb, anaconda 18.30.8-1

Created attachment 762611 [details]
program.log, anaconda 18.30.8-1

OK so after a clean installation of TC5, efibootmgr -v looks like this:

BootCurrent: 0000
BootOrder: 0000
Boot0000* Fedora	HD(4,302b000,64000,9e26fd9f-fb88-4b4b-b958-7705dd15c2a1)File(\EFI\fedora\shim.efi)
BootFFFF* 	ACPI(a0341d0,0)PCI(1d,0)USB(0,0)HD(3,2774,26a00,None)File(\EFI\BOOT\grubx64.efi)

So the reproducer for this bug is to clean install F19 on a UEFI Mac then re-install immediately over the top of it, yes?

Matt, Peter, any ideas?

Correct. Every other installation attempt fails, if I just go with defaults. So the first install attempt works, the 2nd install attempt fails, 3rd install attempt works, 4th attempt fails, etc.

And it's reproducible on three totally different Mac models. I don't have non-Apple UEFI to test, so I wonder if this is a regression that might affect non-Macs.

This is reproducible in VirtualBox EFI mode by first applying a successful install's efibootmgr -c command, to restore the entry lost since VirtualBox's fake NVRAM is actually volatile.

However, abrt thinks it's a duplicate of bug 947142, which seems bogus because ENOSPC doesn't seem to apply in this case (with three real NVRAMs resently cleared, and one that isn't persistent on reboots)

The crash is on anaconda, but I'm wondering if this is actually an efibootmgr bug?

Weird that the status/assignee changed.

I've just done several UEFI installs in a row to my Asus motherboard-based desktop from various F19 Final TC5 install media, and did not hit any failures at the bootloader install stage.

I tried to install Live TC5 over previously existing installation on Mac mini and then again, all defaults. I didn't encounter any problem.

# efibootmgr -v
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000,0080
Boot0000* Fedora	HD(1,800,64000,0fca38e3-1e3a-46a1-ba91-7f95ce7711f4)File(\EFI\fedora\shim.efi)
Boot0080* 	ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(2,64028,3a1ec0c0,00002421-6ff9-0000-8653-0000d3570000)File(\System\Library\CoreServices\boot.efi)
BootFFFF* 	ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(2,64028,3a1ec0c0,00002421-6ff9-0000-8653-0000d3570000)File(\System\Library\CoreServices\boot.efi)

Discussed at 2013-06-19 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19final-blocker-review-7.2013-06-19-16.01.log.txt . So far testing indicates this bug affects *some* Macs, half of the time. We felt this wasn't a wide enough impact to merit blocker status, so it's rejected as a blocker, but accepted as a freeze exception issue as we should fix it if we can. If we don't fix it, we should document the 'just try again' workaround.

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

To be fair, it's not just Macs, it's also reproducible with Virtual Box UEFI. It's also reproducible with Fedora-18-x86_64-Live-Desktop.iso on the same hardware, so at least it's not a regression.

Doubtful this is an anaconda bug, except possibly the crashing part. I think this is related to these and maybe others:
bug 971158
bug 909944
bug 922275
bug 947142
bug 952644

What I can vouch for in my cases is that NVRAM is pretty clean (VirtualBox's isn't persistent across reboots, all I have to do to reproduce is add a Fedora boot entry for anaconda to try and remove to trigger the crash); and ostensibly Mac NVRAM is as clear as it can be upon "zapping PRAM" with command-option-P-R; and all that's being attempted is a removal of an entry rather than modification or creation.

The latest reproducer is with kernel 3.9.5-301.fc19 and efibootmgr-0.5.4-15.fc19.

Re-assigning to kernel for now. It's probably mjg59 and pjones we need to look at this one, though.

Chris: anaconda isn't really 'crashing', exactly, it's just intentionally written to halt when the efibootmgr command returns fail so that you can report a bug.

Created attachment 763583 [details]
efibootmgr error

I am seeing this on a non-mac EFI system. After I manually removed a couple entries I also got this related traceback when it tried to add the new entry.

Is there a way for anaconda to just report the failure to modify NVRAM (be it remove, create, or modify), or must this necessarily be a catastrophic failure? 

(In reply to Brian C. Lane from comment #28)
I see in the attachment that NVRAM contains 21 entries. That's a lot so I wonder if this instance is a case of ENOSPC? The firmware isn't garbage collecting the removed entries and thus fails to add a new entry.

Anyway, I wonder about any dependency on NVRAM contents. Apple's been doing this for 20+ years with CMOS and NVRAM, and even with their control of hardware and kernel they don't trust it much farther than they can throw it: it only contains convenient information, nothing that's required to boot the system, and they make it easy to reset yet still have a bootable (default) OS X system.

Is there any uniformity in behavior of UEFI systems executing /EFI/BOOT/BOOX64.EFI when NVRAM is completely devoid of entries?

"Is there a way for anaconda to just report the failure to modify NVRAM (be it remove, create, or modify), or must this necessarily be a catastrophic failure?"

I was wondering if we might get more information about failures if we stuck a -v in the efibootmgr commands. Right now it appears that all we get is an exit code.

"Is there any uniformity in behavior of UEFI systems executing /EFI/BOOT/BOOX64.EFI when NVRAM is completely devoid of entries?"

Well, we have https://bugzilla.redhat.com/show_bug.cgi?id=963359 for that, I think.

Created attachment 763652 [details]
dmesg.log oops cat'ing /sys/firmware/efi/efivars

(In reply to Adam Williamson from comment #30)
> I was wondering if we might get more information about failures if we stuck
> a -v in the efibootmgr commands. Right now it appears that all we get is an
> exit code.

I get:
efivars: DataSize & Attributes must be valid!

Which is also what's reported in dmesg if -v isn't used. However, without -v there's no error in dmesg. And, with or without the error, the entry appears to be removed. A subsequent efibootmgr -v listing lacks the removed entry. So I'm not sure what the error even means.

When I go to /sys/firmware/efi/efivars, I still see the remove Boot0000 entry, when I cat it, I get an oops. Attached dmesg with oops.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

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

This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

I'm seeing this on  ibm-hs22-03.rhts.eng.brq.redhat.com with Fedora 19 (will re-test with newer releases). 


Performing post-installation setup tasks 

Installing bootloader 

** (anaconda:1038): WARNING **: Could not open X display 
      
An unknown error has occured, look at the /tmp/anaconda-tb* file(s) for more details 

=============================================================================== 
An unknown error has occurred 
=============================================================================== 
anaconda 19.30.13-1 exception report 
Traceback (most recent call first): 
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1653, in remove_efi_boot_target 
    raise BootLoaderError("failed to remove old efi boot entry") 
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1681, in install 
    self.remove_efi_boot_target() 
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1701, in write 
    self.install() 
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2358, in writeBootLoader 
      
    storage.bootloader.write() 
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 171, in doInstall 
    writeBootLoader(storage, payload, instClass, ksdata) 
  File "/usr/lib64/python2.7/threading.py", line 764, in run 
    self.__target(*self.__args, **self.__kwargs) 
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run 
    threading.Thread.run(self, *args, **kwargs) 
BootLoaderError: failed to remove old efi boot entry 

What do you want to do now? 
1) Report Bug 
2) Debug 
3) Quit 
      
Please make your choice from above:

Possible duplicate or related bugs: 

# 909944
# 866028
# 1006304

(In reply to Alexander Todorov from comment #35)
> I'm seeing this on  ibm-hs22-03.rhts.eng.brq.redhat.com with Fedora 19 (will
> re-test with newer releases). 

We can't fix old install media.  Unless it's happening with 3.11.y on F20, there's nothing we can do here.

Also, the basic error message here - 'failed to remove old efi boot entry' - is a _fairly_ generic one. There can be various reasons why it could happen. If you have some kind of reproducible occurrence of it, it'd be useful to look through the logs (particularly program.log) and see if you can see any more detail as to why it's happening, and then take appropriate action: see if it's really a dupe of this, if it's a valid bug but caused by something that's obviously not the same cause as this bug, or if it's not really a bug but just somehow caused by your system's UEFI config.

I tried to install fedora alongside windows 8, both uefi.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/syslinux/vmlinuz inst.stage2=hd:UUID=9AAE-3B53 quiet
hashmarkername: anaconda
kernel:         3.11.5-302.fc20.x86_64
package:        anaconda-20.25.1-1
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Cannot get release name.
version:        20-Beta-TC5

pschindl: can you attach your program.log ?

anaconda maintainers: perhaps you could figure out a way with the libreport maintainers of not having every 'failed to remove old efi boot entry' bug filed as a dupe of this? I don't think they're often likely to actually be dupes.

And the result from "efibootmgr -v" please.

Just attempted to recreate this with F20 Beta and the installation went through fine. The output of "efibootmgr -v":

BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0002,0000,0001
Boot0000* CD/DVD Drive	BIOS(3,0,00)
Boot0001* Hard Drive	BIOS(2,0,00)
Boot0002* Fedora	HD(1,800,64000,d1b40766-15b4-4b19-aa3a-74fd5a907c83)File(\EFI\fedora\shim.efi)

This bug is happening again with 3.11.8, it wasn't happening with 3.11.7 or older. Bug 1033354. Since this bug is F19 and the new bug is F20, I'm not marking either of them as dups.

Happens during the standard installation on UEFI system. Win7SP1 is installed in dualboot sharing the same EFI partition.

I don't even care about efi records, my laptom doesn't use them anyway.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-20-1 ro rd.live.image quiet rhgb
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
other involved packages: python-libs-2.7.5-9.fc20.x86_64
package:        anaconda-20.25.15-1.fc20.x86_64
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Fedora release 20 (Heisenbug)
version:        20

If you hit this error, we really need you to get at program.log from the installation somehow - before rebooting from the installer, it's in /tmp , on the installed system it should be in /var/log/anaconda but perhaps not if the install failed. It will contain the actual error from efibootmgr. We cannot figure out what's happening to you without the log, unfortunately.

(and anaconda/libreport devs, please do look at c#41...)

Unfortunately, I couldn't find the logs from that last attempt, but I made a new one, and I removed all the EFI records manually before starting the setup. So now I see this:

[liveuser@localhost ~]$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds

The setup stil fails, now with

BootLoaderError: failed to set new efi boot target

The last lines from program.log are

15:54:43,708 INFO program: Running... efibootmgr
15:54:43,731 INFO program: BootCurrent: 0000
15:54:43,731 INFO program: Timeout: 0 seconds
15:54:43,731 DEBUG program: Return code: 0
15:54:43,732 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi
15:54:43,792 DEBUG program: Return code: 1
15:54:43,847 INFO program: Running... journalctl -b

If I try to run the command manually - it indeed returns 1 (quietly):

[liveuser@localhost ~]$ sudo efibootmgr -v -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi
[liveuser@localhost ~]$ echo $?
1

Have a question: does the setup do anything after this? provided I can boot the system even without this, what else should I do in order to get a fully installed system?

I think bootloader installation is pretty close to the last thing it does. Should probably work OK if you manage to set up a bootloader entry pointing to the  right thing somehow or other.

My laptop allows to just choose which EFI file to boot from, so it's not an issue in my case.

Anyway, after reboot the efibootmgr worked OK. Whatever it was, it was probably kernel and/or BIOS problem. Only the -c flag didn't work. At the same time I could remove f.i. the "timeout" flag (efibootmgr -T), so it's probably something different from the original issue anyway.

And I think it's a BIG PROBLEM that anaconda doesn't provide a button "continue setup anyway" in case of this failure. Ok, I got it, efivars are screwed, I know how to deal with it, just finish the setup pleeeeease.

(In reply to Radist Morse from comment #49)
> Ok, I got it, efivars are
> screwed, I know how to deal with it, just finish the setup pleeeeease.

Seems reasonable. I suggest opening a new bug against anaconda/rawhide, with bug title starting with RFE. The other reason it doesn't make much sense to totally fail is by choosing \fedora\shim.efi from your firmware's UEFI boot manager, it will add an NVRAM entry for itself (it does at least on my Mac and in VBox UEFI).

"Seems reasonable."

I'm not entirely sure it is - the basic design of anaconda is to fail with data any time we're not very sure we're succeeding, because installation is a very important process and trying to hide errors and muddle through regardless is an approach that historically has not proven to be a very good choice. It may be reasonable to make exceptions in specific situations, but it's worth bearing this design in mind.

(In reply to Adam Williamson from comment #51)
True and it seems as a prerequisite for the suggested RFE, we need c41 addressed such that there's better reporting granularity in order to know whether an exception case could safely be made while also capturing failure information so the problem is better understood.

But this bug is currently set to kernel, not anaconda.

(In reply to Adam Williamson from comment #51)
> the basic design of anaconda is to fail with data any time we're not
> very sure we're succeeding

The problem here as I see it is that there are lots of buggy BIOSes out there, which treat efivars quite unexpectedly (maybe it's because UEFI is still young). F.i. my laptop (HP elitebook 8760w) will always boot MS windows if it finds it's efi loader, regardless of what is written in efivars, so I have to invent a really tricky setup to hide MS efi loaders from BIOS when I don't need them.

Point is, the failure of efibootmgr could easily be caused by BIOS, which means that it can't be fixed by any upstream, which will make fedora uninstallable on such devices.

Error message during normal installation of F20. 

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 quiet
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Cannot get release name.
version:        20

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.13.5-100.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

New SSD, system never had Fedora installed, but identical to past install systems.


cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 quiet
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Cannot get release name.
version:        20

Robert: did you save the install logs? if you haven't wiped the system since, they should still be there in /var/log/anaconda, you can get 'em out by mounting it from a live image or something. we'd need to see program.log. thanks!

second attempt to get logs per request

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 quiet
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Cannot get release name.
version:        20

Since it's crashing they probably aren't being moved to /var/log on the installed system; but are in /tmp while still booted with install media. If there's a tb file, that's most useful because it'll contain everything. Try:
fpaste <anacondatbfilename>
If it's not too big for fpaste, that's an easy way to get it out of the system. The command returns a URL which you can post here. If it's too big it'll complain, in the case either fpaste program.log or copy the tb file to a USB stick and attach it to this bug.

oh, doh, you're right, I forgot it was crashing...do what chris says.

Created attachment 901001 [details]
/root/anaconda-tb-pwnbs4 from lastest failure

anaconda-tb-pwnbs4 from latest failure per request.

21:01:26,852 INFO program: Running... efibootmgr -b 000B -B
21:01:26,901 WARNING kernel:[ 2048.009467] efivars: set_variable() failed: status=-28

So it's the same instigator, removing the existing Fedora boot entry, but different kernel error. Since this can't be fixed in the Fedora 20 installer, best to check Rawhide. There ought to be two fixes, one hopefully the kernel has a fix so the problem doesn't happen in the first place, but if it still does I think the idea for anaconda 21 is to clear/set NVRAM on UEFI before modifying the drive.

attempted to install F20 x64 on a hp zbook 17 with BIOS v1.10 in UEFI secure boot mode. Did an ATA Secure Erase of the SSD before beginning the install.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-20-1 ro rd.live.image quiet rhgb rd.live.check
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
other involved packages: python-libs-2.7.5-9.fc20.x86_64
package:        anaconda-20.25.15-1.fc20.x86_64
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Fedora release 20 (Heisenbug)
version:        20

I tried again, this time running Secure Erase from the BIOS (it's an option on these HP Z workstations).

Ran through the f20 install again, exactly the same way as I had before (except for the secure erase steps) and it worked perfectly.


(In reply to patrick korsnick from comment #63)
> attempted to install F20 x64 on a hp zbook 17 with BIOS v1.10 in UEFI secure
> boot mode. Did an ATA Secure Erase of the SSD before beginning the install.
> 
> cmdline:        /usr/bin/python  /sbin/anaconda --liveinst
> --method=livecd:///dev/mapper/live-base
> cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0
> root=live:LABEL=Fedora-Live-Desktop-x86_64-20-1 ro rd.live.image quiet rhgb
> rd.live.check
> hashmarkername: anaconda
> kernel:         3.11.10-301.fc20.x86_64
> other involved packages: python-libs-2.7.5-9.fc20.x86_64
> package:        anaconda-20.25.15-1.fc20.x86_64
> product:        Fedora
> reason:         BootLoaderError: failed to remove old efi boot entry
> release:        Fedora release 20 (Heisenbug)
> version:        20

tried to install from f20 netinstall  usb stick in uefi mode with secure boot enabled

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 nomodeset
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Cannot get release name.
version:        20

Another user experienced a similar problem:

tried to install via 20140801 live desk respin and got this error again.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=F20-x86_64-LIVE-DESK-20140801 ro rd.live.image quiet rhgb nomodeset
hashmarkername: anaconda
kernel:         3.15.6-200.fc20.x86_64
other involved packages: python-libs-2.7.5-13.fc20.x86_64
package:        anaconda-20.25.16-1.fc20.x86_64
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Fedora release 20 (Heisenbug)
version:        20

(In reply to patrick korsnick from comment #66)
> package:        anaconda-20.25.16-1.fc20.x86_64

This version of the installer doesn't have a fallback position when efibootmgr via the kernel fails to modify NVRAM. It just crashes/fails to complete, so post-install scripts also fail to complete.

It's worth testing with a current build of Fedora 21 (pre-release) because the post-install scripts including grub.cfg are now written even if NVRAM modify fails, this is since anaconda-21.48.1-1.

Another option is to track down a program.log for a successful UEFI install and figure out what post-install things need to be done to your system to make it functional; 99% of the install worked, it's just the very tail end that didn't. You'll need an /etc/default/grub from a successful install, and the following commands run in a chroot for the installed system:

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
authconfig --update --nostart --enableshadow --passalgo=sha512 --enablefingerprint
systemctl enable initial-setup-graphical.service initial-setup-text.service
firewall-offline-cmd --enabled --service=ssh
hostnamectl set-hostname <hostname>.localdomain
new-kernel-pkg --mkinitrd --dracut --depmod --update <kernelversion>

Created attachment 925886 [details]
program.log

Created attachment 925888 [details]
anaconda traceback

OK interesting. Two different install attempts, two different kinds of failures:
19:35:45,598 INFO program: Running... efibootmgr -b 0000 -B
19:35:45,617 DEBUG program: Return code: 1

traceback:
20:02:27,703 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi
20:02:27,720 DEBUG program: Return code: 1

Whether removing or adding an entry, the kernel or firmware barfs.

Can you include dmesg from the failed installation? The traceback has journalctl output but it ends before the efibootmgr failure (weird).

Created attachment 925900 [details]
program.log from attempt 3 using 20140801 live desk respin

Created attachment 925901 [details]
anaconda traceback from attempt #3

Created attachment 925902 [details]
dmesg output from attempt #3

(In reply to patrick korsnick from comment #73)
Since 3.15.6-200.fc20.x86_64, changing to 20. Unfortunately there's no information in dmesg about why efibootmgr failed though, and that in itself seems to be a problem.

Created attachment 926941 [details]
dmesg output showing efibootmanager segfault

looks like efibootmanager segfaulted. gonna try again but with coredumps enabled and see if i can get a core

Good idea. I'd file a new bug against efibootmgr. And may be considered nominatable for F21 final blocker. cc me on that bug.

I tried using the Fedora-20-x86_64-DVD.iso to install and this time the install completed without error. However on reboot I was unable to boot up with secure boot enabled- says "bootloader has not verified loaded image" and machine shuts down.

(In reply to patrick korsnick from comment #77)
That's a different problem, not a kernel bug. See:
https://ask.fedoraproject.org/en/question/39126/bootloader-has-not-verified-loaded-image/
If the install media can boot in Secure Boot mode without this message, and yet an unmodified clean install (you have not run grub2-install, or anything that replaces grubx64.efi from the installed copy) produces this message, I'd file a new bug against grub2.

tried to install from fedora 20 DVD to zbook 17 in EFI mode with secure boot enabled. had done a secure erase before beginning the install

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 quiet
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to remove old efi boot entry
release:        Cannot get release name.
version:        20

(In reply to Chris Murphy from comment #78)
> (In reply to patrick korsnick from comment #77)
> That's a different problem, not a kernel bug. See:
> https://ask.fedoraproject.org/en/question/39126/bootloader-has-not-verified-
> loaded-image/
> If the install media can boot in Secure Boot mode without this message, and
> yet an unmodified clean install (you have not run grub2-install, or anything
> that replaces grubx64.efi from the installed copy) produces this message,
> I'd file a new bug against grub2.

Bug filed against grub2 1132309

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.