Created attachment 795970 [details]
File: anaconda-tb

Created attachment 795971 [details]
File: anaconda.log

Created attachment 795972 [details]
File: environ

Created attachment 795973 [details]
File: lsblk_output

Created attachment 795974 [details]
File: nmcli_dev_list

Created attachment 795975 [details]
File: os_info

Created attachment 795976 [details]
File: program.log

Created attachment 795977 [details]
File: storage.log

Created attachment 795978 [details]
File: ifcfg.log

Created attachment 795979 [details]
File: packaging.log

It seems that bug 947142 is back. Petr, can you please try another installation, whether the ASUS firmware can be convinced to run garbage collection at least through repeated installs?

Anaconda devs, could we maybe try to create a new placeholder UEFI variable _before_ the installation and modify the variable at the end, if everything works OK? That would circumvent this issue (or at least it would crash before actually modifying the disk). That of course assumes that modifying an existing variable works every time (we can verify that with kernel people).

Also, would it be possible to display a reasonable error message in this case? This UEFI problem is very obnoxious, common, and it seems we don't have a good solution for it. At least providing the users with short description (and ideally also a link for more detailed page) explaining why this failure happens and what they can do about it would be very helpful for them. Also they wouldn't blame Fedora and Anaconda for this problem.

Next install worked fine, the garbage collector was triggered. I assume this is not a problem of just this single ASUS board, but more will behave the same - sometimes an installation will fail, but a further installation (which might require power off, not just reboot) will work OK. Leaving assigned to Anaconda, this is a badly designed hardware, but we should at least help our users to overcome the obstacle by informing them, if nothing else.

I've just reproduced this bug with F20 Alpha RC4.

I think I've had it twice, but the first time ABRT decided it was a different bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1010203

USB install of F20 Beta, using the netinstall iso.

USB was correctly identified as an UEFI device at boot.

Using the standard partitioning I tried to install to sdf.  The drive had previous partitions from a failed attempt to install F19, which I removed.  I then used the default options for F20.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020-Beta\x20x86_64 rd.live.check quiet
hashmarkername: anaconda
kernel:         3.11.6-301.fc20.x86_64
package:        anaconda-20.25.6-1
product:        Fedora
reason:         BootLoaderError: failed to set new efi boot target
release:        Cannot get release name.
version:        20-Beta

I found a work around that let me install Fedora.  I had to physically detach all other drives from my system, which results in /dev/sdf becoming /dev/sda.

After the install, I plugged all the drives back and everything appears to be working correctly.

(In reply to Paul Robertson from comment #14)
> USB install of F20 Beta, using the netinstall iso.
> 
> USB was correctly identified as an UEFI device at boot.
> 
> Using the standard partitioning I tried to install to sdf.  The drive had
> previous partitions from a failed attempt to install F19, which I removed. 
> I then used the default options for F20.
> 
> cmdline:        /usr/bin/python  /sbin/anaconda
> cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz
> inst.stage2=hd:LABEL=Fedora\x2020-Beta\x20x86_64 rd.live.check quiet
> hashmarkername: anaconda
> kernel:         3.11.6-301.fc20.x86_64
> package:        anaconda-20.25.6-1
> product:        Fedora
> reason:         BootLoaderError: failed to set new efi boot target
> release:        Cannot get release name.
> version:        20-Beta

Tried to use anaconda in XFCE live spin to install a very typical LUKS + LVM setup.

Lenovo X120E that only bombs out on new Fedora Anaconda - all other Linux OSes are peachy.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-XFCE-x86_64-20-Beta- ro rd.live.image quiet rhgb
hashmarkername: anaconda
kernel:         3.11.6-301.fc20.x86_64
other involved packages: python-libs-2.7.5-8.fc20.x86_64
package:        anaconda-20.25.6-1.fc20.x86_64
product:        Fedora
reason:         BootLoaderError: failed to set new efi boot target
release:        Fedora release 20 (Heisenbug)
version:        20

try install Fedora on GPT/UEFI partition. installing grub fail.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=LIVE quiet
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to set new efi boot target
release:        Cannot get release name.
version:        20

Created USB boot disk using dd
dd if=Fedora.iso of=/dev/sdb

Selected the whole disk with automatic partitions.

click install.

Tried it twice.

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 set new efi boot target
release:        Fedora release 20 (Heisenbug)
version:        20

Installing on a Lenovo x120e. 4GB memory, 320GB sata drive.  Replacing the old partitions, and pretty much default layout for the drive, but I increased swap to 8GB, reduced / to 30GB, and the rest to /home.

I have been having problems with this system with the current install of F17 with writing to standard USB drives or SD (No problem to optical, or HD USB devices).

Also changed my location to Detroit, and the hostname to lx120e.htt-consult.com.  And selected Admin tools.

All else was 'default'.

I earlier had this same failure on my new, blank SSD drive that I chose 'standard partitions' and layed out / and /home as ext4 partitions.  Same failure.

Next I am going to try an i386 installation.

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 set new efi boot target
release:        Cannot get release name.
version:        20

Lenovo x120e install onto SSD drive with x86_64 again.  Using the DVD install, but repo to my local server.

I think the problem is either my optical drive, the DVD I burned, or my USB port on this system.  It seems timing related to read the bootloader off the DVD.

Going to keep trying different combinations.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 rd.live.check quiet repo=http://repo.homebase.home.htt/fedora/20/os/x86_64/
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to set new efi boot target
release:        Cannot get release name.
version:        20

Lenovo x86_64 install from netinstal CD using repo=mylocalrepo

Still hangs at installing bootloader.


cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 rd.live.check quiet repo=http://repo.homebase.home.htt/fedora/20/os/x86_64/
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to set new efi boot target
release:        Cannot get release name.
version:        20

Another attempt to install f20 on my lenovo x120e

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 rd.live.check quiet repo=http://repo.homebase.home.htt/fedora/20/os/x86_64/
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to set new efi boot target
release:        Cannot get release name.
version:        20

Created attachment 843899 [details]
anaconda.log

Created attachment 843904 [details]
anaconda-tb

Created attachment 843906 [details]
syslog

Created attachment 843907 [details]
storage.log

Created attachment 843908 [details]
program.log

(In reply to Robert Moskowitz from comment #27)
> program.log

17:08:21,599 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi
17:08:21,793 DEBUG program: Return code: 1

Yet no kernel messages in syslog. I don't know if we need a dmesg -n7 before running the installer, or debug as a boot param, or a debug kernel to get more information on why setting the entry failed. In any case this particular report and its logs should probably be refiled against the kernel since efibootmgr makes kernel calls to do its job.

(In reply to Chris Murphy from comment #28)
> (In reply to Robert Moskowitz from comment #27)
> > program.log
> 
> 17:08:21,599 INFO program: Running... efibootmgr -c -w -L Fedora -d /dev/sda
> -p 1 -l \EFI\fedora\shim.efi
> 17:08:21,793 DEBUG program: Return code: 1
> 
> Yet no kernel messages in syslog. I don't know if we need a dmesg -n7 before
> running the installer, or debug as a boot param, or a debug kernel to get
> more information on why setting the entry failed. In any case this
> particular report and its logs should probably be refiled against the kernel
> since efibootmgr makes kernel calls to do its job.

Let me know if there is a specific test you wish me to perform.  I can make another go at it tomorrow.  It takes ~2hrs for the whole thing.

I suggest filing a new bug against the kernel, with a summary "efibootmgr fails to set new efi boot target when installing Fedora", and a brief description of how to reproduce this. For actual results I'd state that the installer fails to complete due to bootloadererror, and cite the program log lines I did in comment 28. In expected results, state you don't expect the bootloader to fail being installed, but also that syslog should contain kernel messages with more information on the nature of efibootmgr's failure to write to NVRAM.

In additional info, include computer model and firmware revision. And then attach your program.log, anaconda-tb, and syslog.

Also include as attachments the current results of:
efibootmgr -v > efibootmgr.txt
ls /sys/firmware/efi/efivars/ > efivars.txt

I wouldn't try to reproduce until you get more information from kernel maintainers on how to get the information they need.

tried after applying firmware update 1.17 to Lenovo x120e

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 quiet repo=http://repo.homebase.home.htt/fedora/20/os/x86_64/
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to set new efi boot target
release:        Cannot get release name.
version:        20

Standard partitioning, using LVM with passphrase. Similar problem may have occurred with attempt at installation with BTRFS filesystem too.

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 set new efi boot target
release:        Fedora release 20 (Heisenbug)
version:        20

Instaling fedora 20 LXDE spin

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-LXDE-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 set new efi boot target
release:        Fedora release 20 (Heisenbug)
version:        20

*** Bug 1066640 has been marked as a duplicate of this bug. ***

Fujitsu T731: Bios version 1.09

Workaround (Warning: Can brick and will brick some laptops): set kernel command line to 
$(prev_command_line) efi_no_storage_paranoia


Source: https://bbs.archlinux.org/viewtopic.php?id=173710

I actually booted into a previously installation (that kind of worked), but it should work with the install media as well.

In my case, it appears that NVRAM is never garbage collected (multiple reboots/poweroffs between install attempts).

Other things to note: In my case, the Fedora Install replicated the entire EFI boot list (e.g., 0001: Bios, 0002: Recovery ... 0012: Bios, 0013: Recovery) and rendered the previous boot list unselectable from BIOS. It did manage to partially install grub (such that I got the grub command line).

I'm going to try reflashing the BIOS to see if that helps.

Reflashing the BIOS with a force option appears to have fixed it for me. YMMV.

For those having this problem, search for a DOS update utility from the manufacturer, and use that. You will need to figure out out to "force" the update. In my case (Fujitsu T731), the default command for flashing did NOT fix the problem.

Example:
Default command:
-----
PFLASH /bbl /sv /sd CWVV109.ROM
-----
In that case, it updated/flashed everything besides the Variables and the GPNV (whatever that is). 

Modified command:
----
PFLASH /force CWVV109.ROM
----
In this case, it did everything that the default command did and the Variables and GPNV. It is likely that this command will vary between manufactureres (and probably between products) so read the README file if there is one. 
I should note that it appears to have wiped the Product Name and Serial Number from the BIOS. Also, while trying to fix this (prior to flashing), I did remove my ability to enter the BIOS and change boot order.

In installation EFI Boot won't installed

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 set new efi boot target
release:        Cannot get release name.
version:        20

(In reply to antoine from comment #37)
> In installation EFI Boot won't installed

Need dmesg, /tmp/program.log, and ls -l /sys/firmware/efi/efivars/

Should the component for this bug be switched to kernel? I don't see any of these related to the installer proper, either efibootmgr or kernel.

I was keeping this open to remind me about comment 11. There is already a kernel bug for the efivars failure that is causing this.

It happens enough that we should do a bit more to handle it and let the user know what's going on.

OK that makes perfect sense. 

Sister bug 1033354 is (anaconda) failure to remove an existing NVRAM entry. I think it's OK for anaconda to conflate the two when notifying the user since both are "failure to modify NVRAM"; this is consistent with bug 1047993 "Kernel fails to make NVRAM changes for efibootmgr."

The plan to remove, then set, a Fedora boot entry before modifying the target disk would also obviate RFE bug 1049552, so it can be closed.

Setup gave this error during "Startup program installation" stage (or something like that, "Instalowanie programu startowego" in Polish). This may be connected to some HDD problems which result in (g)parted saying "The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes." and after ignoring "The partition's data region doesn't occupy the entire partition.".

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 set new efi boot target
release:        Fedora release 20 (Heisenbug)
version:        20

(In reply to radactfx from comment #42)
That's sufficiently unique that it might be best to investigate in a separate bug. If you can file a new bug and then post its bug ID number in this bug, I'll take a look at it. Please include:

/var/log/anaconda/anaconda.program.log
/var/log/anaconda/anaconda.storage.log
smartctl -i /dev/sdX  # for the target drive
efibootmgr -v

(In reply to Chris Murphy from comment #43)
> (In reply to radactfx from comment #42)
> That's sufficiently unique that it might be best to investigate in a
> separate bug. If you can file a new bug and then post its bug ID number in
> this bug, I'll take a look at it. Please include:
> 
> /var/log/anaconda/anaconda.program.log
> /var/log/anaconda/anaconda.storage.log

Or attach /tmp/anaconda-tb-* from the failed install which has all the logs in one file.

IBM x3550 with UEFI

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2020\x20x86_64 rd.live.check quiet
hashmarkername: anaconda
kernel:         3.11.10-301.fc20.x86_64
package:        anaconda-20.25.15-1
product:        Fedora
reason:         BootLoaderError: failed to set new efi boot target
release:        Cannot get release name.
version:        20

Using Parallels Desktop 10 private beta on OS X 10.9.3. Set the machine type to Fedora and enabled EFI boot in the Parallels options. From what I see, this doesn't seem to necessarily be due to anything Parallels is doing.

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 set new efi boot target
release:        Cannot get release name.
version:        20

(In reply to Evan Kinney from comment #46)
I'd split this out into a separate bug report against the kernel, and include the dmesg from a failed install attempt, and also include the /tmp/program.log which will help indicate whether it was a bootloader entry remove, or add, attempt.

I'm guessing there's a negative interaction between the kernel and the Parallels NVRAM implementation that's causing the efibootmgr add bootloader entry command to fail. So at this point it's an open question whose bug it is.

I'd also suggest filing a bug with Parallels, and cross reference the two bugs.

Happened during install.  No special install settings, very vanilla.

Motherboard is Intel DP67EPB3.

Seems like another instance of Bugzilla id 1006304

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 set new efi boot target
release:        Cannot get release name.
version:        20

(In reply to Mike Pittaro from comment #48)
> Happened during install.  No special install settings, very vanilla.
> 
> Motherboard is Intel DP67EPB3.
> 

The install worked on a second try, with no problems.

Second try was a warm reboot, first was a cold boot.

Ok, this is 'fixed' in the sense that Anaconda will now handle BootLoaderErrors by prompting you to continue the installation or not. You may be able to fix the failure manually.

Problems with setting UEFI variables should probably be dupes against bug