Version-Release number of selected component: anaconda-core-21.48.21-1.fc21.x86_64 The following was filed automatically by anaconda: anaconda 21.48.21-1 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1725, in _add_single_efi_boot_target raise BootLoaderError("failed to set new efi boot target. This is most likely a kernel bug.") File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1729, in add_efi_boot_target self._add_single_efi_boot_target(self.stage1_device) File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1737, in install self.add_efi_boot_target() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1757, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2346, in writeBootLoaderFinal storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2416, in writeBootLoader writeBootLoaderFinal(storage, payload, instClass, ksdata) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 255, 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 227, in run threading.Thread.run(self, *args, **kwargs) BootLoaderError: failed to set new efi boot target. This is most likely a kernel bug. Additional info: cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-21-5 ro rd.live.image quiet rhgb executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.17.4-301.fc21.x86_64 other involved packages: python-libs-2.7.8-7.fc21.x86_64 product: Fedora" release: Fedora release 21 (Twenty One) type: anaconda version: Fedora
Created attachment 966636 [details] File: anaconda-tb
Created attachment 966637 [details] File: anaconda.log
Created attachment 966638 [details] File: environ
Created attachment 966639 [details] File: journalctl
Created attachment 966640 [details] File: lsblk_output
Created attachment 966641 [details] File: nmcli_dev_list
Created attachment 966642 [details] File: os_info
Created attachment 966643 [details] File: program.log
Created attachment 966644 [details] File: storage.log
Created attachment 966645 [details] File: ifcfg.log
Created attachment 966646 [details] File: packaging.log
Another user experienced a similar problem: Durng installation of Fedora 21 Server on a computer with UEFI firmware. addons: com_redhat_kdump cmdline: /usr/bin/python /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-21-x86_64 quiet hashmarkername: anaconda kernel: 3.17.4-301.fc21.x86_64 package: anaconda-21.48.21-1 product: Fedora" reason: BootLoaderError: failed to set new efi boot target. This is most likely a kernel bug. release: Cannot get release name. version: Fedora
efibootmgr segfaulted. Does the media check pass? Dec 10 00:09:36 imranfedora21 kernel: efibootmgr[18857]: segfault at 410 ip 00007f3be04934ec sp 00007fff5a2a6da0 error 4 in libefivar.so.0[7f3be0490000+7000] Dec 10 00:09:37 imranfedora21 kernel: efibootmgr[18860]: segfault at 410 ip 00007fbcc9b734ec sp 00007fff4b008140 error 4 in libefivar.so.0[7fbcc9b70000+7000] Dec 10 00:09:37 imranfedora21 abrt-hook-ccpp[18861]: Not saving repeating crash in '/mnt/sysimage/usr/sbin/efibootmgr'
(In reply to David Shea from comment #13) > efibootmgr segfaulted. Does the media check pass? > > Dec 10 00:09:36 imranfedora21 kernel: efibootmgr[18857]: segfault at 410 ip > 00007f3be04934ec sp 00007fff5a2a6da0 error 4 in > libefivar.so.0[7f3be0490000+7000] > Dec 10 00:09:37 imranfedora21 kernel: efibootmgr[18860]: segfault at 410 ip > 00007fbcc9b734ec sp 00007fff4b008140 error 4 in > libefivar.so.0[7fbcc9b70000+7000] > Dec 10 00:09:37 imranfedora21 abrt-hook-ccpp[18861]: Not saving repeating > crash in '/mnt/sysimage/usr/sbin/efibootmgr' Actually, installed work in legacy (not-efi) mode. I think it's some weird setting on my motherboard; I've had a similar problem when installing Fedora 20, where installing efi bootloader failed but legacy worked.
(In reply to nujuxz from comment #14) > (In reply to David Shea from comment #13) > > efibootmgr segfaulted. Does the media check pass? > > > > Dec 10 00:09:36 imranfedora21 kernel: efibootmgr[18857]: segfault at 410 ip > > 00007f3be04934ec sp 00007fff5a2a6da0 error 4 in > > libefivar.so.0[7f3be0490000+7000] > > Dec 10 00:09:37 imranfedora21 kernel: efibootmgr[18860]: segfault at 410 ip > > 00007fbcc9b734ec sp 00007fff4b008140 error 4 in > > libefivar.so.0[7fbcc9b70000+7000] > > Dec 10 00:09:37 imranfedora21 abrt-hook-ccpp[18861]: Not saving repeating > > crash in '/mnt/sysimage/usr/sbin/efibootmgr' > > Actually, installed work in legacy (not-efi) mode. I think it's some weird > setting on my motherboard; I've had a similar problem when installing Fedora > 20, where installing efi bootloader failed but legacy worked. To clarify, my motherboard is a Gigabyte 970A-UD3.
*** Bug 1187974 has been marked as a duplicate of this bug. ***
Another user experienced a similar problem: tried to install fedora xfce spin on a asus z77 extreme mother board and a samsung 840 evo 120gbssd let fedora partition for me also woudn't work when i tried to create partition lay our myself booted off usb made with fedora usb creator in uefi mode normal mode did not work got error failed to set new efi boot target this is most likely a kernel bug cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=/syslinux/vmlinuz0 root=live:LABEL=LIVE ro rd.live.image quiet rhgb hashmarkername: anaconda kernel: 3.17.4-301.fc21.x86_64 other involved packages: python-libs-2.7.8-7.fc21.x86_64 package: anaconda-core-21.48.21-1.fc21.x86_64 product: Fedora" reason: BootLoaderError: failed to set new efi boot target. This is most likely a kernel bug. release: Fedora release 21 (Twenty One) version: Fedora
Another user experienced a similar problem: Generate F21 USB-disk with liveusb-creator from ISO-file X86_64 Desktop After Booting, select keyboard layout and then 'install to disk' In the state 'install bootloader' comes popup saying "failed to set new efi boot target. This is most likely a kernel bug" The installed disk doesnt boot. I tried more than once; i tried even to 'yum update' the packages grub2,grub2-efi,grub2-tools,python-blivet before installing. If this is really kernel-bug, how can i update the kernel in the USB-disk? To get a new kernel running, i have to reboot: after reboot, all updates are lost. If this is really kernel-bug, the downloadable ISO-Image should be regenerated! cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-21-5 ro rd.live.image quiet rhgb hashmarkername: anaconda kernel: 3.17.4-301.fc21.x86_64 other involved packages: python-libs-2.7.8-7.fc21.x86_64 package: anaconda-core-21.48.21-1.fc21.x86_64 product: Fedora" reason: BootLoaderError: failed to set new efi boot target. This is most likely a kernel bug. release: Fedora release 21 (Twenty One) version: Fedora
Is someone here who can give a pointer to this kernel-bug? Can i do some manual repair after installation before reboot? Can i provide some other info/logs/dumps ? Mainboard is ASUS Sabertooth X79 with UEFI-BIOS see also http://www.asus.com/Motherboards/SABERTOOTH_X79/ Installing F20 last year on this MB was not a problem.
This is another one of those bugs that isn't always the same, so we need to see your logs - in this case program.log is the most important one, so can you attach that? anaconda calls 'efibootmgr' to interact with the UEFI firmware, and this is the message you get when it tries to create a new EFI boot manager entry and that fails. The *reason* why it failed can vary from case to case.
Another user experienced a similar problem: I was attempting to install fedora when the error occurred. cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=/syslinux/vmlinuz0 root=live:LABEL=LIVE rw rd.live.image rd.live.overlay=LABEL=LIVE quiet rhgb hashmarkername: anaconda kernel: 3.17.4-301.fc21.x86_64 other involved packages: python-libs-2.7.8-7.fc21.x86_64 package: anaconda-core-21.48.21-1.fc21.x86_64 product: Fedora" reason: BootLoaderError: failed to set new efi boot target. This is most likely a kernel bug. release: Fedora release 21 (Twenty One) version: Fedora
Another user experienced a similar problem: Started installation of Fedora 21 server on 120 GB SDD and uefi boot. Am using custom partitioning, including /boot/efi, /, swap, /home. Installation aborted, unable to set up /boot/efi. addons: com_redhat_kdump cmdline: /usr/bin/python /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-21-x86_64 quiet hashmarkername: anaconda kernel: 3.17.4-301.fc21.x86_64 package: anaconda-21.48.21-1 product: Fedora" reason: BootLoaderError: failed to set new efi boot target. This is most likely a kernel bug. release: Cannot get release name. version: Fedora
Created attachment 1011858 [details] Rsync fails to copy /boot/efi its a selinux problem
(In reply to awilliam from comment #20) > This is another one of those bugs that isn't always the same, so we need to > see your logs - in this case program.log is the most important one, so can > you attach that? > Was i see from program.log is some rsync invocation failed with having problems with selinux After that, efibootmgr gives exit code -11 which i think is because rsync failed to copy some files to /mnt/sysimage/boot/efi The Bug is to not check the return code 23 of the rsync-invocation, giving erraneous info to user (kernel bug!) o.t.: why use selinux in install process? why use selinux at all?
No, there is no selinux problem. What happens there is that SELinux contexts cannot be set for those files because they're on an EFI FAT filesystem (which doesn't support such attributes). The command is transferring more than just those files, which is why it tries to transfer SELinux contexts at all; it *does* successfully set the contexts for all the other files it transfers (you can tell, because there are no errors for those files). Note the error is "some files/attrs were not transferred" - in this case, the *files* were transferred, it's only the *attrs* that weren't. efibootmgr does not rely on anything being present in /boot/efi in any case. The firmware boot manager entry it creates may fail to *work* if the files it's supposed to load aren't present, but creating the entry would not fail, there is no creation-time validity check for boot manager entries. You can create an entry pointing to a disk that doesn't exist at all, if you like.
ok, but there is the return code -11 from efibootmgr invocation. As i see, it is started twice, the first time without arguments. Would a manual invocation of su ulimit -c unlimited efibootmgr produce some useful coredump? or is this not worth the effort?
Yes, that is clearly the problem, but we really need a pjones or similar to take a guess at what's actually going wrong :/ That manual invocation certainly couldn't hurt. My inexpert eyeballing of the code seems to indicate that efibootmgr returns exit code 11 when it fails to wipe the 'Timeout' variable, but that doesn't seem right, because I can't see why a bare 'efibootmgr' invocation would try to do that in the first place...
the problematic RC is -11, not +11. Does this mean SIGSEGV ? I managed to boot the partially installed F21 with help from BIOS (it scans all disks for EFI partitions). A naked invocation of efibootmgr gives only the boot list: BootCurrent: 0007 Timeout: 1 seconds BootOrder: 0000,0007,0003,0002,0005 Boot0000* Fedora Boot0002* CD/DVD Drive Boot0003* Hard Drive Boot0005* Network Card Boot0007* UEFI OS $?=0 Then on the half-installed F21 i did: efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi and it gave the lines: ** Warning ** : Boot0000 has same label Fedora BootCurrent: 0007 Timeout: 1 seconds BootOrder: 0001,0000,0007,0003,0002,0005 Boot0000* Fedora Boot0002* CD/DVD Drive Boot0003* Hard Drive Boot0005* Network Card Boot0007* UEFI OS Boot0001* Fedora which shows it has added the boot-entry "Fedora" without problems. I am a little bit worried about the backslashes not being doubled.
"I managed to boot the partially installed F21 with help from BIOS (it scans all disks for EFI partitions)." That's actually the EFI 'fallback path' behaviour, it's defined in the spec, and we do some magic in anaconda to try and make boot work even when the boot menu entry creation fails, by providing a bootloader on the fallback path. So...you're welcome. ;) There is *further* magic which then tries again to create the EFI boot manager entry, and from your output, it looks like that has now succeeded. So it's probably not telling us much useful. (You've now created two entries with the same name, which probably isn't a great idea - I'd suggest removing the one you just added). What would be useful is if you could boot the installer again and try running 'efibootmgr' in the installer env to see if you can reproduce the failure there.
:-) There is a little bit too much magic in EFI? In the liveimage, invoking efibootmgr shows no problems: BootCurrent: 0008 Timeout: 1 seconds BootOrder: 0001,0000,0007,0008,0003,0002,0005 Boot0000* Fedora Boot0001* Fedora Boot0002* CD/DVD Drive Boot0003* Hard Drive Boot0005* Network Card Boot0007* UEFI OS Boot0008* UEFI: SanDisk Cruzer Contour [liveuser@localhost ~]$ echo $? 0 So is it probably the anaconda-environment which is hostile to efibootmgr?
or a quirk in your firmware; it happens. the 'further magic' I mention is in Fedora, not UEFI; when we spot that we were booted via the fallback path and the expected EFI boot manager entry for Fedora is missing, we try to recreate it.
Now i have this workaround to get a bootable F21: Open a root terminal window before starting install_to_disk Start install_to_disk as usual When the error 'failed to set...' pops up, <alt>-<tab> to the terminal and type: tail -25 /tmp/program.log efibootmgr efibootmgr -c -w -L Fedora21 -d /dev/sda -p 1 -l \\EFI\\fedora\\shim.efi and then continue with the install process. When copying the second invocation line, double the backslashes and change the Label to something meaningful. Fedora 21 is now installed in UEFI mode as it should be. No kernel bug, no firmware quirx, no efibootmgr error.
Last week i installed fresh-loaded Fedora 22 on a similar machine (same mainboard Asus sabertooth x79 with UEFI-firmware vers. 4801) The same error occured. I did the same workaround as on the first machine and i could complete the installation. So my question: Can i produce some additional helpful outputs? Some special anaconda with additional trace-info? As this second machine is a backup device, i can experiment with it.
I have the same problem on my laptop.
Any case where you hit this message is highly system-specific; basically it means 'we sent some perfectly normal commands to the firmware and it crapped itself'. So any two cases which *don't* involve the same motherboard are probably different. At minimum we need to see program.log from each specific case (so we can see exactly what the efibootmgr command that failed was, and what the error code was if there was one). pjones is the expert who can possibly look into things further from there, but he's currently busy with some other work and probably won't have time for miscellaneous Fedora bugs till July, unfortunately.
I faced the same issue while installing Fedora 22 to Lenovo Thinkpad e550 along with Windows 8.1. After installation I booted Fedora installation USB media in troubleshooting mode and checked EFI boot setup and it looked something like this $ efibootmgr BootCurrent: 0013 Timeout: 0 seconds BootOrder: 000C,0013,0007,0008,0009,000A,000B,000D Boot0000 Setup Boot0001 Boot Menu Boot0002 Diagnostic Splash Screen Boot0003 Lenovo Diagnostics Boot0004 Startup Interrupt Menu Boot0005 Rescue and Recovery Boot0006 MEBx Hot Key Boot0007* USB CD Boot0008* USB FDD Boot0009* ATA HDD0 Boot000A* ATA HDD1 Boot000B* ATA HDD2 Boot000C* USB HDD Boot000D* PCI LAN Boot000E* IDER BOOT CDROM Boot000F* IDER BOOT Floppy Boot0010* ATA HDD Boot0011* ATAPI CD Boot0012* PCI LAN Boot0013* Windows Boot Manager Boot0014* Fedora Fedora is there, but it's not in boot list. So I just added Fedora before Windows in boot list with a command $ efibootmgr -o c,14,13,7,8,9,a,b,d And now both Fedora and Windows boots fine.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.