Description of problem:When installed release - almost done got erroneous error message Version-Release number of selected component (if applicable):Fedoar 22 X64 network release using DVD for workstation How reproducible: 100% with right machine Steps to Reproduce: 1. install release 2. at step where installing boot image - GET message 3. Actual results: Message: The following error occurred while installing the boot-loader. The system will not be bootable. FAILED TO SET NEW EFI BOOT TARGET This is most likely a kernel or firmware bug. Expected results: No errors. Additional info: I had used this same DVD to install one older machine and it worked fine there so it is something unique to the hardware here. I did this install a second time (adding more software selected to change the mix) and got the same exact error. The good thing is that the message was a lie. I chose to continue and the machine booted fine - I am working on this machine RIGHT NOW. The machine was running Fedora 20 just fine. I could not figure what "component" to select. SORRY. I will be glad to supply additional information if it will help.
I'm taking a stab at the installer ("anaconda") as the correct component, but as the message says, it may indeed be a kernel bug. Have you tried updating the EFI firmware on your system (the other possible culprit named).
No I have no idea how to update the EFI firmware. Please tell me and I will see if it updates (but I sure don't want to do an install again, sorry). One other comment worth mentioning. It may have booted alright because I had Fedora 20 on there before - perhaps the old boot blocks are there and booting the system. I have no way of checking that. Thanks as I have no idea where this should have been filed.
Please attach the logs from /tmp as individual, text/plain attachments.
Most sorry, this machine has been rebooted at least 4 times since then. Anything in /tmp is lost as it is wiped each time (I like that fedora does it, I used to do that manually in /etc/rc.local). If there is a stable place that I can get logs from (/var/logs or ...), I will be glad to attach. Besides the problem here occurs during the Fedora build, not after reboot. I have no idea how to get to any temporary files built in the memory kernel that was running (at least that is how it used to be done in the old days - before you had a disk, you worked with a memory kernel). Note this only occurs on a machine with a graphics board. I will be glad to attach any files you need and/or information if you give me shell commands on how to amass the info. Apologies - Ray
Installation logs are copied to /var/log/anaconda in the installed system.
Created attachment 1040595 [details] more /var/log/anaconda/* > /tmp/anaconda.logs if you need anything else, shout
For the record, the fact that the machine booted may not conflict with the statement by the software that it would not. I have no way of knowing for sure, but I may be booting from the bootblocks installed by Fedora 20.
This is usually a firmware problem, either it ran out of variable space or it has a bug. It will usually boot by using the fallback.efi in /EFI/BOOT/ and will try to recreate the variables. Although I don't think I've seen this exact error before: 09:13:41,039 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi 09:13:41,100 INFO program: efibootmgr: Could not add entry to BootOrder: No such file or directory 09:13:41,101 DEBUG program: Return code: 6
OK, is there anything I can do here to confirm your theory (other than a total rebuild - that is too painful)? I know nothing about checking or updating the firmware on this DELL box. I am willing to update the firmware and try the command again if this will not result in my hosing the box (I would think that should be fairly safe as failure before turned out OK).
Seeking correct way to update firmware, but have not found the correct way yet. After update of firmware, would be more than willing to run failing command to try again. Please instruct with with either how to update, or how to run command. Here is what I have been trying to do the former: wget -q -O - http://linux.dell.com/repo/software/bootstrap.cgi wget -q -O - http://linux.dell.com/repo/firmware/bootstrap.cgi dnf -y install firmware-addon-dell dnf -y install $(bootstrap_firmware) update_firmware step 2 (wget) does nothing step 4 fails not knowing what $(bootstrap_firmware) is step 5 says nothing to do, probably because 2 + 4 fail
I tried to update my firmware pretty hard - one more time - [root@rainbow tech]# update_firmware Running system inventory... Searching storage directory for available BIOS updates... This system does not appear to have any updates available. No action necessary. So if there is something wrong, I give up.
I have been building a remix of Fedora for several months now. I use the 'pungi' utility to do this (works great, BTW). The hardware platform that I am working with is a small box that is based on the Intel Atom Z3735F Quad Core processor. I have been building my remix based on Fedora 21 and, up until yesterday, I have had no problems creating an installation that worked flawlessly on my platform. However, building against Fedora 22 has always resulted in an installation that issued the error noted in the title of this bug. Consistently, without fail. And as mentioned in a previous post, typing 'yes' to continue will actually result in a valid and working installation. Then yesterday, I rebuilt my Fedora 21-based installation and now I am seeing the 'efi boot target' message! With side-by-side package listings, the only thing I can see that could cause this is the latest kernel package update: Working version: kernel-4.1.6-100.fc21 Broken version: kernel-4.1.7-100.fc21 The only other package differences are cryptsetup-libs, gnupg2 and vim-minimal. I'm really hoping that this may shed some light on the problem and a possible solution, not only for Fedora 21 but also 22 (and perhaps beyond?).
(In reply to Roger Gaudet from comment #12) > I have been building a remix of Fedora for several months now. I use the > 'pungi' utility to do this (works great, BTW). The hardware platform that I > am working with is a small box that is based on the Intel Atom Z3735F Quad > Core processor. I have been building my remix based on Fedora 21 and, up > until yesterday, I have had no problems creating an installation that worked > flawlessly on my platform. However, building against Fedora 22 has always > resulted in an installation that issued the error noted in the title of this > bug. Consistently, without fail. And as mentioned in a previous post, > typing 'yes' to continue will actually result in a valid and working > installation. > > Then yesterday, I rebuilt my Fedora 21-based installation and now I am > seeing the 'efi boot target' message! With side-by-side package listings, > the only thing I can see that could cause this is the latest kernel package > update: > > Working version: kernel-4.1.6-100.fc21 > Broken version: kernel-4.1.7-100.fc21 > > The only other package differences are cryptsetup-libs, gnupg2 and > vim-minimal. > > I'm really hoping that this may shed some light on the problem and a > possible solution, not only for Fedora 21 but also 22 (and perhaps beyond?). I am no expert in how the EFI stuff works but I did notice the following entry in the kernel package changelog for 4.1.7-100: Fri Aug 21 2015 Josh Boyer <jwboyer> - Disable EFI_VARS *rhbz 1252137)
One of the difficulties in doing remixes is that we generally don't update anaconda after the release. So changes in other packages can introduce problems. It is usually a good idea to start making your remix using only the released packages, and then add specific updates to that.
If I may ask, what is entailed in updating anaconda? Is this something that someone like me with reasonable but perhaps misguided ambition can do or is this a "run-don't-walk away" kind of thing? I am no stranger to anaconda, but I understand and respect its complexities. From what I can gather from recent experimentation, the 'pungi' facility builds the installer with the kernel that is downloaded as part of the package selection process (presumably by looking at all the 'repo' statements in the kickstart file and performing its dependency & version resolution magic, etc.). This seems to be where the problem lies. During installation, the operational environment is running kernel 4.1.7-100.fc21, which is the latest version from the updates repository. Based on Brian's comment, something in anaconda is now having an issue with using this new kernel and is throwing the 'efi boot target' message. There appear to be two solutions here: 1) force my package list to use kernel 4.1.6-100.fc21, or 2) update anaconda to deal with the latest kernel. I would prefer #2, but would really like to know what I'm getting into if I try to do this. Any thoughts would be greatly appreciated.
(In reply to Roger Gaudet from comment #15) > If I may ask, what is entailed in updating anaconda? Is this something that > someone like me with reasonable but perhaps misguided ambition can do or is > this a "run-don't-walk away" kind of thing? I am no stranger to anaconda, > but I understand and respect its complexities. > That's certainly possible, if it is something you like to do :) > From what I can gather from recent experimentation, the 'pungi' facility > builds the installer with the kernel that is downloaded as part of the > package selection process (presumably by looking at all the 'repo' > statements in the kickstart file and performing its dependency & version > resolution magic, etc.). This seems to be where the problem lies. During > installation, the operational environment is running kernel 4.1.7-100.fc21, > which is the latest version from the updates repository. Based on Brian's > comment, something in anaconda is now having an issue with using this new > kernel and is throwing the 'efi boot target' message. There appear to be > two solutions here: 1) force my package list to use kernel 4.1.6-100.fc21, > or 2) update anaconda to deal with the latest kernel. I would prefer #2, > but would really like to know what I'm getting into if I try to do this. > Any thoughts would be greatly appreciated. I'd try #1 first. This issue may just need to have commit 104fbd792435b63 from blivet back-ported. Or it may be more complex.
Could you be more specific about what "commit 104fbd792435b63 from blivet" applies to and what would be patched by a back-port of the changes?
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.