Bug 995834 - (fallback-dupes) Fedora fills up EFI boot screen
Fedora fills up EFI boot screen
Status: NEW
Product: Fedora
Classification: Fedora
Component: shim (Show other bugs)
25
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-11 07:35 EDT by Lukas Tvrdy
Modified: 2017-11-18 17:10 EST (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-22 11:43:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot from BIOS (143.72 KB, image/jpeg)
2013-08-17 05:20 EDT, Lukas Tvrdy
no flags Details

  None (edit)
Description Lukas Tvrdy 2013-08-11 07:35:14 EDT
Description of problem:
I'm dualbooting Fedora with Windows
Fedora adds new entry to efi multiboot option and now 
multiboot screen from BIOS freezes

Version-Release number of selected component (if applicable):
Fedora release 19 (Schrödinger’s Cat)

How reproducible:
Probably every reboot new entry is added

Steps to Reproduce:
1. Reboot PC
2. Check multiboot option screen in BIOS
3. Observe too much entries called Fedora

Actual results:
Too much entries called Fedora

Expected results:
One Fedora entry

Additional info:
HP EliteBook 8750w

Complete output of efibootmgr:
efibootmgr 
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0020,001F,001E,001D,001C,001B,001A,0019,0018,0017,0016,0015,0014,0013,0012,0011,0010,000F,000E,000D,000C,000B,000A,0009,0008,0007,0006,0005,0004,0003,0002,0001,0000
Boot0000* Windows Boot Manager
Boot0001* Fedora
Boot0002* Fedora
Boot0003* Fedora
Boot0004* Fedora
Boot0005* Fedora
Boot0006* Fedora
Boot0007* Fedora
Boot0008* Fedora
Boot0009* Fedora
Boot000A* Fedora
Boot000B* Fedora
Boot000C* Fedora
Boot000D* Fedora
Boot000E* Fedora
Boot000F* Fedora
Boot0010* Fedora
Boot0011* Fedora
Boot0012* Fedora
Boot0013* Fedora
Boot0014* Fedora
Boot0015* Fedora
Boot0016* Fedora
Boot0017* Fedora
Boot0018* Fedora
Boot0019* Fedora
Boot001A* Fedora
Boot001B* Fedora
Boot001C* Fedora
Boot001D* Fedora
Boot001E* Fedora
Boot001F* Fedora
Boot0020* Fedora
Comment 1 Lukas Tvrdy 2013-08-17 05:20:19 EDT
Created attachment 787531 [details]
Screenshot from BIOS

Adding screenshot showing BIOS boot menu
Comment 2 Dang Sananikone 2013-08-21 15:14:12 EDT
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
Comment 3 Lukas Tvrdy 2013-09-20 08:19:29 EDT
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?
Comment 4 Fedora Admin XMLRPC Client 2013-10-09 16:37:54 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Paolo Leoni 2013-12-18 06:40:58 EST
I have this problem with a fresh installation of Fedora 20.

Not present in Fedora 19 for me.
Comment 6 Peter Jones 2013-12-20 11:40:10 EST
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.
Comment 7 Peter Jones 2014-01-31 10:38:17 EST
FYI, https://github.com/mjg59/shim/commit/894a2738d6c843a7b51245fb92bb2f835901e613 should help this scenario.
Comment 8 Roman 2014-02-12 09:49:44 EST
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).
Comment 9 Paolo Leoni 2014-04-08 11:14:38 EDT
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
Comment 10 Michael Shigorin 2014-04-08 13:43:40 EDT
Have you seen shim > 0.7 tagged as of today?
Comment 11 Paolo Leoni 2014-04-09 06:14:07 EDT
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?
Comment 12 Charlweed Hymerfan 2014-04-30 22:57:16 EDT
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
Comment 13 Julian Stecklina 2014-07-28 04:30:52 EDT
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.
Comment 14 Peter Jones 2014-11-06 11:03:51 EST
Can you test this with shim-0.8 ?  I think it should be fixed.
Comment 15 Lukas Tvrdy 2014-11-22 11:43:13 EST
It is fixed for me for quite a long time on Fedora 19 (HP EliteBook 8570w).
Comment 16 Pavlo Rudyi 2016-01-04 13:30:20 EST
The same situation with HP 4530s - https://bugzilla.redhat.com/show_bug.cgi?id=1295124
Comment 17 Jan Kurik 2016-02-24 10:30:24 EST
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
Comment 18 Paolo Leoni 2016-05-18 04:15:16 EDT
I have this problem too. I'm using Fedora 23 64 bit.
Comment 19 shridhar 2016-06-09 11:20:41 EDT
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!!!
Comment 20 Pavlo Rudyi 2016-10-25 08:34:51 EDT
shridhar, very cool! But this is hardcore hack, not the fix :)
Comment 21 Fedora End Of Life 2017-11-16 13:34:19 EST
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.
Comment 22 Andris Pavenis 2017-11-18 17:10:22 EST
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.

Note You need to log in before you can comment on or make changes to this bug.