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