View Issue Details

IDProjectCategoryView StatusLast Update
0014519CentOS-7shim-x64public2019-02-16 05:58
ReporterAndyLiang Assigned To 
Status assignedResolutionopen 
Product Version7.4.1708 
Summary0014519: Bootx64.efi fails to fetch correct file to boot.
DescriptionBy choosing the bootx64.efi under /EFI/boot/, the system can't boot into OS and with the following message. However, there is no problem on CentOS-7-x86_64-DVD-1611.iso. The bootx64.efi should read the files under /EFI/centos instead of /EFI/boot/.

Failed to open \EFI\BOOT\grubx64.efi - Not Found
Failed to load image \EFI\BOOT\grubx64.efi: Not Found
start_image() returned Not Found
Steps To Reproduce1. Boot into BIOS and directly select the boot block device or using the EFI shell to execute bootx64.efi.
TagsNo tags attached.


child of 0008360 assignedtigalch Tracking bug for 




2018-02-23 07:34


centos.png (121,567 bytes)   
centos.png (121,567 bytes)   
redhat.png (20,588 bytes)   
redhat.png (20,588 bytes)   


2018-04-10 16:46

reporter   ~0031592

I had the same Problem with an VM Template i made for EFI VM's

I hotfixed my Template via
cp -av /boot/efi/EFI/BOOT/fbx64.efi /boot/efi/EFI/BOOT/fallback.efi

with this it all works just fine.

i came across this solution because of:
But if the boot variables are missing or corrupted,
the firmware will eventually try to boot the hard disk as removable
media. In that case, it'll invoke \EFI\BOOT\BOOTX64.EFI (or whatever
filename is right for your architecture.) In that case it'll be in
\EFI\BOOT, so it'll check for fallback.efi

it seems all the grub and shim "stuff" got renamings, and there also were a renaming of the fallback.efi file, but without adjustment of the shim.efi, so the "fallback" for installations where the UEFI/NVRAM never saw the centos, for example if you put your HDD with your centos on it is switched into a new hardware, would not work because of a missing "fallback.efi" file.


2018-04-24 16:19

reporter   ~0031670

seems a dublicate of


2018-04-25 07:21

reporter   ~0031674

Hi Ghosts, thanks for your workaround. My workaround is to directly select the /EFI/centos/shimx64.efi but still has the issue for the duplicate bug as you provided.


2018-04-26 09:28

reporter   ~0031681

i only wanted to restore the old behavior ;)

but, my understanding of the to "14443" ticket is, that this behavior is already on the best way to get fixed
maybe later due to the 7.5 release that already happend on rhel side, but i hope/think its on a good way :D


2018-06-05 05:03

reporter   ~0032011

I saw this bug when installing both CentOS 7.4 1708 x64 and CentOS 7.5 1804 x64 from the DVD iso.

I never got far with 7.4, but in 7.5 the following resolved the problem: Simply to boot into rescue mode and copy grubx64.efi to the path in the error message:

  root@localhost/mnt/sysimage/boot/efi/EFI# cp centos/grubx64.efi BOOT

In case it helps, I'm doing this on a Lenovo Thinkpad T560, BIOS v1.22, UEFI Secure Boot enabled (no legacy boot), bare metal install.


2018-06-05 05:11

reporter   ~0032012

I should clarify, regarding my comment above: I used the DVD.iso's standard installer, which appeared to complete successfully. Then I booted the computer and saw the error message, the same as the one in the description, in text mode soon after the BIOS splash screen.

Issue History

Date Modified Username Field Change
2018-02-23 07:34 AndyLiang New Issue
2018-02-23 07:34 AndyLiang File Added: centos.png
2018-02-23 07:34 AndyLiang File Added: redhat.png
2018-04-10 16:46 ghosts Note Added: 0031592
2018-04-10 16:54 toracat Status new => assigned
2018-04-10 16:58 toracat Category -OTHER => shim
2018-04-24 16:19 ghosts Note Added: 0031670
2018-04-24 16:44 toracat Relationship added child of 0008360
2018-04-25 07:21 AndyLiang Note Added: 0031674
2018-04-26 09:28 ghosts Note Added: 0031681
2018-06-05 05:03 roto Note Added: 0032011
2018-06-05 05:11 roto Note Added: 0032012
2020-08-24 23:33 toracat Category shim => shim-x64