Description of problem: After upgrading to F18 (using kernel-3.8.4-202.fc18) efibootmgr is no longer able to write to "/sys/firmware/efi/vars/new_var" because it results in ENOSPC. After rebooting to the prevous (F17) kernel (kernel-3.7.9-104.fc17.x86_64) efbootmgr is able to write to "/sys/firmware/efi/vars/new_var". Version-Release number of selected component (if applicable): kernel-3.8.4-202.fc18.x86_64 How reproducible: 100% (on my Asus C60M1-I BIOS 0205) Steps to Reproduce: 1. upgrace F17 tot F18 using yum 2. reboot 3. try to use grub2-efi instead of grub by (also) using efibootmgr Actual results: Nothing changes in efivars/NFVRAM Expected results: Modified efivars/NVRAM Additional info: Bug 922275
The kernel now limits efivars from using more than 50% of the available firmware space. This has some known deficiencies if the firmware on the machine doesn't do garbage collection to free up space. This is being worked on upstream.
Also, some Asus boards return 0 for the maximum variable size.
For informational purposes: I upgraded the C60M1-I bios to 0305, that did not help.
*** Bug 949122 has been marked as a duplicate of this bug. ***
This could be a candidate for F19 Alpha blocker, but we'd kinda need to guess how many systems it's likely to affect; anyone have a WAG?
(In reply to comment #1) > The kernel now limits efivars from using more than 50% of the available > firmware space. This has some known deficiencies if the firmware on the > machine doesn't do garbage collection to free up space. This is being > worked on upstream. Josh, do you know if the fix is already available upstream/could be backported? Also it would be nice to have guess how wide spread this bug is as Adam asked - forh Alpha, we could be tolerant (but it really depends). Thanks.
(In reply to comment #6) > (In reply to comment #1) > > The kernel now limits efivars from using more than 50% of the available > > firmware space. This has some known deficiencies if the firmware on the > > machine doesn't do garbage collection to free up space. This is being > > worked on upstream. > > Josh, do you know if the fix is already available upstream/could be > backported? Matthew Garrett has patches submitted, but the upstream EFI maintainer has some concerns and would like a few changes. > Also it would be nice to have guess how wide spread this bug is > as Adam asked - forh Alpha, we could be tolerant (but it really depends). > Thanks. I honestly don't know. I would think the number of machines that run out of space while doing an OS install would be fairly low, as we only add a boot variable for shim. However, it really depends on the state of the NVRAM before we install so it's hard to say. If Peter or Matthew have a better idea on how widespread of a problem this would be, I'm sure they'll speak up. (Note, I'm focusing on the default install here. Not people using gummiboot or manually changing bootloaders, or doing other stuff that isn't part of getting Fedora booting.)
Created attachment 733186 [details] mac grub screen It seems that Mac Mini is affected. See screenshot. You can't do anything. F19 Alpha RC1 UEFI (dd'd DVD to USB).
No, if grub is starting at all then you're not affected by this.
I tried to reproduce on an ASUS UEFI motherboard and I received bug 950022. I don't know whether it is related, it could be.
As far as I can judge something like this seems to be happening after install of Fedora 19 Alpha TC 1 on Lenovo Thinkpad T520 using UEFI. (latest firmware). The install appears to complete but at reboot grub does not start, at least it 'tries to' but fails, leaving black screen. I see nothing in the logs that appears related using rescue mode.
*** Bug 950022 has been marked as a duplicate of this bug. ***
To explain the "See also: 949721": #949721 is kind of a complementary bug here. Apparently, F17 and F18 have code to write kernel dumps to the UEFI firmware (so they can be recovered and debugged if the crash is particularly hard), but there was no corresponding mechanism for cleaning them out after a certain time, or after they're reported, or after a certain amount have accumulated. So if you have an F17 or F18 install that you've actually been using for a while, it's possible that mechanism will have completely filled your NVRAM with crash dumps. If you get affected by *that*, then you still won't be able to do an install even after this bug is fixed. So what Josh and Matthew are looking at here is to implement both the upstream kernel patches for this bug (once they're accepted), and a mechanism in anaconda to clean out kernel dumps from the NVRAM before attempting to do its efibootmgr runs.
(In reply to comment #13) > mechanism in anaconda to clean out kernel dumps from the NVRAM before > attempting to do its efibootmgr runs. https://bugzilla.redhat.com/show_bug.cgi?id=950709
Similar problem: bug 949786 "failed to set new efi boot target". EFI install to bare metal ASUS P8Z68-V/GEN3, BIOS version 3402 (May 2012) using Fedora-19-Alpha-RC2 (and RC1)
Yup, and smooge also had a failure that libreport considered a dupe of 949786.
Description of problem: Trying a UEFI install of F19 Alpha RC2; this will be the ENOSPC bug, probably. Version-Release number of selected component: anaconda-19.17-1 Additional info: cmdline: /usr/bin/python /sbin/anaconda cmdline_file: BOOT_IMAGE=/syslinux/vmlinuz inst.stage2=hd:UUID=76E6-7761 quiet slub_debug=-x executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.9.0-0.rc4.git0.1.fc19.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 19-Alpha Truncated backtrace: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run threading.Thread.run(self, *args, **kwargs) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 141, in doInstall writeBootLoader(storage, payload, instClass, ksdata) File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2246, in writeBootLoader storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1690, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1670, in install self.remove_efi_boot_target() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1642, in remove_efi_boot_target raise BootLoaderError("failed to remove old efi boot entry") BootLoaderError: failed to remove old efi boot entry
Description of problem: Fedora 19 Alpha RC2 install in UEFI mode booted from netinst.iso dd'ed to USB stick. Minimal install on reclaimed disk /dev/sdb, default partitioning on whole disk (GPT). Crash during "Installing bootloader". Lenovo ThinkPad T520. Version-Release number of selected component: anaconda-19.17-1 Additional info: cmdline: /usr/bin/python /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2019-Alpha\x20x86_64 inst.updates=http://dlehman.fedorapeople.org/updates/updates-950510.0.img executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.9.0-0.rc4.git0.1.fc19.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 19-Alpha Truncated backtrace: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run threading.Thread.run(self, *args, **kwargs) File "/usr/lib64/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 141, in doInstall writeBootLoader(storage, payload, instClass, ksdata) File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2246, in writeBootLoader storage.bootloader.write() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1690, in write self.install() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1670, in install self.remove_efi_boot_target() File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1642, in remove_efi_boot_target raise BootLoaderError("failed to remove old efi boot entry") BootLoaderError: failed to remove old efi boot entry
After updating Lenovo ThinkPad T520 to the newest BIOS (going from version 1.31 to version 1.42) I no longer see this error and can successfully complete an EFI install of 19 Alpha RC2.
Could you try to wipe out pstore as described in Mathew's blog - http://mjg59.dreamwidth.org/23554.html - and try to reproduce this bug again? If reproducible - it would be probably this bug (so another option could be updating UEFI as it seems it makes difference too based on comment #19). Otherwise I'd say it would be more issue of not clearing pstore - and #950709 and we could document it in release notes in case we would be ok with workaround. Correct me, if I'm wrong ;-).
I tested F19 Alpha RC2 on my production UEFI system. I ended up with "BootLoaderError: failed to remove old efi boot entry". However, it _did_ remove my old UEFI entry (pointing to an existing Fedora 18 installation), and it didn't create a new one, so I ended up with no boot entry at all. The system also didn't boot using a BIOS boot (that's another bug I suppose, the fallback should have worked), so I had no way to boot my previous system. I had a bloody hard time to figure out how to fix this. Eventually I find out that removing /sys/fs/pstore/* will free up the NVRAM space and allow me to manually create a new UEFI boot entry using efibootmgr. I don't think there is more than a few percent of our user base who would be able to resolve this.
(In reply to comment #21) > Eventually I find out > that removing /sys/fs/pstore/* will free up the NVRAM space and allow me to > manually create a new UEFI boot entry using efibootmgr. Seems like this confirms it's really more about #950709 - if we clean up pstore, we have enough space there, at least reported for some systems. > I don't think there is more than a few percent of our user base who would be > able to resolve this. Agree, it could be difficult for many users to resolve the issue. Question is if Release Notes and Common Bugs with guide what to do before installing UEFI would be sufficient or not.
(In reply to comment #20) > Could you try to wipe out pstore as described in Mathew's blog - > http://mjg59.dreamwidth.org/23554.html - and try to reproduce this bug > again? If reproducible - it would be probably this bug (so another option > could be updating UEFI as it seems it makes difference too based on comment > #19). Otherwise I'd say it would be more issue of not clearing pstore - and > #950709 and we could document it in release notes in case we would be ok > with workaround. Correct me, if I'm wrong ;-). In my case where updating the BIOS "fixed" the problem, I still have the same contents of pstore that I had before updating the BIOS, so I don't think it cleaned up anything: [root@localhost pstore]# find /sys/fs/pstore/ -ls 8232 0 drwxr-xr-x 2 root root 0 Apr 11 04:24 /sys/fs/pstore/ 8243 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-1 8242 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-2 8241 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-3 8240 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-4 8239 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-5 8238 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-6 8237 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-7 8236 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-8 8235 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-9 8234 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-10 8233 0 -r--r--r-- 1 root root 1024 Nov 2 2011 /sys/fs/pstore/dmesg-efi-11
In my failing case (ASUS P8Z68-V/GEN3 with BIOS version 3402 from May 2012), I never had a kernel oops or crash, or anything else in pstore. After "mount -t pstore /sys/fs/pstore /sys/fs/pstore" the directory /sys/fs/pstore was empty. So pstore probably isn't the only problem. In particular, multiple attempts at installing via UEFI can create enough garbage to get in the way. See the output from "efibootmgr --verbose" in https://bugzilla.redhat.com/show_bug.cgi?id=949761#c5
Discussed at 2013-04-11 F19 Alpha go/no-go meeting, acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-11/f19_alpha_gono-go_meeting.2013-04-11-17.00.log.html . Accepted as a blocker as testing so far indicates a lot of UEFI systems are susceptible to this bug, and it can leave the system in a somewhat messy state.
The same result as in Comment 24: /sys/fs/pstore was empty (and also no kernel oops or crash on this machine ever) I also cannot find any references to a 'bootloader error' of any kind. So it seems there might be more ways problems can arise when doing an UEFI install.
On my ThinkPad X230 (latest EFI) the pstore was empty too. However in /sys/firmware/efi/efivars I had lots of Files named dump-type0* After deleting those I could use efibootmgr again.
(In reply to comment #27) > On my ThinkPad X230 (latest EFI) the pstore was empty too. > However in /sys/firmware/efi/efivars I had lots of Files named dump-type0* > After deleting those I could use efibootmgr again. Was that with F19 or F18? If it was with F19, was pstore mounted?
(In reply to comment #24) > In my failing case (ASUS P8Z68-V/GEN3 with BIOS version 3402 from May 2012), > I never had a kernel oops or crash, or anything else in pstore. After > "mount -t pstore /sys/fs/pstore /sys/fs/pstore" the directory /sys/fs/pstore > was empty. So pstore probably isn't the only problem. If you're using F19, systemd should be mounting pstore by default for you. A manual mount should not be required.
(In reply to comment #28) > (In reply to comment #27) > > On my ThinkPad X230 (latest EFI) the pstore was empty too. > > However in /sys/firmware/efi/efivars I had lots of Files named dump-type0* > > After deleting those I could use efibootmgr again. > > Was that with F19 or F18? If it was with F19, was pstore mounted? This was on F19 (Fedora-Live-Desktop-x86_64-19-Alpha-TC6-1.iso). pstore was mounted. At least I could not mount it manually because it said something was already mounted there.
I committed Matthew's V6 patches after they got an informal review from upstream.
kernel-3.9.0-0.rc6.git2.3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-5224/kernel-3.9.0-0.rc6.git2.3.fc19
Created attachment 736131 [details] console.log efibootmgr can create entry with .git2.3 now. Other problems happened: BUG: sleeping function called from invalid context at mm/slub.c:925 pstore: failed to load 2 record(s) from 'efi' when mounting pstore. Looks like remnant of bug 877366. After removing files in pstore, you can't rm dump-* again in efivarfs. Otherwise general protection fault happens in do_raw_spin_lock, the same pattern with bug 918422. Upstream report is here http://thread.gmane.org/gmane.linux.kernel.efi/1075
(In reply to comment #29) > If you're using F19, systemd should be mounting pstore by default for you. > A manual mount should not be required. Note that I've been booting kernel with efivars.pstore_disable=N in case efi pstore isn't enabled by default. Is it what cause pstore to be empty?
Package kernel-3.9.0-0.rc6.git2.3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.9.0-0.rc6.git2.3.fc19' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5224/kernel-3.9.0-0.rc6.git2.3.fc19 then log in and leave karma (feedback).
Petr Schindler did a UEFI installation today with F19 Alpha RC3, but he failed to add a comment here, so I'll add it: The installer fails during bootloader installation with "BootLoaderError: failed to remove old efi boot entry". /sys/fs/pstore is mounted and empty, so nothing to prune there. We deleted /sys/firmware/efi/efivars/dump* (10 files or so), but it didn't fix the issue, the following installation failed again with the same message. efibootmgr -v shows correct output, no binary mess. efibootmgr -c fails with exit code 1 and no error message.
On a different machine (Dell XPS 8500) I reproduced this with RC4 (.git2.3). A workaround is to reboot 30 times (each reboot generates some garbage; my nvram is 128K; YMMV) and trigger firmware garbage collection.
(In reply to comment #36) Martin Holec had exactly the same problem with ThinkPad T520 and F19 Alpha RC4. The only difference is that he had some old UEFI entries he was able to delete. If he deleted one of these old entries, he was then able to create a new UEFI entry.
In the RC3/RC4 kernel, the EFI pstore backend is disabled. That means that it doesn't register with the pstore filesystem and the dump files don't show up under /sys/fs/pstore/ so there is nothing for anaconda to remove. That was inadvertent, however it also means that any kernel crashes done with those kernels won't write out to EFI NVRAM space either. The other issues is that if you enable the option manually, or via kernel parameters, the pstore code itself seems fairly broken when trying to gather records stored in EFI. The mount succeeds, but the record collection fails to complete as it should. That is most likely what Lingzhu hit in comment #33. At this point we avoid the pstore issue by default because the option is disabled by default in the Alpha kernel, but the dump-* files stick around. Other than instructing people to remove them from /sys/firmware/efi/efivarfs/ manually, I'm not sure there's much that can be done.
(In reply to comment #38) > (In reply to comment #36) > Martin Holec had exactly the same problem with ThinkPad T520 and F19 Alpha > RC4. The only difference is that he had some old UEFI entries he was able to > delete. If he deleted one of these old entries, he was then able to create a > new UEFI entry. Then I tried install RC4 again and it was successful.
(In reply to comment #39) > In the RC3/RC4 kernel, the EFI pstore backend is disabled. That means that > it doesn't register with the pstore filesystem and the dump files don't show > up under /sys/fs/pstore/ so there is nothing for anaconda to remove. That > was inadvertent, however it also means that any kernel crashes done with > those kernels won't write out to EFI NVRAM space either. Is EFI pstore backend enabled in current F17/F18 kernels (if I understood it correctly it is)? Shouldn't we disable it too in that case too? > The other issues is that if you enable the option manually, or via kernel > parameters, the pstore code itself seems fairly broken when trying to gather > records stored in EFI. The mount succeeds, but the record collection fails > to complete as it should. That is most likely what Lingzhu hit in comment > #33. > > At this point we avoid the pstore issue by default because the option is > disabled by default in the Alpha kernel, but the dump-* files stick around. > Other than instructing people to remove them from > /sys/firmware/efi/efivarfs/ manually, I'm not sure there's much that can be > done. Reading this bug, #919485 and Googling - it seems like we have to document/recommend manual efivars cleanup (with up to 30 restarts? wow), for some systems firmware update or resetting BIOS settings but that's probably everything we can do for people with entries in efi vars and hitting variants/combinations of efivars related bugs.
Josh, can you please make a guess why our ASUS board (comment 36) can't be cleaned up? We have removed all dump* files, we don't see anything extraordinary, but we still can't create a new UEFI boot entry. $ efibootmgr -v BootCurrent: 0007 Timeout: 3 seconds BootOrder: 0001,0003,0002,0007 Boot0001* Hard Drive BIOS(2,0,00) Boot0002* Network Card BIOS(6,0,00)Realtek PXE B02 D00. Boot0003* CD/DVD Drive BIOS(3,0,00)P3: ATAPI DVD D DH16DYS . Boot0007* UEFI: KingstonDT Elite 3.0 1.01 ACPI(a0341d0,0)PCI(7,0)PCI(0,0)USB(2,0)HD(1,800,1d6e800,646bcc0d-6df7-4774-9b53-3e55ac381dd0) $ ls -l /sys/firmware/efi/efivars total 0 -rw-r--r--. 1 root root 36 Apr 17 2013 AMIMemInfo-43387991-1223-7645-b5bb-aa7675c5c8ef -rw-r--r--. 1 root root 85 Apr 17 2013 AMITSESetup-c811fa38-42c8-4579-a9bb-60e94eddfb34 -rw-r--r--. 1 root root 8 Apr 17 2013 AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e -rw-r--r--. 1 root root 45 Apr 17 2013 Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 69 Apr 17 2013 Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 80 Apr 17 2013 Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 150 Apr 17 2013 Boot0007-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 6 Apr 17 2013 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 8 Apr 17 2013 BootFlow-ef152fb4-7b2f-427d-bdb4-7e0a05826e64 -rw-r--r--. 1 root root 12 Apr 17 2013 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 6 Apr 17 2013 CMOSfailflag-c89dc9c7-5105-472c-a743-b1621e142b41 -rw-r--r--. 1 root root 40 Apr 17 2013 ConErrDev-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 38 Apr 17 2013 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 38 Apr 17 2013 ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 40 Apr 17 2013 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 40 Apr 17 2013 ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 8 Apr 17 2013 CpuS3Resume-30b98b95-dfa3-4501-a3ce-e38c186384a0 -rw-r--r--. 1 root root 7 Apr 17 2013 EfiTime-9d0da369-540b-46f8-85a0-2b5f2c301e15 -rw-r--r--. 1 root root 5 Apr 17 2013 HpcModeBU-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 7 Apr 17 2013 Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 28 Apr 17 2013 LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 12 Apr 17 2013 LegacyDevChecksum-a56074db-65fe-45f7-bd21-2d2bdd8e9652 -rw-r--r--. 1 root root 30 Apr 17 2013 LegacyDevOrder-a56074db-65fe-45f7-bd21-2d2bdd8e9652 -rw-r--r--. 1 root root 588 Apr 17 2013 MemoryS3SaveNv-b1cfc482-4cb2-4cee-9b00-ce2579ec7186 -rw-r--r--. 1 root root 12 Apr 17 2013 MemoryS3SaveVol-0a51b41d-de21-43fe-be27-d6dbc9efd104 -rw-r--r--. 1 root root 12 Apr 17 2013 MemoryS3SaveVolLength-0a51b41d-de21-43fe-be27-d6dbc9efd104 -rw-r--r--. 1 root root 8 Apr 17 2013 MonotonicCounter-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 20 Apr 17 2013 NBMemoryLength-490216c0-076a-44d3-a536-ace05c90e386 -rw-r--r--. 1 root root 7 Apr 17 2013 PNP0400_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 13 Apr 17 2013 PNP0400_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 7 Apr 17 2013 PNP0501_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 13 Apr 17 2013 PNP0501_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 7 Apr 17 2013 PNP0501_1_NV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 13 Apr 17 2013 PNP0501_1_VV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 7 Apr 17 2013 PNP0510_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 13 Apr 17 2013 PNP0510_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 7 Apr 17 2013 PNP0604_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 13 Apr 17 2013 PNP0604_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031 -rw-r--r--. 1 root root 8 Apr 17 2013 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 36 Apr 17 2013 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 486 Apr 17 2013 Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 -rw-r--r--. 1 root root 6 Apr 17 2013 SetupAccFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 -rw-r--r--. 1 root root 13 Apr 17 2013 SetupCpuFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 -rw-r--r--. 1 root root 5 Apr 17 2013 SetupHWMFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 -rw-r--r--. 1 root root 3009 Apr 17 2013 StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824 -rw-r--r--. 1 root root 6 Apr 17 2013 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 12 Apr 17 2013 UMAVar.-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 12 Apr 17 2013 UMAVarB.-8be4df61-93ca-11d2-aa0d-00e098032b8c -rw-r--r--. 1 root root 6 Apr 17 2013 UsbMassDevNum-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 -rw-r--r--. 1 root root 712 Apr 17 2013 VARSTORE_OCMR_SETTINGS_NAME-c05fba7d-7a92-49e0-bcee-233b14dca803 -rw-r--r--. 1 root root 1044 Apr 17 2013 VARSTORE_OCMR_TIMING_SETTINGS_NAME-93c483a1-d3fa-4e92-b437-733b2a346e23 $ efibootmgr -c -L foo; echo $? 1 (and the 'foo' item is not added) Anaconda installations therefore fail. Any ideas?
My only guess is that the firmware did not do garbage collection after you removed the dump vars.
A firmware update "fixed" the issue, we can create new UEFI boot entries now.
*** Bug 949786 has been marked as a duplicate of this bug. ***
kernel-3.9.0-0.rc6.git2.3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Update BIOS to ver. 218 fixed this problem for me. Fedora 19 alpha - Asus Zenbook Prime UX31A.
Same Problem in F19 Beta, the solution was for me to delete the dump-type0* files mentioned in Comment 27, Thanks
Heads up, folks: there's a substantial change to how the kernel handles this whole mess in 19 Final TC1, available at https://dl.fedoraproject.org/pub/alt/stage/19-TC1/ . We're *relatively* confident this should be rather better than what was in 18, Alpha and Beta. If folks could try it out - especially those of you who have systems known to run into this issue a lot - and let us know how it goes, that'd be great. http://mjg59.dreamwidth.org/25091.html explains the technical details of the change that went into TC1.
(In reply to Adam Williamson from comment #49) > Heads up, folks: there's a substantial change to how the kernel handles this > whole mess in 19 Final TC1 ... It still fails on ASUS P8Z68-V/GEN3; original report in bug 949786 "BootLoaderError: failed to set new efi boot target", marked as duplicate of this bug 947142. Default Gnome desktop fresh install from Fedora-19-TC1-x86_64-DVD.iso after "livecd-iso-to-disk --efi" onto USB flash memory. anaconda-19.30.2-1 kernel-3.9.4-300.fc19.x86_64
TC1 was not composed according to the request. The compose request ticket https://fedorahosted.org/rel-eng/ticket/5623 asks for https://koji.fedoraproject.org/koji/buildinfo?buildID=424421 which is kernel-3.9.4-301.fc19 TC1 contains Packages/k/kernel-3.9.4-300.fc19.x86_64.rpm Note the mismatch between requested "-301" and actual "-300".
Right, looks like releng missed the kernel build :( Indeed, it needs to be -301 to have the fix. So, wait for TC2 I guess.
This can also be reproduced by using a VirtualBox VM with EFI activated. Hope this make easier for everybody to test.
I'm kinda reluctant to use EFI virtualization for testing, as it's still pretty early and can differ quite a lot from the implementations on real systems. But it sure beats nothing.
Success! Final TC2 of Fedora-19-x86_64-DVD.iso installs default Gnome desktop successfully after "livecd-iso-to-disk --efi" onto USB flash memory, then booting the install from USB flash memory. The installed system boots successfully. The UEFI boot even inter-operates with an existing UEFI boot of Windows Vista on the same drive. Both systems share the same 100MB EFI System Partition, using different directories 'fedora' and 'Microsoft'. anaconda-19.30.3-1 kernel-3.9.4-301.fc19.x86_64
A UEFI install of Vista?! Isn't that banned under the Geneva Convention? :P Good news, thanks for testing!
(In reply to Adam Williamson from comment #56) > A UEFI install of Vista?! http://www.techpowerup.com/forums/showthread.php?t=167245 "Installing Windows Vista/7 on a GUID Partition Table" (The problems may come later, when "Repair your system" via MS DVD refuses.)
jreiser: I wasn't expressing surprise that such a thing is possible, just that it has not been outlawed by all right-thinking nations ;)
Apparently I just hit this problem trying to install FC19-beta. The reason I say apparently is the anaconda install failed trying to write EFI variables. Clicked on the buttons to open a BZ and it flagged it as a duplicate of this BZ (and dropped all the failing data). This was using Fedora-19-Beta-x86_64-netinst.iso downloaded today from the fedora website and installing on an SGI UV2 system. If what I am hitting is not the same as this BZ, then I need some way to trick anaconda into opening a new BZ with the failing info.
The beta did not have this fix. Please try the TC2 image at https://dl.fedoraproject.org/pub/alt/stage/19-TC2/
FC19-TC2 failed the same way. Same backtrace as BZ 949786. Anaconda refuses to open a new BZ, indicating it is a dup of this one. Note this should not be a case of nvram being full. FWIW, we have a backdoor way of printing EFI variables. These are the variables set after the failure. --------------------------------------- name: Boot0000 name: Boot0001 name: Boot0002 name: Boot0003 name: Boot0004 name: BootOrder name: ConIn name: ConOut name: EDD30 name: GigNVData name: Lang name: LastEnumLang name: LegacyDevOrder name: MTC name: MemoryTypeInformation name: PlatformLang name: RTC name: Setup name: SetupApicMode name: SetupAutoSelectMNOff name: SetupMIoValue name: SetupMvalue name: SetupNIoValue name: SetupNodeType name: SetupNvalue name: copy name: cr name: del name: dir name: dump-type0-1-1370814147 name: dump-type0-10-1370814147 name: dump-type0-11-1370814147 name: dump-type0-2-1370814147 name: dump-type0-3-1370814147 name: dump-type0-4-1370814147 name: dump-type0-5-1370814147 name: dump-type0-6-1370814147 name: dump-type0-7-1370814147 name: dump-type0-8-1370814147 name: dump-type0-9-1370814147 name: md name: rd
Reopening as we are seeing this failure on UV2000 The machine is semi-under beaker ssh root.bos.redhat.com ssh root.eng.bos.redhat.com This breakage is part of what is inhibiting making the machine generally available. This is the point of failure in Anaconda: 1638 continue 1639 1640 rc = self.efibootmgr("-b", slot_id, "-B", 1641 root=ROOT_PATH) 1642 if rc: 1643 -> raise BootLoaderError("failed to remove old efi boot entry") 1644 1645 @property 1646 def efi_dir_as_efifs_dir(self): 1647 ret = self._config_dir.replace('efi/', '') 1648 return "\\" + ret.replace('/', '\\') (Pdb) p slot_id '0003' (Pdb) p slot 'Boot0003*' (Pdb) p _product 'Red Hat Enterprise Linux' (Pdb)
Closing this again - we'll track the SGI issue in #972945.