Bug 975537 - BootLoaderError: failed to remove old efi boot entry [NEEDINFO]
Summary: BootLoaderError: failed to remove old efi boot entry
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:55cf9399562c4d739015b39a2d5...
: 976093 1010203 (view as bug list)
Depends On:
Blocks: F19-accepted, F19FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2013-06-18 17:49 UTC by Chris Murphy
Modified: 2015-05-25 11:14 UTC (History)
32 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-10 14:57:41 UTC
Type: ---
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)
File: anaconda-tb (678.96 KB, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: anaconda.log (13.96 KB, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: backtrace (1.12 KB, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: environ (769 bytes, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: ifcfg.log (486 bytes, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: lsblk_output (3.77 KB, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: messages (277.61 KB, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: nmcli_dev_list (3.44 KB, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: packaging.log (201 bytes, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: program.log (62.07 KB, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
File: storage.log (307.88 KB, text/plain)
2013-06-18 17:49 UTC, Chris Murphy
no flags Details
anacond-tb, anaconda 18.30.8-1 (580.58 KB, text/plain)
2013-06-18 19:39 UTC, Chris Murphy
no flags Details
program.log, anaconda 18.30.8-1 (44.01 KB, text/plain)
2013-06-18 19:40 UTC, Chris Murphy
no flags Details
efibootmgr error (1.39 MB, text/plain)
2013-06-20 20:45 UTC, Brian Lane
no flags Details
dmesg.log oops cat'ing /sys/firmware/efi/efivars (96.77 KB, text/plain)
2013-06-21 05:31 UTC, Chris Murphy
no flags Details
/root/anaconda-tb-pwnbs4 from lastest failure (1.21 MB, text/plain)
2014-05-30 21:59 UTC, Robert Moskowitz
no flags Details
program.log (33.87 KB, text/plain)
2014-08-11 23:50 UTC, patrick korsnick
no flags Details
anaconda traceback (873.75 KB, text/plain)
2014-08-12 00:09 UTC, patrick korsnick
no flags Details
program.log from attempt 3 using 20140801 live desk respin (33.72 KB, text/x-log)
2014-08-12 03:33 UTC, patrick korsnick
no flags Details
anaconda traceback from attempt #3 (872.84 KB, text/plain)
2014-08-12 03:34 UTC, patrick korsnick
no flags Details
dmesg output from attempt #3 (85.73 KB, text/plain)
2014-08-12 03:35 UTC, patrick korsnick
no flags Details
dmesg output showing efibootmanager segfault (89.26 KB, text/plain)
2014-08-15 00:24 UTC, patrick korsnick
no flags Details

Description Chris Murphy 2013-06-18 17:49:14 UTC
Description of problem:
crash during installation of bootloader
The following was filed automatically by anaconda:
anaconda 19.30-1 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1643, 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 1671, in install
    self.remove_efi_boot_target()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1706, in install
    super(MacEFIGRUB, self).install()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1691, in write
    self.install()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2339, in writeBootLoader
    storage.bootloader.write()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 166, in doInstall
    writeBootLoader(storage, payload, instClass, ksdata)
  File "/usr/lib64/python2.7/threading.py", line 766, 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

Version-Release number of selected component:
anaconda-19.30-1.fc19.x86_64

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-19-Be ro rd.live.image quiet rhgb
core_backtrace: 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
other involved packages: python-libs-2.7.4-4.fc19.x86_64
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 166, in doInstall
    writeBootLoader(storage, payload, instClass, ksdata)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2339, in writeBootLoader
    storage.bootloader.write()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1691, in write
    self.install()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1706, in install
    super(MacEFIGRUB, self).install()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1671, in install
    self.remove_efi_boot_target()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1643, in remove_efi_boot_target
    raise BootLoaderError("failed to remove old efi boot entry")
BootLoaderError: failed to remove old efi boot entry

Comment 1 Chris Murphy 2013-06-18 17:49:23 UTC
Created attachment 762579 [details]
File: anaconda-tb

Comment 2 Chris Murphy 2013-06-18 17:49:27 UTC
Created attachment 762580 [details]
File: anaconda.log

Comment 3 Chris Murphy 2013-06-18 17:49:30 UTC
Created attachment 762581 [details]
File: backtrace

Comment 4 Chris Murphy 2013-06-18 17:49:33 UTC
Created attachment 762582 [details]
File: environ

Comment 5 Chris Murphy 2013-06-18 17:49:37 UTC
Created attachment 762583 [details]
File: ifcfg.log

Comment 6 Chris Murphy 2013-06-18 17:49:40 UTC
Created attachment 762584 [details]
File: lsblk_output

Comment 7 Chris Murphy 2013-06-18 17:49:44 UTC
Created attachment 762585 [details]
File: messages

Comment 8 Chris Murphy 2013-06-18 17:49:47 UTC
Created attachment 762586 [details]
File: nmcli_dev_list

Comment 9 Chris Murphy 2013-06-18 17:49:50 UTC
Created attachment 762587 [details]
File: packaging.log

Comment 10 Chris Murphy 2013-06-18 17:49:53 UTC
Created attachment 762588 [details]
File: program.log

Comment 11 Chris Murphy 2013-06-18 17:49:57 UTC
Created attachment 762589 [details]
File: storage.log

Comment 12 Chris Murphy 2013-06-18 19:38:02 UTC
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."

Comment 13 Chris Murphy 2013-06-18 19:39:26 UTC
Created attachment 762610 [details]
anacond-tb, anaconda 18.30.8-1

Comment 14 Chris Murphy 2013-06-18 19:40:00 UTC
Created attachment 762611 [details]
program.log, anaconda 18.30.8-1

Comment 15 Chris Murphy 2013-06-18 20:12:59 UTC
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)

Comment 16 Adam Williamson 2013-06-18 20:52:56 UTC
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?

Comment 17 Chris Murphy 2013-06-18 21:06:32 UTC
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.

Comment 18 Chris Murphy 2013-06-19 04:39:42 UTC
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?

Comment 19 Chris Murphy 2013-06-19 04:42:50 UTC
Weird that the status/assignee changed.

Comment 20 Adam Williamson 2013-06-19 05:05:00 UTC
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.

Comment 21 Lukas Brabec 2013-06-19 09:15:23 UTC
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)

Comment 22 Adam Williamson 2013-06-19 16:20:23 UTC
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.

Comment 23 Chris Murphy 2013-06-19 21:38:55 UTC
*** Bug 976093 has been marked as a duplicate of this bug. ***

Comment 24 Chris Murphy 2013-06-19 21:42:13 UTC
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.

Comment 25 Chris Murphy 2013-06-19 22:36:08 UTC
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.

Comment 26 Adam Williamson 2013-06-20 02:55:35 UTC
Re-assigning to kernel for now. It's probably mjg59 and pjones we need to look at this one, though.

Comment 27 Adam Williamson 2013-06-20 02:57:07 UTC
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.

Comment 28 Brian Lane 2013-06-20 20:45:28 UTC
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.

Comment 29 Chris Murphy 2013-06-20 21:31:11 UTC
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?

Comment 30 Adam Williamson 2013-06-21 00:13:15 UTC
"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.

Comment 31 Chris Murphy 2013-06-21 05:31:09 UTC
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.

Comment 32 Josh Boyer 2013-09-18 20:44:33 UTC
*********** 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.

Comment 33 David Shea 2013-09-20 12:08:41 UTC
*** Bug 1010203 has been marked as a duplicate of this bug. ***

Comment 34 Josh Boyer 2013-10-08 17:10:48 UTC
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.

Comment 35 Alexander Todorov 2013-10-09 08:50:25 UTC
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:

Comment 37 Alexander Todorov 2013-10-09 08:51:55 UTC
Possible duplicate or related bugs: 

# 909944
# 866028
# 1006304

Comment 38 Josh Boyer 2013-10-09 12:19:56 UTC
(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.

Comment 39 Adam Williamson 2013-10-10 09:45:12 UTC
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.

Comment 40 Petr Schindler 2013-10-18 12:10:52 UTC
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

Comment 41 Adam Williamson 2013-10-18 13:05:44 UTC
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.

Comment 42 Chris Murphy 2013-10-18 14:35:36 UTC
And the result from "efibootmgr -v" please.

Comment 43 Mike Ruckman 2013-11-12 00:20:00 UTC
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)

Comment 44 Chris Murphy 2013-11-21 23:08:13 UTC
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.

Comment 45 Radist Morse 2013-12-20 00:21:31 UTC
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

Comment 46 Adam Williamson 2013-12-20 00:36:23 UTC
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...)

Comment 47 Radist Morse 2013-12-20 01:15:37 UTC
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?

Comment 48 Adam Williamson 2013-12-20 01:58:00 UTC
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.

Comment 49 Radist Morse 2013-12-20 02:25:47 UTC
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.

Comment 50 Chris Murphy 2013-12-23 02:58:56 UTC
(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).

Comment 51 Adam Williamson 2013-12-23 03:21:35 UTC
"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.

Comment 52 Chris Murphy 2013-12-23 03:32:53 UTC
(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.

Comment 53 Radist Morse 2013-12-23 13:02:04 UTC
(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.

Comment 54 Ulrich Schweitzer 2014-01-02 10:54:39 UTC
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

Comment 55 Justin M. Forbes 2014-03-10 14:48:13 UTC
*********** 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.

Comment 56 Robert Moskowitz 2014-05-30 17:08:31 UTC
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

Comment 57 Adam Williamson 2014-05-30 18:20:32 UTC
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!

Comment 58 Robert Moskowitz 2014-05-30 21:05:28 UTC
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

Comment 59 Chris Murphy 2014-05-30 21:33:27 UTC
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.

Comment 60 Adam Williamson 2014-05-30 21:50:47 UTC
oh, doh, you're right, I forgot it was crashing...do what chris says.

Comment 61 Robert Moskowitz 2014-05-30 21:59:29 UTC
Created attachment 901001 [details]
/root/anaconda-tb-pwnbs4 from lastest failure

anaconda-tb-pwnbs4 from latest failure per request.

Comment 62 Chris Murphy 2014-05-31 00:05:50 UTC
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.

Comment 63 patrick korsnick 2014-07-30 01:28:48 UTC
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

Comment 64 patrick korsnick 2014-07-30 03:01:06 UTC
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

Comment 65 patrick korsnick 2014-08-11 19:55:50 UTC
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

Comment 66 patrick korsnick 2014-08-11 23:16:18 UTC
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

Comment 67 Chris Murphy 2014-08-11 23:42:07 UTC
(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>

Comment 68 patrick korsnick 2014-08-11 23:50:10 UTC
Created attachment 925886 [details]
program.log

Comment 69 patrick korsnick 2014-08-12 00:09:47 UTC
Created attachment 925888 [details]
anaconda traceback

Comment 70 Chris Murphy 2014-08-12 00:20:32 UTC
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).

Comment 71 patrick korsnick 2014-08-12 03:33:41 UTC
Created attachment 925900 [details]
program.log from attempt 3 using 20140801 live desk respin

Comment 72 patrick korsnick 2014-08-12 03:34:30 UTC
Created attachment 925901 [details]
anaconda traceback from attempt #3

Comment 73 patrick korsnick 2014-08-12 03:35:06 UTC
Created attachment 925902 [details]
dmesg output from attempt #3

Comment 74 Chris Murphy 2014-08-13 02:19:24 UTC
(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.

Comment 75 patrick korsnick 2014-08-15 00:24:37 UTC
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

Comment 76 Chris Murphy 2014-08-15 01:36:58 UTC
Good idea. I'd file a new bug against efibootmgr. And may be considered nominatable for F21 final blocker. cc me on that bug.

Comment 77 patrick korsnick 2014-08-18 20:37:25 UTC
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.

Comment 78 Chris Murphy 2014-08-18 21:25:53 UTC
(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.

Comment 79 patrick korsnick 2014-08-21 06:14:41 UTC
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

Comment 80 patrick korsnick 2014-08-21 06:32:22 UTC
(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

Comment 81 Justin M. Forbes 2014-11-13 15:56:11 UTC
*********** 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.

Comment 82 Justin M. Forbes 2014-12-10 14:57:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.