Created attachment 787531 [details]
Screenshot from BIOS

Adding screenshot showing BIOS boot menu

I am also suffering from the same issue.

$ sudo efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 3003,3000,3001,3002,2001,2002,2003
Boot0000  EFI HDD Device (SAMSUNG MZMPC032HBCD-000H1)	ACPI(a0341d0,0)PCI(1f,2)03120a00020000800000HD(1,800,64000,e52c30fc-fb20-4d91-884b-6bce04be6e1a)RC
Boot0001* Fedora	ACPI(a0341d0,0)PCI(1f,2)03120a00020000800000HD(1,800,64000,e52c30fc-fb20-4d91-884b-6bce04be6e1a)File(\EFI\fedora\shim.efi)..
Boot0002* Fedora	ACPI(a0341d0,0)PCI(1f,2)03120a00020000800000HD(1,800,64000,e52c30fc-fb20-4d91-884b-6bce04be6e1a)File(\EFI\fedora\shim.efi)..
Boot0003  Windows Boot Manager	HD(2,c8800,82000,1465fb59-b36a-40a4-a9c2-2c12fd876df6)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...9................
Boot0010* USB Hard Drive (UEFI) - USB     Flash Disk	ACPI(a0341d0,0)PCI(1d,0)USB(0,0)USB(1,0)HD(1,ac,272c,7c18d952)RC
Boot2001* USB Drive (UEFI)	RC
Boot3000* Internal Hard Disk or Solid State Disk	RC
Boot3001* Internal Hard Disk or Solid State Disk	RC
Boot3002* Internal Hard Disk or Solid State Disk	RC
Boot3003* Internal Hard Disk or Solid State Disk	RC


If I boot using boot entry Boot0000 a new boot entry is created that is the same as boot entry Boot0001 every time I boot (in this case the Boot0002 entry was created) . If I boot using boot entry Boot0001 a new boot entry is _not_ created. Both boot entries Boot0000 and Boot0001 boot into F19, except that Boot000 creates a new boot entry.

Here is a file listing of the corresponding boot directories:

[root@spitfire efi]# ls -lR EFI/BOOT/ EFI/fedora
EFI/BOOT/:
total 1396
-rwx------. 1 root root 1363376 Jun 20 15:23 BOOTX64.EFI
-rwx------. 1 root root   65280 Jun 20 15:23 fallback.efi

EFI/fedora:
total 5656
-rwx------. 1 root root     102 Jun 20 15:23 BOOT.CSV
drwx------. 2 root root    4096 Aug 18 20:48 fonts
-rwx------. 1 root root  931176 Jul  2 19:29 gcdx64.efi
-rwx------. 1 root root    5587 Aug 20 19:20 grub.cfg
-rwx------. 1 root root  931176 Jul  2 19:29 grubx64.efi
-rwx------. 1 root root 1184784 Jun 20 15:23 MokManager.efi
-rwx------. 1 root root 1363376 Jun 20 15:23 shim.efi
-rwx------. 1 root root 1354752 Jun 20 15:23 shim-fedora.efi

EFI/fedora/fonts:
total 2504
-rwx------. 1 root root 2560080 Jul  2 19:29 unicode.pf2


The files EFI/BOOT/BOOTX64.EFI and EFI/fedora/shim.efi are the same:

[root@spitfire efi]# cmp EFI/BOOT/BOOTX64.EFI  EFI/fedora/shim.efi 
[root@spitfire efi]# 


Additional information:

$ uname -r
3.10.6-200.fc19.x86_64

$ sudo grep shim /var/log/yum.log 
Jul 09 19:18:13 Updated: shim-unsigned-0.4-1.fc19.x86_64
Jul 09 19:18:13 Updated: shim-0.4-1.fc19.x86_64

$ sudo grep grub /var/log/yum.log 
Jul 05 18:52:12 Updated: 1:grub2-tools-2.00-23.fc19.x86_64
Jul 05 18:53:12 Updated: 1:grub2-efi-2.00-23.fc19.x86_64
Jul 05 18:53:13 Updated: 1:grub2-2.00-23.fc19.x86_64

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk 
├─sda1   8:1    0   400M  0 part 
├─sda2   8:2    0   260M  0 part 
├─sda3   8:3    0   128M  0 part 
├─sda4   8:4    0  68.3G  0 part 
├─sda5   8:5    0 376.5G  0 part /space
└─sda6   8:6    0  20.2G  0 part 
sdb      8:16   0  29.8G  0 disk 
├─sdb1   8:17   0   200M  0 part /boot/efi
└─sdb2   8:18   0  29.6G  0 part /

My hardware specification:

 * HP Touchsmart XT 15-4000ea
 * 500GB HDD on /dev/sda, GPT partitioned with ESP
 * 32GB mSata SSD on /dev/sdb, GPT partitioned with ESP
 * Windows 8 bootloader on /dev/sda ESP
 * F19 on /dev/sdb ESP

New entry is added only when I use first entry.

Now I'm trying to work-around the issue by selecting 1+n entry :)

Few weeks ago Fedora managed to fill up the boot menu completely and I had to recover the grub because of this bug.

Any progress regarding this bug?

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I have this problem with a fresh installation of Fedora 20.

Not present in Fedora 19 for me.

So, what appears to be happening here is that something — possibly the system firmware — is creating some boot entries for your SSD as a generic disk, i.e. as if it were removable, and it's changing the boot order to prefer those, for whatever reason.  When that happens, it boots /EFI/BOOT/BOOTX64.EFI instead of the entry that we've added. /EFI/BOOT/BOOTX64.EFI sees that it is the generic loader, and assumes that the correct boot entry is missing or malformed, and runs /EFI/BOOT/fallback.efi , which then attempts to re-create the appropriate boot entry, and then it boots the new entry. This is not supposed to happen during normal operation, as that entry should only be used if there's no working boot entry.

What's confusing here is that fallback.efi sets the new entry as first in the boot order, so unless the firmware is re-writing those entries and the boot order /very often/, you shouldn't get multiple entries. So what that probably means is that the firmware vendor has created a test to see if boot entries are "valid" that uses some incredibly wrong criteria, and are creating/using fallback entries when that test fails.

Nevertheless, we can probably mitigate this to some extent in a future version of fallback.efi by looking for extant boot entries that match what we /would/ create, and merely changing the order to reflect the existing entry.

FYI, https://github.com/mjg59/shim/commit/894a2738d6c843a7b51245fb92bb2f835901e613 should help this scenario.

Have that issue too. Also with an HP notebook. I am running W7/F20 in dualboot. When I recovered the W7 installation it accidently wiped my efi partition.

I reinstalled shim and grub2 to get the grub bootloader as default. Now I have the same problem too. Each time I reboot into the standard OS bootloader entry, it creates a new boot entry for "Fedora" with shim.efi.

I also figured out, this happens when the systems starts with the OS bootloader entry only. When I choose "Boot from efi file" from boot menu and choosing shim.efi directly, it starts as expected without creating another boot entry.

Another point: I can only boot in UEFI/hybrid-mode, as W7 cannot boot with UEFI native mode (maybe just in my case).

Is there any chance to include Peter's workaround into an updated package? 
shim package in koji is very old:

shim-0.7-1.fc20	pjones	2013-11-06 21:46:12

Have you seen shim > 0.7 tagged as of today?

Not yet. Last version builded is shim-0.7-1 on november 6th, 2013.

Peter Jones: can you build the new package with the patch on koji?

I have this too. I have a dual boot UEFI system. Its a Gigabyte GA-Z87X-HD3 motherboard. After successful install of UEFI Windows and UEFI Fedora 20. I discovered that literally every other boot wold fail. Grub would not even load. The problem is/was a bogus boot entry in UEFI NVRAM. I used efibootmgr to delete it, and verified that it was gone. Two reboots later, and grub failed to load again. After manually specifying the bootloader from the firmware and restarting Fedora 20, I saw the bogus entry was back! 
My  unbootable entry looks like:
ACPI(a0341d0,0)PCI(1f,2)03120a000100ffff0000HD(1,800,64000,960aab70-1e59-4f31-a3b6-d175e512a6a7)File(\EFI\FEDORA\shim.efi)


Name        : grub2
Arch        : x86_64
Epoch       : 1
Version     : 2.00
Release     : 25.fc20
Size        : 1.3 M
Repo        : fedora/20/x86_64
Summary     : Bootloader with support for Linux, Multiboot and more
URL         : http://www.gnu.org/software/grub/
License     : GPLv3+

[root@intrepid ~]# yum info shim
Loaded plugins: langpacks, refresh-packagekit
Installed Packages
Name        : shim
Arch        : x86_64
Version     : 0.7
Release     : 1.fc20
Size        : 5.2 M
Repo        : installed
From repo   : anaconda
Summary     : First-stage UEFI bootloader
URL         : http://www.codon.org.uk/~mjg59/shim/
License     : BSD

Happens to me as well on a HP EliteBook 840, booting from USB. Shim complains about not being able to find BootOrder and adds a new entry every time.

Can you test this with shim-0.8 ?  I think it should be fixed.

It is fixed for me for quite a long time on Fedora 19 (HP EliteBook 8570w).

The same situation with HP 4530s - https://bugzilla.redhat.com/show_bug.cgi?id=1295124

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

I have this problem too. I'm using Fedora 23 64 bit.

I had this problem too. I was manually deleting the automatically created boot entries using efibootmgr -bxxxx -B manually every few days.I am not a programmer but end user using Fedora for last 12 years.
My problem history in short.... I was using dual booting in legacy mode for Fedora 23 and Windows 10 on my Dell vostro 1500 laptop whose motherboard failed, so I bought a new acer aspire e5-574G-50xn laptop with linpus linux preloaded on it. To use dual boot on new laptop I deleted linpus and using live fedora 23 UEFI boot usb loaded Fedora 23 on gpt formated hard disk.The fedora 23 install was succesfully completed.On rebooting I got error saying No Bootable device found! So again turned on pressing F2 to enter in InsydeH20 setup utility v5.0 to manually add UEFI file as trusted executive using some file with *.efi and naming it as Fedora. and I could boot to Fedora, but this started the new problem of adding new entries automatically for fedora. I then installed windows 10 using USB boot disk and entry for microsoft was added.I could select either fedora or windows to boot, but when ever I used to boot selecting fedora the bootloader order would change automatically starting with new boot entry for fedora and I had to delete them manually with efibootmgr, but now no more!
I solved it thus.........
Use setup utility and not efibootmgr to create a new entry for fedora
Turn on and press F2(Bios InsydeH20 Setup utility v5.0)
go to security page.
Go to set supervisor password and press enter(set password)
Go to select an UEFI file as trusted for executing and press enter
A new page appears with listed HDD0
press enter & see if sublist with EFI comes up.
Press enter on Fedora a new list comes up with 
shimx64.efi
grubx64.efi
shim-fedora.efi etc
Press enter and select shim-fedora.efi and give the name "Shimfedorae" and press yes
save and exit
Go back in bios by pressing F2
Go to set supervisor password and set password to blank.
Go to bootpage tab
you should find above named file as last in boot menu.
Bring it to top using F6
save and exit
On reboot delete all entries for fedora using efibootmgr -bxxxx -B and do not delete Shimfedorae
Again reboot and press f2 and delete the Fedora entry from boot menu using supervisor password and delete key
save and exit
The automatic creation of fedora boot entries is gone for ever!!!

shridhar, very cool! But this is hardcore hack, not the fix :)

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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.

Same problem noticed after boot failure (continuous boot loop) after upgrade from Fedora 26 to 27 (I did not check output of efibootmgr without need before and rebooted not often (mostly left on standby instead)

System information:
HP EliteBook 8570w, Intel I7-3610QM, etc

I'm not completely sure that problem was not caused by upgrade to 27. It looks however very similar. The number of accumulated extra boot entries exceeded 200.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.

This bug exists on Fedora 29 too. So, it should be analyzed and fixed.