Created attachment 736283 [details] anaconda-logs-20130416.tar.gz I tried to install from the RC3 DVD installation media (x86_64): https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC3/Fedora/x86_64/iso/Fedora-19-Alpha-x86_64-DVD.iso The installer booted, I could select a destination disk (did not change partitioning), set a root and user password. However, the installation did not complete successfully, and anaconda reported an "unknown error". I switched consoles, but then the X server crashed. I'm attaching the log files I could recover from the failed installation attempt. I saw this, I don't know how relevant it is: 10:08:29,065 WARNING kernel:[ 1616.817187] efivars: set_variable() failed: status=8000000000000009
Please attach logs as individual, uncompressed attachments. Doing anything else prevents us from searching bugzilla in the future.
Created attachment 736310 [details] anaconda.log
Created attachment 736311 [details] anaconda-tb-ALQ2K0
Created attachment 736312 [details] anaconda-yum.conf
Created attachment 736313 [details] ifcfg.log
Created attachment 736314 [details] packaging.log
Created attachment 736315 [details] program.log
Created attachment 736316 [details] storage.log
Created attachment 736317 [details] storage.state
Created attachment 736318 [details] syslog
Created attachment 736319 [details] X.log
06:08:28,969 INFO program: Running... efibootmgr -b 0001 -B 06:08:29,073 DEBUG program: Return code: 1 That's not especially helpful.
(In reply to comment #12) > 06:08:28,969 INFO program: Running... efibootmgr -b 0001 -B > 06:08:29,073 DEBUG program: Return code: 1 > > That's not especially helpful. Not sure if this is my fault (IOW, so is your comment). Is there something I can do post-installation to obtain more data?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
florian: 8000000000000009 is our old friend EFI_OUT_OF_RESOURCES , which basically means this case is quite likely to have related to our old friend the Samsung bricking bug. Post F19, the kernel stuff was tweaked to still not brick Samsungs while being less likely to run into EFI_OUT_OF_RESOURCES on other systems; did you try F20 on this system? There's a reasonable chance it'd work. (note: the fact that efibootmgr fails silently when set_variable() fails is what clumens was referring to in c#12, and is indeed something that efibootmgr could do better).
still valid in current Rawhide, as we're still on 0.5.4.
Filed upstream as https://github.com/vathpela/efivar/issues/4 - we just need to keep track of when pjones gets time to fix it upstream and the fixed version lands in Fedora.
(In reply to Adam Williamson from comment #15) > florian: 8000000000000009 is our old friend EFI_OUT_OF_RESOURCES , which > basically means this case is quite likely to have related to our old friend > the Samsung bricking bug. Post F19, the kernel stuff was tweaked to still > not brick Samsungs while being less likely to run into EFI_OUT_OF_RESOURCES > on other systems; did you try F20 on this system? There's a reasonable > chance it'd work. I installed F20 on my test machine, and the installation completed. This is a dual-boot environment with Windows 8, and the installer failed to bump the priority over the Fedora entry over the Windows boot loader entry. However, booting Fedora was possible after going through the Windows boot selector.
One of the following should fix the error code reporting issue: https://admin.fedoraproject.org/updates/efibootmgr-0.10.0-1.fc19 https://admin.fedoraproject.org/updates/efibootmgr-0.10.0-1.fc20 https://admin.fedoraproject.org/updates/efibootmgr-0.10.0-1.fc21 (or the efibootmgr-0.10.0-1.fc22 package in rawhide )
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
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.