Fedora duplicates in uefi

Hello,

I hope this message finds you well. I am reaching out to seek assistance with an issue I encountered after installing Fedora on my ASUS laptop with UEFI BIOS version 310.

Upon accessing the BIOS, I noticed that there are two identical “Fedora” boot options available. I attempted to manually partition the disk, creating separate /boot/efi and / partitions. My assumption was that one of the options was for UEFI booting, and the other for non-UEFI booting.

Using the “efibootmgr” command I found online, I observed that there are two files associated with these boot options: “shim.efi” and “shimx64.efi.” While I understand the need for multiple files, having two distinct options in the BIOS menu is a bit confusing for a newcomer like me to the Linux environment.

I find it interesting to note that I did not encounter a similar situation when installing Ubuntu on the same laptop. This leads me to wonder why there are two seemingly identical options in the BIOS under Fedora, but not with Ubuntu.

I kindly request guidance on this matter. Could you please explain why there are two seemingly identical options in the BIOS and how I can best manage them? As a Linux novice, I truly appreciate your assistance in helping me understand and resolve this issue.

Thank you for your time and support.

These two files are identical copies

[root@newbox fedora]# diff -s shim.efi shimx64.efi
Files shim.efi and shimx64.efi are identical
[root@newbox fedora]# 

When running efibootmgr you can see which entry was used to boot the system. You should then be able to remove the other duplicate using

efibootmagr  -b #### -B

where "####` is the bootnumber that you want to remove. Or you can just leave it alone.

1 Like

Thank you for your prompt response and valuable insights. I truly appreciate your assistance.

I executed the command you mentioned and found that the two files, “shim.efi” and “shimx64.efi,” are indeed identical copies. Your explanation has clarified the situation for me.

I understand that I can use the “efibootmgr” command to remove one of the duplicate boot entries. However, I’ve noticed that even if I remove one entry, it tends to reappear after a while. Additionally, there was a single instance where the system booted into the GNU GRUB loader instead of automatically launching.

Your guidance has been immensely helpful, and I’m grateful for your support in navigating these nuances. If you have any further recommendations or insights regarding these issues, I would greatly appreciate your advice.

Thank you once again for your time and expertise.

This will happen after a Grub menu modification often. I have even had it after an update of the system before. It is normal and will return to the default booting quicker the next time. Interestingly, I use systemd-boot instead of Grub2 and it does not do this.

1 Like

Thank you for your continued guidance and explanations. Your insights into the behavior after Grub menu modifications and system updates are really helpful in understanding this process.

I’d like to clarify that as a newcomer, I haven’t intentionally modified any bootloader settings like Grub, as you’ve mentioned. However, based on your advice, I have a preference for Fedora to automatically boot without any delays or additional menus like Grub, especially since I don’t have multiple operating systems on my laptop.

Your recommendation to explore systemd-boot as an alternative option is interesting, and I’ll definitely look into it further. Your assistance has been invaluable in helping me navigate these aspects of the Linux environment.

Regarding the issue of duplicate entries in the BIOS, I was wondering if there might be a way to merge these entries into one. Could the duplicate entries be combined to simplify the boot process and avoid any potential confusion? Your insights on this matter would be greatly appreciated.

Thank you for sharing your knowledge and expertise.

@jakfrost I just realize that it also happen to my Fedora 38 fresh installation. The different also on different path to *.efi file as below from efibootmgr:

Boot0002 ... /File(\EFI\FEDORA\SHIMX64.EFI)
Boot0004 ... /File(\EFI\FEDORA\SHIM.EFI)0000424f

I also check folder /boot/efi/EFI/ it’s only contain one fedora folder.

Btw after test, both are working fine and showing GRUB boot list menu. Maybe this is new setup from Fedora 38 installation or something wrong with the Fedora 38 installation setup(?).

I also tested with efibootmgr to Fedora 38 in Gnome Box and it also give me two entries.

You could delete one of them by using efibootmgr, but I suggest not to do it for now. May later if you’re more comfortable with the system.

There should no confusion since we only make the setup once (boot order in BIOS).

1 Like

I seem to see the same, and extra entries do not seem a problem.
The bios sees both on my system as well as being shown in efibootmgr.

ISTR that this has been this way for a long time. Obviously the system only boots from one of those entries but the duplication seems more related to bios and grub configs than any problem.

1 Like

No. I already used Fedora Workstation since 5 years ago and as long as remember it only happen with this Fedora 38 version. May be it only shown if we use fresh install and not upgrading from previous Fedora version.

Btw I just check with Fedora 36 in Gnome Box. It only give one item.

[rizal@fedora ~]$ efibootmgr
BootCurrent: 0003
Timeout: 3 seconds
BootOrder: 0003,0002,0000
Boot0000* UiApp
Boot0002* UEFI Misc Device
Boot0003* Fedora
1 Like

There is/was a bug with how the entries were made with Silverblue some time ago, but that was rectified I though. It dealt with after update getting duplicate entries in the Grub2 menu. They were entries only though, so if there are actual duplicates that duplicate more than the menu entries and on to the boot image, this would be a bug, unless they point to different kernels. Here is a link (https://discussion.fedoraproject.org/t/multiple-entry-on-boot-menu/77275) to a discussion on the same subject at F33 time, but same applies for DNF behaviour and rpm-ostree behaviour at runtime after update or installation. After installation you should have two different entries, one the installed system, the other a rescue mode system. After each update both dnf and rpm-ostree should carry the last two kernels plus the rescue image for a total of three entries.

1 Like

I know that the default with dnf is that it keeps 3 kernel versions plus the rescue image. I cannot speak for rpm-ostree systems.

1 Like