Same here on acer aspire v nitro

tried many installs

- update from working f26 (UEFI 1 Win10 disk and a separate f26 disk) -> BootOrder not found

- clean install with the 2 disks, format + repartition fedo disk -> BootOrder not found

- clean install with only fedo disk format + repartition -> BootOrder not found

I'm so sad f27 looks so slick ;p I want it so bad !! :)))

here are some logs

________________________


[root@nitro ~]# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
loop0 squashfs
loop1 ext4 Anaconda ecca4143-2913-455c-852d-d66c32f4f25e
├─live-rw ext4 Anaconda ecca4143-2913-455c-852d-d66c32f4f25e /
└─live-base ext4 Anaconda ecca4143-2913-455c-852d-d66c32f4f25e
loop2 DM_snapshot_cow
└─live-rw ext4 Anaconda ecca4143-2913-455c-852d-d66c32f4f25e /
sda
├─sda1 vfat 0533-6B5A /mnt/sysimage/boot/efi
├─sda2 ext4 ee196870-6159-4b59-aeb9-7240a2562308 /mnt/sysimage/boot
├─sda3 swap 4100cf9c-48b2-4df9-be48-3aae85b5728a [SWAP]
└─sda4 ext4 73311e2f-5f3f-46ac-a707-9c8cc368d367 /mnt/sysimage
sdb iso9660 Fedora-WS-Live-27-1-6 2017-11-05-07-38-39-00
├─sdb1 iso9660 Fedora-WS-Live-27-1-6 2017-11-05-07-38-39-00 /run/initramfs/live
├─sdb2 vfat ANACONDA FF9B-8FE5
└─sdb3 hfsplus ANACONDA 095b3e54-6722-3663-9355-20c7d4e06c4b



[root@nitro ~]# efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0003,0002,0001,2001,2002,2003
Boot0000* Fedora    HD(1,GPT,6b132d67-567c-40fb-8e3c-c65fc1a85bd1,0x800,0x64000)/File(\EFI\fedora\shimx64.efi)
Boot0001* Linpus lite    HD(1,MBR,0x2563bf1a,0x1b9d0,0x4664)/File(\EFI\Boot\grubx64.efi)RC
Boot0002* Command Linpus lite    HD(1,MBR,0x2563bf1a,0x1b9d0,0x4664)/File(\EFI\Boot\bootx64.efi)RC
Boot0003* Command Linpus lite    HD(1,GPT,92b9be91-2ada-4c0e-a558-f94cb5dbbab2,0x800,0x64000)/File(\EFI\Boot\bootx64.efi)RC
Boot0004* Unknown Device:     HD(1,GPT,92b9be91-2ada-4c0e-a558-f94cb5dbbab2,0x800,0x64000)/File(\EFI\fedora\shim.efi)RC
Boot0005* Unknown Device:     HD(1,GPT,92b9be91-2ada-4c0e-a558-f94cb5dbbab2,0x800,0x64000)/File(\EFI\fedora\shim.efi)RC
Boot2001* EFI USB Device    RC
Boot2002* EFI DVD/CDROM    RC
Boot2003* EFI Network    RC

Same problem with a clean install on an EliteBook 8470p 
I think the 'Component:' value of this ticket must be changed to grub2 instead of 0ad.

Changed the component to grub2. Thanks.

maybe adjust the title too ?

-> Fedora 27 fails to boot with EFI : BootOrder not found

Adjusted the title... Thank you for the suggestion.

I have the same problem on a Sony VAIO Pro laptop. After a dnf upgrade from Fedora 26 to 27 the system keeps power-cycling and producing the same error message as in  the photo posted by Bogdan Bartos.

Booting with a Fedora 25 live usb, I tried manually adding a boot entry with efibootmgr. This has no result, and if I boot from the usb again the boot entry has disappeared - I think this part (not the bug) may be a Sony thing.

Any suggestions are highly appreciated.

I found a workaround to get Fedora 27 running but I would not call it a solution. First of all my observations about efibootmgr are besides the point - the efi boot is not the problem, the problem starts when efi passes on the responsibility to the bootloader in the efi partition.

What I did was the following transplant:

Step 1: I took the contents of the 'EFI' directory from a healthy booting Fedora 25 machine. The 'EFI' directory is the one that contains a 'BOOT' and a 'fedora' directory - just to clarify as this 'EFI' lives some levels down in another 'efi' directory.

Step 2: On the affected machine, I renamed the 'EFI' directory to 'EFI-original' just to not loose the content.

Step 3: I then copied the entire 'EFI' from the Fedora 25 machine to the affected machine.

Step 4: I overwrote the files 'grub.cfg' and 'grubenv' to ensure the bootloader actually knows what to look for.

Then a restart and the machine now shows the much desired normal grub menu with the option to boot Fedora 27. Booting now proceeds fine. Running dnf update yields some complaints as it tries to update grub-related things and cannot find certain things in expected locations. It seems to overcome these issues. The system now boots fine, the issue seems to have gone.

As I mentioned, this is more of a dirty hack than a solution but perhaps it puts someone on the right track for a real solution or at least helps people out who were stuck on this.

@Fjalar cool move ;p can you give us detail about step 4 plz ?

(In reply to David Berlioz from comment #9)
> @Fjalar cool move ;p can you give us detail about step 4 plz ?

No problems. 

When you copy the entire 'EFI' directory (including subdirs) to the affected machine, it will contain a 'grub.cfg' and 'grubenv' that have bootentries pointing to kernels on the working machine - and which therefore won't work on the affected machine.

Simply overwriting those two files with the versions you kept in the renamed old 'EFI' directory (I called it 'EFI-original') gives it the bootentry for Fedora 27. But now the system will actually reach the point where it hands control over to the grub bootloader so you can actually see the grub bootmenu.

Hope this helps. Let me know if any further clarification or details are necessary.

(In reply to Fjalar from comment #8)
> I found a workaround to get Fedora 27 running but I would not call it a
> solution. First of all my observations about efibootmgr are besides the
> point - the efi boot is not the problem, the problem starts when efi passes
> on the responsibility to the bootloader in the efi partition.
> 
> What I did was the following transplant:
> 
> Step 1: I took the contents of the 'EFI' directory from a healthy booting
> Fedora 25 machine. The 'EFI' directory is the one that contains a 'BOOT' and
> a 'fedora' directory - just to clarify as this 'EFI' lives some levels down
> in another 'efi' directory.
> 
> Step 2: On the affected machine, I renamed the 'EFI' directory to
> 'EFI-original' just to not loose the content.
> 
> Step 3: I then copied the entire 'EFI' from the Fedora 25 machine to the
> affected machine.
> 
> Step 4: I overwrote the files 'grub.cfg' and 'grubenv' to ensure the
> bootloader actually knows what to look for.
> 
> Then a restart and the machine now shows the much desired normal grub menu
> with the option to boot Fedora 27. Booting now proceeds fine. Running dnf
> update yields some complaints as it tries to update grub-related things and
> cannot find certain things in expected locations. It seems to overcome these
> issues. The system now boots fine, the issue seems to have gone.
> 
> As I mentioned, this is more of a dirty hack than a solution but perhaps it
> puts someone on the right track for a real solution or at least helps people
> out who were stuck on this.

Same issue for my Thinkpad-t450s. With that workaround i can boot correctly. I had the same issue when i made a clean f27 install or a f26 to f27 upgrade. Maybe an error in installation procedure?

Same issue on my acer travelmate.

@Fjalar How do I get the contents of the 'EFI' directory if I don't have a healthy booting Fedora machine anymore? :D

The problem lied in the bios of my Acer laptop. Maybe this workaround is helpful for some of you too:

https://www.reddit.com/r/Fedora/comments/7d38pb/f27_systembootorder_not_found_after_update_does/

The problem lied in the bios of my Acer laptop. Maybe this workaround is helpful for some of you too:

https://www.reddit.com/r/Fedora/comments/7d38pb/f27_systembootorder_not_found_after_update_does/

(In reply to spamemichzu from comment #14)
> The problem lied in the bios of my Acer laptop. Maybe this workaround is
> helpful for some of you too:
> 
> https://www.reddit.com/r/Fedora/comments/7d38pb/
> f27_systembootorder_not_found_after_update_does/

In my case the secure boot is already disabled. I resolved coping EFI folder from F26 to F27 skipping grub.cfg and grubenv

Don't get me wrong. The problem lied in the bios although my specific workaround is a bit different:

1) Change Boot Mode from Legacy to UEFI
2) Enable Secure Boot
3) Go to Security -> Secure Boot Mode -> Select an UEFI file as trusted for executing
4) Find and select grubx64.efi

Maybe you guys got lucky. If I select secure boot, I get no option on my Acer to select the file. There should not be a workaround, there should be a fix.

Same here. Did the upgrade today. There seems to be an issue with the shim package shim-x64-13-0.7.x86_64. I uninstalled the package and installed the previous version shim-0.8-10.x86_64 and that resolved the issue.


HP folio 9470m

(In reply to feeble from comment #18)
> Same here. Did the upgrade today. There seems to be an issue with the shim
> package shim-x64-13-0.7.x86_64. I uninstalled the package and installed the
> previous version shim-0.8-10.x86_64 and that resolved the issue.
> 
> 
> HP folio 9470m

Just wanted to add that this occurs when trying to load bootx64.efi and the failback efi. Not sure what is wrong with the binaries.

In reply to comment 17:

> If I select secure boot, I get no option on my Acer to select the file.

@Bogdan: in the Acer Nitro BIOS, you must have the supervisor password set and the secure boot enabled to be able to enter a new UEFI trusted file. You may remove the password after operations at your convenience. Maybe this also applies to the Acer Swift.

I have better results if I move the new UEFI entry at position 1 in boot order (autoboot ok).

I managed to make it work like Patrick suggested. I changed the supervisor password in the BIOS, rebooted, got back in the BIOS, changed the secure boot to UEFI and selected grub as the trusted boot source and named it Fedora and it autoboots properly. I am not sure if this is a fix or a workaround, but it sure makes it work with not much hassle. Thank you guys!

(In reply to spamemichzu from comment #16)
> Don't get me wrong. The problem lied in the bios although my specific
> workaround is a bit different:
> 
> 1) Change Boot Mode from Legacy to UEFI
> 2) Enable Secure Boot
> 3) Go to Security -> Secure Boot Mode -> Select an UEFI file as trusted for
> executing
> 4) Find and select grubx64.efi

I have upgraded to Fedora 27 on an HP EliteBook 8740w, 
and I got the same problem than all people complaining here.

So I have to boot manually, by choosing any *.efi file under
/EFI/fedora/ from my HP UEFI monitor.
 
But it's really boring to do so Each time I powerup my laptop, so I dont found this as a final workaround solution, but just a debug solution, untils a real solution is found !

And apparently some people here have a very simplistic EFI monitor, WITH NO OPTION to navigate in EFI directory to choose an *.efi file !!!!!

So I'm going to try the suggested solution by:
 feeble 2017-11-23 13:48:22 EST 
described above, if secure boot shim.efi is the blocking point!

Does this new SHIM system check some AUTHORYTY certificate somewhere ? And because they are not installed, the shim.efi cannot be used in an other mode than "forced manually" ????

I am in dualboot Windows 2012 and Fedora 27, so disable secure boot in UEFI mode is not an option, otherwise I don't boot in windows mode
And unlike spamemichzu with his Acer laptop, I have no option like:

Security -> Secure Boot Mode -> Select an UEFI file as trusted

On Some more modern laptop (less than 3 years), like ASUS
we can find some certificate on the laptop, provide by Asus , some of them identifies uniquely a given laptop.This is used by Microsoft to detect if you can reinstall a laptop with a given version of windows 8, 10? without reentering activation key.
Is new SHIM implementation using something quite similar ?
Building a kernel key signature with the private key of one of these LAPTOP certificate, and put it under a directory something like :
f66bdc3dfcc84e2fbd5cd4469e75ffb8/4.13.13-300.fc27.x86_64
(this is my situation after installation on 25 Nov 2017, on my disk)
Because under my laptop, this directory created by the installation remains empty !

The situation, before trying any solution suggested above :
=================================
since Fedora 27 is installed on my EliteBook 8740w :

Each time you boot automatically, it  goes into continuous boot loop, and a new entry is added in UEFI monitor, visible with efibootmanager.
So I had to write a script to remove all these unuseful entries , when there is too many ones!

And yes, the only way to boot is to choose the EFI boot manager manually, by navigating in the EFI File system:
any shim.efi, shimx64.efi, grubx64.efi, under EFI/fedora/ is usable to perform that/
But no solution to fix this manual choice for the next reboots !

Ok , I followed the suggested turnaround  suggested above by:
feeble 2017-11-23 13:48:22 EST
And all is working now.
The step:
I first boot manually grop HP EliteBook UEFI monitor, by navigating in EFI file system, to EFI/fedora/shimx64.efi
NOTE
=====
I chose this one because with others, I cannot remove extra "fedora" entries listed by efibootmanager (one added automatically each time i boot the PC !), getting an error:
" ..no space left on device .." (You must understand in UEFI EEPROM !)

If I choose  EFI/BOOT/BOOTX64.EFI
It doesn't boot either, while this file is a copy (I checked it with diff)
of EFI/fedora/shimx64.efi. So this efi prog check itself its PATH, before geving hand to grub2 boot loader first stage !
===================
Once system booted, and I'am logged in,

all the command are in a shell terminal, where you are root: 
   $  su  -  root
    password:
   # 
1)
# dnf remove shim-x64

2)
dowload shim-0.8-10.x86_64.rpm package from any mirror of Fedora 26 package
for example 
# wget http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/26/Everything/x86_64/os/Packages/s/shim-0.8-10.x86_64.rpm

3) install it
dnf install shim-0.8-10.x86_64.rpm

Then reboot,
and after reboot, it works and I have something like:
# efibootmgr
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0004,0000,0001,0002
Boot0000* Notebook Upgrade Bay
Boot0001* Notebook Hard Drive
Boot0002* Notebook Ethernet
Boot0003* Fedora
Boot0004* Fedora
Boot0031* Windows Boot Manager

Subsequent boot, letting on my hp 8740W booting by default with "System upgrade Bay", will work, but UEFI monitor (?) adds a new
    Boot000X* Fedora 
entry, and this entry becomes automatically the first entry 
(like in this example : 0004)in the boot order.

On the reverse with the new shim-x64 package of Fedora 27, this default entry is not added by UEFI monitor BootOrder, 
while extra entry
    Boot000X* Fedora
continue to be added !
Of cause I can add this extra entry with 
efibootmgr -o 4,0,1,2
but at rebbot, this fisrt boot entry : 4
in boot order is removed by UEFI monitor !!!!!!
=========
So what's the problem ?
Was the shim.efi program was signed by Microsoft certificate until Fedora 26 ?
Ans now its self signed ? And that the reason why yhe HP EliteBook 8740w, refuse to add this entry in UEFI boot order ???
I tried to read this:
https://docs-old.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim.html
but its not obvoius to me how exactly its works !!!

Before accepting as only current usable solution: install shim-0.8-10.x86_64.rpm
from Fedora 26,
I tried to install shim-unsigned-x64.x86_64, letting standard package shim-x64 installed too.
and Then after renaming all *.efi file under:
/boot/efi/EFI/fedora/
in *.efi.ref

Then I made a copy of *.efi files provided under /usr/share/shim/13-3.fc27/x64/ by shim-unsigned-x64, 
in the standard directory:
/boot/efi/EFI/fedora/

And at the end, always under /boot/efi/EFI/fedora/
make a copy of shimx64.efi in shim.efi,
because the standard shimx64.efi and shim.efi, provided by shim-x64 are also identical!

And i did not get any better result than with original efi programm, provided by shim-x64!

(In reply to Yves L'ECUYER from comment #25)
> Ok , I followed the suggested turnaround  suggested above by:
> feeble 2017-11-23 13:48:22 EST
> And all is working now.
> The step:
> I first boot manually grop HP EliteBook UEFI monitor, by navigating in EFI
> file system, to EFI/fedora/shimx64.efi
> NOTE
> =====
> I chose this one because with others, I cannot remove extra "fedora" entries
> listed by efibootmanager (one added automatically each time i boot the PC
> !), getting an error:
> " ..no space left on device .." (You must understand in UEFI EEPROM !)
> 
> If I choose  EFI/BOOT/BOOTX64.EFI
> It doesn't boot either, while this file is a copy (I checked it with diff)
> of EFI/fedora/shimx64.efi. So this efi prog check itself its PATH, before
> geving hand to grub2 boot loader first stage !
> ===================
> Once system booted, and I'am logged in,
> 
> all the command are in a shell terminal, where you are root: 
>    $  su  -  root
>     password:
>    # 
> 1)
> # dnf remove shim-x64
> 
> 2)
> dowload shim-0.8-10.x86_64.rpm package from any mirror of Fedora 26 package
> for example 
> # wget
> http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/26/
> Everything/x86_64/os/Packages/s/shim-0.8-10.x86_64.rpm
> 
> 3) install it
> dnf install shim-0.8-10.x86_64.rpm
> 
> Then reboot,
> and after reboot, it works and I have something like:
> # efibootmgr
> BootCurrent: 0000
> Timeout: 10 seconds
> BootOrder: 0004,0000,0001,0002
> Boot0000* Notebook Upgrade Bay
> Boot0001* Notebook Hard Drive
> Boot0002* Notebook Ethernet
> Boot0003* Fedora
> Boot0004* Fedora
> Boot0031* Windows Boot Manager
> 
> Subsequent boot, letting on my hp 8740W booting by default with "System
> upgrade Bay", will work, but UEFI monitor (?) adds a new
>     Boot000X* Fedora 
> entry, and this entry becomes automatically the first entry 
> (like in this example : 0004)in the boot order.
> 
> On the reverse with the new shim-x64 package of Fedora 27, this default
> entry is not added by UEFI monitor BootOrder, 
> while extra entry
>     Boot000X* Fedora
> continue to be added !
> Of cause I can add this extra entry with 
> efibootmgr -o 4,0,1,2
> but at rebbot, this fisrt boot entry : 4
> in boot order is removed by UEFI monitor !!!!!!
> =========
> So what's the problem ?
> Was the shim.efi program was signed by Microsoft certificate until Fedora 26
> ?
> Ans now its self signed ? And that the reason why yhe HP EliteBook 8740w,
> refuse to add this entry in UEFI boot order ???
> I tried to read this:
> https://docs-old.fedoraproject.org/en-US/Fedora/18/html/
> UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-
> Implementation_of_UEFI_Secure_Boot-Shim.html
> but its not obvoius to me how exactly its works !!!

@Yves You have peaked my interest in this. At this point I was just happy to not have to select the efi each time I was booting. I don't think it's the signature. From my limited knowledge, the signature only applies if you have secureboot on. After the upgrade I thought maybe I had inadvertently turned secureboot on. I have seen a similar issue on EL7 servers. You can manually load the EFI prog, but grub will never load. There is definitely something wrong with new shim package. I assume most people are not using the EFI bios and therefore not seeing this issue.

Just read the release notes for the newest shim package. Please refer to rhbz#1497854. Refer to this comment on that bz.

shim-signed-13-0.7 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e2325fb83d

(In reply to spamemichzu from comment #12)
> Same issue on my acer travelmate.
> 
> @Fjalar How do I get the contents of the 'EFI' directory if I don't have a
> healthy booting Fedora machine anymore? :D

I suppose I could send you the files? Let me know if it is still necessary, I haven't been online for a couple of days and it seems there are other suggestions available now. Cheers, F.

(In reply to Fjalar from comment #29)
> (In reply to spamemichzu from comment #12)
> > Same issue on my acer travelmate.
> > 
> > @Fjalar How do I get the contents of the 'EFI' directory if I don't have a
> > healthy booting Fedora machine anymore? :D
> 
> I suppose I could send you the files? Let me know if it is still necessary,
> I haven't been online for a couple of days and it seems there are other
> suggestions available now. Cheers, F.


I found a solution (comment #16), but thanks anyway.

(In reply to feeble from comment #27)
> (In reply to Yves L'ECUYER from comment #25)
> > Ok , I followed the suggested turnaround  suggested above by:
> > feeble 2017-11-23 13:48:22 EST
> > And all is working now.
...


> > =========
> > So what's the problem ?
> > Was the shim.efi program was signed by Microsoft certificate until Fedora 26
> > ?
> > Ans now its self signed ? And that the reason why yhe HP EliteBook 8740w,
> > refuse to add this entry in UEFI boot order ???
> > I tried to read this:
> > https://docs-old.fedoraproject.org/en-US/Fedora/18/html/
> > UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-
> > Implementation_of_UEFI_Secure_Boot-Shim.html
> > but its not obvoius to me how exactly its works !!!
> 
> @Yves You have peaked my interest in this. At this point I was just happy to
> not have to select the efi each time I was booting. I don't think it's the
> signature. From my limited knowledge, the signature only applies if you have
> secureboot on. After the upgrade I thought maybe I had inadvertently turned
> secureboot on. I have seen a similar issue on EL7 servers. You can manually
> load the EFI prog, but grub will never load. There is definitely something
> wrong with new shim package. I assume most people are not using the EFI bios
> and therefore not seeing this issue.

===================================
 IN MY CASE, secure boot IS ENABLED
===================================
because my HP EliteBook is installed in dual mode, with Windows 2012R2
so disabling secureboot is not an option.

I take time to do more investigation:
first the link I give in my previous comment 25:

https://docs-old.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim.html

There you can read at the beginning:
=====================
3.2. Shim
Fedora uses a first-stage boot loader called shim which embeds a self-signed CA certificate. This CA is then used to verify the GRUB 2 boot loader (UEFI version, a PE/COFF program signed with AuthentiCode). Before booting a kernel, GRUB 2 calls back into shim to verify the AuthentiCode signature of the kernel." . . .
====================


So its clear, in shim*.efi, there is a CA certificate, whith at least its public-key, to allow:
1) grub to check it's own signature
2) then grub chek kernel signature with the same public key.

That's mean, Fedora Development or packaging team, get the private key corresponding to that embedded CA certificate with its public key.

OK

SO as long as , you allow any shim*.efi to be loaded through EFI monitor:
1) either navigating manually  in EFI filesystem (allowed by HP EliteBokk UEFI monitor)
2) or declaring a specific PATH to a given *.efi file, marked manually as trusted in monitor( NOT allowed by HP EliteBokk UEFI monitor, but YES on others Manufacturers, as mentioned in others comments in this buzilla report)

The boot process is not stopped.

The presence of self-signed CA certificate, can be checked easily in any file *.efi, brought by package shim.x86_64, shim-x64.x86_64 , or shim-unsigned-x64.x86_64,
whith :
# cd /boot/efi/EFI
# find . | xargs fgrep  "Fedora Secure Boot CA"  *.efi  2> /dev/null
Binary file ./BOOT/BOOTX64.EFI matches
Binary file ./BOOT/fallback.efi matches
Binary file ./fedora/grubx64.efi matches
Binary file ./fedora/MokManager.efi matches
Binary file ./fedora/shim-fedora.efi matches
Binary file ./fedora/shim.efi matches



BUT THE DIFFERENCE is about the program SIGNATURE of shimx64.efi itself.
shim.x86_64, shim-x64.x86_64    ==> shimx64.efi  is SIGNED
shim-unsigned-x64.x86_64        ==> shimx64.efi   is NOT SIGNED

BUT SIGNED WITH WHAT ????
EXPLANATION FOLLOWS .....


============
As i mentioned previously, when HP EliteBook monitor start in SECURE MODE, the UEFI monitor programm, recheck all what it found as "SECURE" EFI program, in EFI file system, and add them with an order number, X, Y, in the boot order, before the standard ones 0,1,2, corresponding to the physical peripherals.

This order is re-checked each time you reboot.
So whatever you are setting with efibootmgr , all this is reset by the UEFI monitor secure policy , as soon as securebot it enabled.

=======
HOW HP UEFI EliteBook monitor considers that an *.efi program is secure ?
ONLY when signed by a Microsoft CA certificate.


Here are some links corroborating this process:
https://unix.stackexchange.com/questions/93787/how-do-i-use-custom-signed-shim-for-secure-boot-fedora
======== related text ==============

How do I use custom-signed shim for secure boot (Fedora)?

I'm not sure whether there's a guide for this but I'd like to know the detailed steps (step-by-step guide perhaps?) involved in achieving the following:

    Re-sign shim with a custom CA private key, but still let shim to use Fedora boot CA public key to verify the kernel components for Secure Boot.
    Replace Microsoft's key stored in the firmware with the corresponding custom CA public key whose private key was used to sign shim.

The main goal that I want to achieve is to replace the built-in Microsoft's CA certificate stored in the firmware, in order to forbid Microsoft-signed OS bootloaders from being executed, and still use the UEFI's secure boot functionality to boot ...
=====================================

In this one, the question is clearly asked, in the little comment at the end of this HTML page :
https://askubuntu.com/questions/342365/what-is-the-difference-between-grubx64-and-shimx64
======== related text ==============

Did MS sign shimx64.efi then? – Mâtt Frëëman Mar 8 '15 at 8:28
Yes, Microsoft signed shimx64.efi -- at least, the version that Ubuntu installs on Secure Boot computers. (There are also unsigned Shim binaries available; or you can install your own Secure Boot keys and sign shimx64.efi yourself to take full control of your computer's Secure Boot process. – Rod Smith Mar 8 '15 at 15:04
====================================



So in Fedora, the requirement is the same for shimx64.efi, otherwise  UEFI Monitor has no mean to check the validity of this *.efi programm
(EXCEPT in UEFI monitor, like the ASUS ones, where you can install extra CA certificate !)

===========CONCLUSION=======================
Something goes wrong in current stable shim.x86_64 package preparation for Fedora 27, and that the reason of this bug !

The signon process of shimx64.efi, was performed by a private key in an expired  Microsoft certificate belonging to Fedora development  team  ?

ONLY DEVELOPPER CAN ANSWER TO THIS !

(In reply to feeble from comment #28)
> Just read the release notes for the newest shim package. Please refer to
> rhbz#1497854. Refer to this comment on that bz.
> 
> shim-signed-13-0.7 has been pushed to the Fedora 27 testing repository. If
> problems still persist, please make note of it in this bug report.
> See https://fedoraproject.org/wiki/QA:Updates_Testing for
> instructions on how to install test updates.
> You can provide feedback for this update here:
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-e2325fb83d

YES I read that for ARM 64 architecture.
But the context of this bug report is not the same as bug1512410
Paul Whalen was just complaining about the lacking of shim.efi in EFI file system.
This is no more the case in new package on line shim-x64-13-0.7, because for architecture x86_64 
 shim.efi and shimx64.efi, exist and have the same content:
# ll /boot/efi/EFI/fedora/shim*
-rwx------. 1 root root 1293304 Oct  4 17:39 /boot/efi/EFI/fedora/shim.efi
-rwx------. 1 root root 1293304 Oct  4 17:39 /boot/efi/EFI/fedora/shimx64.efi
-rwx------. 1 root root 1206896 Oct  4 17:39 /boot/efi/EFI/fedora/shimx64-fedora.efi

[root@encelade utils]# diff /boot/efi/EFI/fedora/shim.efi  /boot/efi/EFI/fedora/shimx64.efi
[root@encelade utils]#
(so their content are identical)
===========
And I suppose that Paul is not working in a secure boot UEFI environment,
so he did not notice the problem with the signature of shim.efi itself ?

To show the listing above I re-installed shim-x64-13-0.7 package after the working bug turnaround solution with Fedora 26 shim package was tested succesfully:
==================proof=====================
# dnf info shim-x64
Failed to synchronize cache for repo 'local', disabling.
Last metadata expiration check: 0:03:41 ago on Mon 04 Dec 2017 06:03:10 PM CET.
Installed Packages
Name         : shim-x64
Version      : 13
Release      : 0.7
Arch         : x86_64
Size         : 7.2 M
Source       : shim-signed-13-0.7.src.rpm
Repo         : @System
From repo    : fedora
Summary      : First-stage UEFI bootloader
URL          : http://github.com/rhboot/shim/
License      : BSD
Description  : Initial UEFI bootloader that handles chaining to a trusted full
             : bootloader under secure boot environments. This package contains
             : the version signed by the UEFI signing service.
===========================================

AND THIS DOES NOT WORK !!!!!!!!!!!!!!!!!!!

As you can notice, for the moment this bugzilla report is like a forum between users
NOBODY in fedora packaging team has reacted to that submit !

In bug reported for ARM 64 architecture,in
 https://bugzilla.redhat.com/show_bug.cgi?id=1497854
made an answer, and now in every architecture we benefit of the updated package:
shim-x64-13-0.7

But the bug with EFI monitor in  secure mode STILL REMAINS

======== NOTE ==============
for information about ARM 64 architecture in Linux developpement, see:
https://stackoverflow.com/questions/31851611/differences-between-arm64-and-aarch64
=============================

To understand what is lacking with shim-x64-13.0-7 to have a correct shim.efi (working in UEFI monitor secure boot environment)
I tried to rebuild it from src file: shim-signed-13-0.7.src.rpm

Once installed, look at /root/rpmbuild/SPEC/shim-signed.spec
Then , to build with :# rpmbuild -bb  shim-signed.spec
you will have to install first the required package to build (as described in *.spec file above)

# rpmbuild -bb shim-signed.spec
error: Failed build dependencies:
    pesign >= 0.112-20.fc27 is needed by shim-signed-13-0.7.x86_64
    shim-unsigned = 0.8-1.fc22 is needed by shim-signed-13-0.7.x86_64
    shim-unsigned-ia32 = 13-3.fc27 is needed by shim-signed-13-0.7.x86_64
    shim-unsigned-x64 = 13-3.fc27 is needed by shim-signed-13-0.7.x86_64


Ok I just installed
pesign
hoping to find some information about the signature tied with shimx64.efi , shim.efi

because , if you look at *.specfile, you can see:
======= SPEC file =================
....
Source12:       shimx64.efi
Source13:       shimx64-signed.efi
...

%ifarch x86_64
%do_install -a x64 -A X64 -b %{SOURCE0}
%do_install -a ia32 -A IA32 -b %{SOURCE2}
install -m 0644 %{SOURCE2} $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/BOOT.CSV
install -m 0644 $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/mmx64.efi $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/MokManager.efi
install -m 0644 %{SOURCE13} $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/shim.efi
install -m 0644 %{SOURCE13} $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/shimx64.efi
install -m 0644 %{SOURCE13} $RPM_BUILD_ROOT/boot/efi/EFI/BOOT/BOOTX64.EFI
install -m 0644 $RPM_BUILD_ROOT/boot/efi/EFI/BOOT/fbx64.efi $RPM_BUILD_ROOT/boot/efi/EFI/BOOT/fallback.efi
%endif
...
========================================
So shim.efi, shimx64.efi and BOOTX64.EFI
are simple copy of Source13, brought by shim-signed-13-0.7.src.rpm

NORMAL:
that binary must be signed normally by private key associated to a Microsoft certificate, having also his public key
AND only Linux distribution development team have that !

===============NOTE====================
after shim-x64-13.0-7 installation we have:

[root@encelade fedora]# pwd
/boot/efi/EFI/fedora

[root@encelade fedora]# pesign --show-signature -i shim.efi
---------------------------------------------
certificate address is 0x7fe91fcdaa18
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------
[root@encelade fedora]#

===============END NOTE====================


If you look in *.spec file all the modification performed on this package, since the one : shim-0.8-10 , used in Fedora 26
we see:

======= SPEC file =================
%changelog
* Wed Oct 04 2017 Peter Jones <pjones> - 13-0.7
- Make /boot/efi/EFI/fedora/shim.efi still exist on aarch64 as well.
  Resolves: rhbz#1497854

* Tue Sep 19 2017 Peter Jones <pjones> - 13-0.6
- Fix binary format issue on Aarch64
  Resolves: rhbz#1489604

* Tue Sep 05 2017 Peter Jones <pjones> - 13-0.5
- Make /boot/efi/EFI/fedora/shim.efi still exist on x86_64, since some
  machines have boot entries that point to it.

* Tue Aug 29 2017 Peter Jones <pjones> - 13-0.4
- Make our provides not get silently ignore by rpmbuild...

* Fri Aug 25 2017 Peter Jones <pjones> - 13-0.3
- x64: use the new fbx64.efi and mm64.efi as fallback.efi and MokManager.efi
- Provide: "shim" in x64 and aa64 builds

* Thu Aug 24 2017 Peter Jones <pjones> - 13-0.2
- Obsolete old shim builds.

* Tue Aug 22 2017 Peter Jones <pjones> - 13-0.1
- Initial (partially unsigned) build for multi-arch support on x64/ia32.

* Thu Mar 23 2017 Petr �| abata <contyk> - 0.8-9
- Re-enable dist tag for module builds
=====================================

SO IN 13-0.5 release, shim.efi is re-introduced.
But nothing about signature of file:
shimx64-signed.efi
+++++++++++++++++++++++++++++++++++
IS THERE A DIFFERENCE between :
           this file brought by shim-x64.13-0.7
and     the one brought by shim-0.8-10.x86_64 from Fedora 26     ????
+++++++++++++++++++++++++++++++++++

To answer this I de-installed the first and re-installed the second
check:
# rpm -q --whatprovides /boot/efi/EFI/fedora/shim.efi
shim-0.8-10.x86_64

# ll  /boot/efi/EFI/fedora/shim.efi
-rwx------. 1 root root 1293304 Aug 15  2016 /boot/efi/EFI/fedora/shim.efi

Now I go in /root/rpmbuild/SOURCES, where we find the famous file :
brought by shim-signed-13-0.7.src.rpm installation:
[root@encelade SOURCES]# pwd
/root/rpmbuild/SOURCES

[root@encelade SOURCES]# ll *.efi
-rw-rw-r--. 1 root root  868376 Sep 19 21:54 shimaa64.efi
-rw-rw-r--. 1 root root  967681 Sep 19 21:54 shimia32.efi
-rw-rw-r--. 1 root root 1204515 Sep 19 21:54 shimx64.efi
-rw-rw-r--. 1 root root 1293304 Aug 21 23:46 shimx64-signed.efi
[root@encelade SOURCES]#

AND NOW THE COMPARISON:

[root@encelade SOURCES]# diff  /boot/efi/EFI/fedora/shim.efi  shimx64-signed.efi
[root@encelade SOURCES]#
++++++++++++++++++++++++++
 So the answer is  NO, it's not a problem with shim.efi signature 
++++++++++++++++++++++++++

BUT
when I switched several time between
        shim-0.8-10.x86_64
and
        shim-x64-13-0.7

I noticed with the last one, installation of dependencies, not required by the first.
And this dependencies are removed if you remove shim-x64-13-0.7

---------------
Here is the process:


++++++++++++++++++++=
# dnf install shim-x64
Failed to synchronize cache for repo 'local', disabling.
Last metadata expiration check: 2:32:45 ago on Mon 04 Dec 2017 06:03:10 PM CET.
Dependencies resolved.
================================================================================
 Package           Arch            Version               Repository        Size
================================================================================
Installing:
 shim-x64          x86_64          13-0.7                fedora           1.3 M
Installing dependencies:
 dbxtool           x86_64          8-3.fc27              fedora            35 k
 efivar            x86_64          32-2.fc27             updates           30 k

Transaction Summary
================================================================================
Install  3 Packages

Total download size: 1.4 M
Installed size: 7.3 M
Is this ok [y/N]:y
++++++++++++++++++++++++++++++++
SO THE PROBLEM Could come from
dbxtool or efivar, note used until now in stable Fedora release.

About this extra package:
=================
[root@encelade RHF27_i686_x86_64_addons]# dnf info efivar
Failed to synchronize cache for repo 'local', disabling.
Last metadata expiration check: 2:37:13 ago on Mon 04 Dec 2017 06:03:10 PM CET.
Installed Packages
Name         : efivar
Version      : 32
Release      : 2.fc27
Arch         : x86_64
Size         : 46 k
Source       : efivar-32-2.fc27.src.rpm
Repo         : @System
From repo    : updates
Summary      : Tools to manage UEFI variables
URL          : https://github.com/rhboot/efivar
License      : LGPLv2.1
Description  : efivar provides a simple command line interface to the UEFI
             : variable facility.

[root@encelade RHF27_i686_x86_64_addons]# dnf info dbxtool
Failed to synchronize cache for repo 'local', disabling.
Last metadata expiration check: 2:37:39 ago on Mon 04 Dec 2017 06:03:10 PM CET.
Installed Packages
Name         : dbxtool
Version      : 8
Release      : 3.fc27
Arch         : x86_64
Size         : 53 k
Source       : dbxtool-8-3.fc27.src.rpm
Repo         : @System
From repo    : fedora
Summary      : Secure Boot DBX updater
URL          : https://github.com/vathpela/dbxtool
License      : GPLv2
Description  : This package contains DBX updates for UEFI Secure Boot.

[root@encelade RHF27_i686_x86_64_addons]#

=================
This package are quite simple, mainly they provide:
efivar-32-2.fc27   --> /usr/bin/efivar
dbxtool-8-3.fc27        --> /usr/bin/dbxtool
                                --> /usr/lib/systemd/system/dbxtool.service
So most probably the matter is from dbxtool  ???

Just after installation:
=========
# systemctl status dbxtool.service
* dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Dec 04 18:56:28 encelade systemd[1]: Started Secure Boot DBX (blacklist) updater.
Dec 04 19:08:09 encelade systemd[1]: Stopped Secure Boot DBX (blacklist) updater.
# so the service was started once, and stopped apparently without any errors

Does this tries, to write something in UEFI eeprom monitor ????

I tried to disable this service:
# systemctl disable  dbxtool.service
Removed /etc/systemd/system/multi-user.target.wants/dbxtool.service.

And reboot
and nothing change. I had again to boot by navigating in EFI file system from HP UEFI monitor, by default only: DBXUpdate-2016-08-09-13-16-00.bin


Anyway this service launched only once at shim-x64 installation,
 seems only to apply any *.bin file in /usr/share/dbxtool/

And normally when I deinstall
shim-x64-13-0.7, to fallback to fedora 26 package, the UEFI database remain the same ??

OR I'm wrong the data base is not the one, in UEFI monitor, but somewhere else in EFI file system, and shim --> grub boot process abort because of this database ??


I CANNOT SOLVE THIS PROBLEM BY MYSELF. we require help from someone understanding well,
how boot EFI process use  EFI variables !!!!

Hello all,
I was able to solve it by using the suggestion from Comment #18.
What I did:
- wget ftp://mirror.switch.ch/pool/4/mirror/fedora/linux/releases/26/Workstation/x86_64/os/Packages/s/shim-0.8-10.x86_64.rpm
- rpm -e --justdb --nodeps shim-x64-13-0.7.x86_64
- rpm -ivh shim-0.8-10.x86_64.rpm

After a reboot the system started without any problem.

Nevertheless I would be interested to know what is the source problem of shim-x64-13-0.7.x86_64.

Thank you all for the helpful comments.

Acer Aspire V Nitro, same problem.  Adding the grubx64.efi file didn't work, but downgrading to the F26 shim package did.

@josh I have the same laptop (it's my spare and game laptop) : can you post a step by step to downgrade the packet please ?

@David Berlioz - it's pretty simple.  

Boot to a F27 Live DVD
Download the shim RPM from a F26 repository using firefox (or use wget as in comment #34)
mount <root partition> /mnt
mount </boot partition> /mnt/boot
mount </boot/efi partition> /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
copy the downloaded RPM to /mnt/tmp
chroot /mnt
yum remove shim-x64
yum install /tmp/shim*.rpm
exit
reboot

THe hardest part is getting the F27 Live DVD burned if you can't boot the machine...

Hello,

I ran into the same problem on my Lenovo Thinkpad T430 (Model 2349GCG) after upgrading F26 to F27:

> System BootOrder not fond. Initializing defaults.
> Creating boot entry "Boot0000" with label Fedora for file "\EFI\fedora\shimx64.efi"
> Reset System

Did the upgrade to F27 today. Nothing really useful to add for the developer (beside the fact that it is still broken with shim-x64-13-0.7.x86_64 as it is available on 2018-Jan-06). Relevant firmware settings:

* "UEFI only" was and still is enabled
* "Secure Boot" was and still is disabled

Side note: These reboots also filled up the EFI space, therefore I got a warning when entering the Laptop's Firmware Setup:

> Error: The non-volatile system UEFI variable storage is nearly full

I do not go into details on the latter as the space was cleaned up automatically after having a working setup again. But https://superuser.com/questions/1081537/ might be useful if somebody is not that lucky.

Hello again,

First thing I tried: update UEFI (did not solve anything but I wanted to update UEFI anyways because of security fixes). I updated to newest T430 Firmware Release to make sure it is not only caused by outdated firmware:
 
    Package  (ID)     UEFI BIOS  (BIOS ID)  ECP  (ECP ID)       Rev.  Issue Date
    ----------------  --------------------  ----------------    ----  -----------
    2.74  (G1UJ41UC)  2.74  (G1ETB4WW)      1.13  (G1HT35WW)    01    2017/09/29

Links for reference:
- README for UEFI Firmware Release 2.74: https://download.lenovo.com/pccbbs/mobiles/g1uj41uc.txt
- Software Center, UEFI Download T430: https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t430/2349/2349gcg/downloads



Workaround (not a fix): I booted F27 netinstall live USB key in rescue mode, removed "shim-x64" and installed the older "shim" package from F26 (as suggested above).

I have a cryptsetup/LUKS encrypted system. Creating a chrooted environment from the graphical Live system in combination with DNF is a bit more sophisticated (so not only cryptsetup luksOpen '/dev/sdaX' 'encrypted-sdaX', create mountpoints and chroot into, ...). As I was lazy and my laptop has a working Ethernet Port: Rescue Mode... to the rescue.

Using the Fedora Netinstaller on USB key with rescue mode is the easiest way, as it setups the disk properly and enables you to simply install packages on your local disk without hassle. For the record:

1) Created the USB Key with the following command (cf. https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB):
   su -c 'dd if=/path/to/Fedora-WS27-netinstall.iso of=/dev/sdX bs=8M oflag=direct'

2) Booted USB key -> Troubleshooting -> Rescue a Fedora-System -> Option "1) Continue"

3) chroot /mnt/sysimage
   [ You are now on the system installed on your machine, not some kind of
     live media ]

4) dnf remove shim-x64
   [ have a glimpse on the dependencies, this might remove e.g. "gnome-software".
     Just run "dnf install gnome-software" later if needed ]

5) curl -o /tmp/shim-0.8-10.x86_64.rpm -L https://bitly.com/2CJ0ohV
    [ https://bitly.com/2CJ0ohV points to a free.fr F26 mirror ]
   sha256sum /tmp/shim-0.8-10.x86_64.rpm 
     b72a623455d513c3f05eb9520a126f9bf8dfce677d8e3710098dd4b7b22ea890  /tmp/shim-0.8-10.x86_64.rpm
   sha1sum /tmp/shim-0.8-10.x86_64.rpm 
     6802df2fb75831e0d75d54c4b3b3c4ecf66fc60b  /tmp/shim-0.8-10.x86_64.rpm
   dnf install /tmp/shim-0.8-10.x86_64.rpm
   [ optional: "dnf install gnome-software" ]
   rm /tmp/shim-0.8-10.x86_64.rpm
   exit
   systemctl reboot

The System should come up correctly again. Resetting SELinux context happens on first boot because you bootet up in rescue mode. This takes some time but is not harmful in any way.

If you have to adapt the commands above for your setup, the following might be useful:
- https://unix.stackexchange.com/questions/267155/
- https://ask.fedoraproject.org/en/question/53127/
- https://ask.fedoraproject.org/en/question/115228/
- https://unix.stackexchange.com/questions/72592/
- https://wiki.sabayon.org/index.php?title=HOWTO:_chroot_from_a_LiveCD
- https://wiki.sabayon.org/index.php?title=HOWTO:_Mount_LVM
- https://wiki.sabayon.org/index.php?title=HOWTO:_Mount_Encrypted_Partition


Regards,
Andreas

Big Up @josh worked like a charm

Had no pb booting on a live image have a nice usb stick that works good !

Could be convenient to add this in /etc/dnf/dnf.conf

exclude=shim-x64

(In reply to Andreas Haerter from comment #39)
> Hello again,
> 
> First thing I tried: update UEFI (did not solve anything but I wanted to
> update UEFI anyways because of security fixes). I updated to newest T430
> Firmware Release to make sure it is not only caused by outdated firmware:
>  
>     Package  (ID)     UEFI BIOS  (BIOS ID)  ECP  (ECP ID)       Rev.  Issue
> Date
>     ----------------  --------------------  ----------------    ---- 
> -----------
>     2.74  (G1UJ41UC)  2.74  (G1ETB4WW)      1.13  (G1HT35WW)    01   
> 2017/09/29
> 
> Links for reference:
> - README for UEFI Firmware Release 2.74:
> https://download.lenovo.com/pccbbs/mobiles/g1uj41uc.txt
> - Software Center, UEFI Download T430:
> https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/thinkpad-t-
> series-laptops/thinkpad-t430/2349/2349gcg/downloads
> 
> 
> 
> Workaround (not a fix): I booted F27 netinstall live USB key in rescue mode,
> removed "shim-x64" and installed the older "shim" package from F26 (as
> suggested above).
> 
> I have a cryptsetup/LUKS encrypted system. Creating a chrooted environment
> from the graphical Live system in combination with DNF is a bit more
> sophisticated (so not only cryptsetup luksOpen '/dev/sdaX' 'encrypted-sdaX',
> create mountpoints and chroot into, ...). As I was lazy and my laptop has a
> working Ethernet Port: Rescue Mode... to the rescue.
> 
> Using the Fedora Netinstaller on USB key with rescue mode is the easiest
> way, as it setups the disk properly and enables you to simply install
> packages on your local disk without hassle. For the record:
> 
> 1) Created the USB Key with the following command (cf.
> https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB):
>    su -c 'dd if=/path/to/Fedora-WS27-netinstall.iso of=/dev/sdX bs=8M
> oflag=direct'
> 
> 2) Booted USB key -> Troubleshooting -> Rescue a Fedora-System -> Option "1)
> Continue"
> 
> 3) chroot /mnt/sysimage
>    [ You are now on the system installed on your machine, not some kind of
>      live media ]
> 
> 4) dnf remove shim-x64
>    [ have a glimpse on the dependencies, this might remove e.g.
> "gnome-software".
>      Just run "dnf install gnome-software" later if needed ]
> 
> 5) curl -o /tmp/shim-0.8-10.x86_64.rpm -L https://bitly.com/2CJ0ohV
>     [ https://bitly.com/2CJ0ohV points to a free.fr F26 mirror ]
>    sha256sum /tmp/shim-0.8-10.x86_64.rpm 
>      b72a623455d513c3f05eb9520a126f9bf8dfce677d8e3710098dd4b7b22ea890 
> /tmp/shim-0.8-10.x86_64.rpm
>    sha1sum /tmp/shim-0.8-10.x86_64.rpm 
>      6802df2fb75831e0d75d54c4b3b3c4ecf66fc60b  /tmp/shim-0.8-10.x86_64.rpm
>    dnf install /tmp/shim-0.8-10.x86_64.rpm
>    [ optional: "dnf install gnome-software" ]
>    rm /tmp/shim-0.8-10.x86_64.rpm
>    exit
>    systemctl reboot
> 
> The System should come up correctly again. Resetting SELinux context happens
> on first boot because you bootet up in rescue mode. This takes some time but
> is not harmful in any way.
> 
> If you have to adapt the commands above for your setup, the following might
> be useful:
> - https://unix.stackexchange.com/questions/267155/
> - https://ask.fedoraproject.org/en/question/53127/
> - https://ask.fedoraproject.org/en/question/115228/
> - https://unix.stackexchange.com/questions/72592/
> - https://wiki.sabayon.org/index.php?title=HOWTO:_chroot_from_a_LiveCD
> - https://wiki.sabayon.org/index.php?title=HOWTO:_Mount_LVM
> - https://wiki.sabayon.org/index.php?title=HOWTO:_Mount_Encrypted_Partition
> 
> 
> Regards,
> Andreas

works correctly for me after a clean F26 install (only OS) and upgraded to F27. Same issue with a directly F27 install

I also encountered this problem with my Acer Aspire E 15 notebook.

I managed to boot into Fedora 27 without downgrading shim when I followed the instructions from comment #16.

Out of curiosity, I also selected the UEFI file shimx64-fedora.efi, which comes with shim-x64-13.0.7, as trusted for executing and was able to boot, too.

However, the entry for shimx64.efi still remained the default. Since I could neither delete the entry for shimx64.efi nor change the boot order in efibootmgr (changes were shown in efibootmgr, but didn’t survive reboot), I selected in the UEFI menu Security -> Restore Secure Boot to Factory Default (also requires a supervisor password). This deletes all custom boot menu entries.

After a reboot (changes take effect only after reboot), I selected the shimx64-fedora.efi as trusted for executing, which is now my default boot entry so that I needn’t manually select an entry from the boot menu any more.

Then I selected shimx64.efi, which had not worked before, as trusted for executing, and it booted successfully. It seems that it is necessary to clear the boot menu (e.g. by restoring the factory defaults) to remove the broken entry for shimx64.efi from the boot menu.

However, after factory defaults are restored, all of these UEFI files successfully boot when selected as trusted for executing:
* shimx64.efi
* shimx64-fedora.efi
* grubx64.efi
I didn’t try shim.efi, but I would expect that it also works.

Interestingly, shim.efi and shimx64.efi from shim-x64-13.0.7 have the same SHA1 sum as shim.efi from shim-0.8-10. Since, according to some comments, the older shim, that has the same content as the new one, seems to work, there must be another difference between these files.

This difference is the timestamp: all UEFI files from shim-0.8-10 have a timestamp from 2016-08-15, whereas all UEFI files from shim-x64-13-0.7 have a timestamp from 2017-10-04.

Maybe the UEFI checks if the timestamp of a trusted UEFI file has changed, and, if so, does not trust it anymore? If this is the actual problem, a simple "touch -r" should solve it. Can anyone confirm this?

Reading the last question of  Daniel Woschée  comment 43,
I tried the suggestion.
So I started first with "touch -r", but the problem was, that to get the reference time stamps, you need to install FC26 shim-0.8-10, and then made a copy with cp -p , in a reference directory outside EFI file system (because when booting, all the EFI file system is explored - we shall see later by WHAT !), ans if you just rename the EFI/BOOT and EFI/fedora directory before installing shim-x64-13.0.7, you get artifact because two shim.EFI are detected !!
So I moved this BOOT and fedora directories in a tempo directory in my ext4 main file system, and just checked the time date of all the *.efi file from this backup directory with ls -l. It looked OK, so I removed shim-0.8-10, and then installed shim-x64-13.0.7 with dnf, so its dependencies are installed too.
In my case :
dbxtool, and efivars
My reference file was copied under :
UTILS0=/utils/RHF27_i686_x86_64_addons/EFI/fedora
So I defined this
export REF0=$UTILS0/shim.efi
AND made the change on Fedora 27 files:
#  cd /boot/efi/EFI/
# touch -r $REF0  BOOT/*
# cd fedora
# touch -r $REF0 BOOT.CSV* MokManager.efi shim.efi shim-fedora.efi

AND tried to boot as is!
I was not working !
=========
So reinstalled shim-0.8-10, And chek deeper the time stamps:

# stat /boot/efi/EFI/fedora/shim.efi
  File: /boot/efi/EFI/fedora/shim.efi
  Size: 1293304         Blocks: 2528       IO Block: 8192   regular file
Device: 801h/2049d      Inode: 1533        Links: 1
Access: (0700/-rwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:dosfs_t:s0
Access: 2016-08-15 18:31:50.000000000 +0200
Modify: 2016-08-15 18:31:50.000000000 +0200
Change: 2018-02-27 21:19:48.000000000 +0100
 Birth: -

Unfortunately , the backup reference in $UTILS0 whith cp -r, or cpio -pumd, does not get the same Access time, and even if you change the time stamps of the backup reference file, whith
# export REF0=/boot/efi/EFI/fedora/shim.efi
and you applies 
# touch -r $REF0 ... to all file in $UTILS0 and $UTILS0/../BOOT
As soon as you have rebooted, the supposed backup reference file have their Acces time stamp modified 
(only Modified time stamps remain at 2016-08-15 18:31:50.)
So at the end I used this script (/root/bin/reset_efi_timestamp):
==========
REF_TS="201608151831.50"
for F in \
/boot/efi/EFI/BOOT/BOOTX64.EFI \
/boot/efi/EFI/BOOT/fallback.efi \
/boot/efi/EFI/fedora/BOOT.CSV \
/boot/efi/EFI/fedora/MokManager.efi \
/boot/efi/EFI/fedora/shim.efi \
/boot/efi/EFI/fedora/shim64.efi \
/boot/efi/EFI/fedora/shim-fedora.efi
do
        if [ -f $F ]
        then
                echo "adjust time stamp on:"
                echo "$F"
                touch  -t 201608151831.50 "$F"
                stat "$F" | egrep 'File:|Access:|Modify:'
        fi
done
===================
to quicly reset the time stamps once shim-x64-13.0.7 and it dependence were installed.

and then NO SUCCES at boot on my HP EliteBook 8740W

I even try after this install, to remove only shim-x64-13.0.7 with rpm -i (because dnf remove, remove also its dependencies), 
and then reinstall only shim-0.8-10.x86_64.rpm,
  with dbxtool, and efivars always installed,
  show a successful EFI  boot!!!
==========
So now I decided to go on further experimentation to understand how
my HP EliteBook 8740W boot in UEFI mode
in comparison with 
my Lenovo ThinkCenter M700.

The last one is booting perfectly, after an upgrade from Fedora 25 to Fedora 27
so with shim-x64-13.0.7 and its dependency installed.

I explain all that in my next comment, and all the tests that helped me to understand which code is wrong for old PC related here by people in some bad experience , while was working fine until Fedora 26 included !

So I checked the history on my HP elitebook from the beginning:

What I supposed to be an UEFI secure boot was actually NOT !
I just supposed that because each time I booted my PC, I could see a message like:

System Boot Order not Found, Initailizing default
Creating boot entry "Boot00<xx>" with label "Fedora" for file ...

(its difficult to read, so short is the show of this message: < 1s,
 so I made a video of my screen during booting, 
  and passed it in VLC in slow motion!)
And after the grubs menu appears.

NOTICE that I modified the EFI/fedora/grub.cfg
=======
if loadfont $font ; then
 ...
  insmod png
  insmod gettext

  set gfxmode=1024x768x32,auto
  insmod gfxterm
  terminal_output gfxterm
else 
 ...
fi
 ...
  ( and some lines below)
if background_image /EFI/fedora/FED24STARBG-1024x768.png ; then
  #set color_normal=black/black
  #set color_highlight=magenta/black
  set color_normal=cyan/black
  #set color_highlight=magenta/black
  set color_highlight=yellow/black
else
  set color_normal=cyan/blue
  set color_highlight=white/blue
fi
set timeout=-1
================
So that my grub choice is over a colored backgound.
( this required to have some grub module inside EFI partition, 
in particular png, because ext2 module is loaded too late, and the EFI first stage loader is not able to search them in Linux ext2/3/4 file system:
I made a complete copy of all *.mod in EFI/fedora/x86_64-efi ,
from package: grub2-efi-x64-modules: /usr/lib/grub/x86_64-efi/)

THIS POINT IS NOT A DETAIL, because with this set in place, 
I discovered with the experiments detailed below that you know immediately
if you boot in secure mode or not!

On my both PC I get this  specific grub.cfg options installed!
On My Lenovo, I discovered that if I boot in secure mode, the background image is not shown!! And later the NVIDIA proprietary modules is NOT loaded because NOT SIGNED !!!!(while of course in not UEFI secure mode, grubmenu background si visible, and later NVIDIA module is loaded !!)

I never get this on my HP (also with a Nvidia Graphic chip)

So I checked MY UEFI MOnitor carefully.

Details in next comment

I always configured my HP UEFI monitor, to show the UEFI boot menu choice at least 10 s
and the boot order is:
1) NOTEBOOK Upgrade Bay (UEFI)
2) OS BOOT MAnager
3) Boot from EFI file
...
I never use the other ones
NOTEBOOK Ugrade Bay
Notebook Hard drive
Notebbok ethernet
because they are not for UEFI booting
=============
So by default 1) is used, and conducts to boot until Linux grub menu
except when you encounter the problem of this bugzilla report

2) boot windows via secure loader bootmgfw.efi
(at the end maybe it's not secure as in Linux booting as explaine below !!!)

3) allow too boot via any valid *.efi  loader found in EFI file system
( in my case allow for example to boot via shim.efi or grub.efi found in EFI/fedora)

*****
So concentrate on the first case: I do nothing and I let the PC boot freely:
with shim-0.8-10, It boots:
===========================
Each time with the message:

System Boot Order not Found, Initailizing default
Creating boot entry "Boot00<xx>" with label "Fedora" for file ...

And after the grubs menu appears.
Once booted:
efibootmgr show something like :
[root@encelade RHF27_i686_x86_64_addons]# efibootmgr 
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0004,0000,0001,0002
Boot0000* Notebook Upgrade Bay
Boot0001* Notebook Hard Drive
Boot0002* Notebook Ethernet
Boot0003* SD Card
Boot0004* Fedora
Boot0005* Fedora
Boot0031* Windows Boot Manager
++++++++++
and with efibootmgr -v, we see details likes
Boot0004* Fedora	HD(1,GPT,36037381-f9d1-11ce-b1ed-f52e2f70cddf,0x800,0xff801)/File(\EFI\fedora\shim.efi)
Boot0005* Fedora	HD(1,GPT,36037381-f9d1-11ce-b1ed-f52e2f70cddf,0x800,0xff801)/File(\EFI\fedora\shim.efi)

That why I supposed that the system booted in secure mode !
But its not the case.
An entry is added by the program shim.efi , but it seams that BootOrder is not stored anywhere in the UEFI EEPROM.
That's the point on this "old" PC, with not a fully implemented UEFI functionality.
So I removed the file shim*.efi from EFI/fedora, when shim-0.8-10 was installed, and my PC continued to boot in the same way !!!!!
I removed EFI/BOOT/BOOTX64.EFI,and then :


-> no more message:
  System Boot Order not Found, Initailizing default
  Creating boot entry "Boot00<xx>" with label "Fedora" for file ...
Appears , that's the proof that this messages is managed by shim.efi or BOOTX64.efi (the same code), and NOT by UEFI monitor !!

-> And the PC boot directly under WINDOWS  (so via  the entry 2 of the UEFI boot order)

AND NOW with the standard Fedora 27 shim-x64-13-0.7 package
===========================================================
With no modification I got:
System Boot Order not Found, Initailizing default
Creating boot entry "Boot00<xx>" with label "Fedora" for file ...

System Reset

AND GO BACK to UEFI MONITOR,
in and endless loop, adding one entry in UEFI table monitor, until the EEPROM is saturated from Boot0000* to Boot002F*.

So the logic is: the same code :
EFI/fedora/shim.efi or EFI/BOOT/BOOTX64.efi
does follow different successive steps (remember on HP 8740W booting via shim.efi is only possible by browsing EFI partition)
In fact booting manually by  shim.efi, shim-fedora.efi, or grubx64.efi get the same result; give grubmenu on my colored background, and then boot linux kernel

Secure boot is ignored, probably because reduced UEFI monitor does not give to shim.efi/ the parameters required !!!

Ok , so now I'm conviced by this test that by default HP elitebook 8740,
I removed the programm supposed to be executed when secureboot with BOOTX64.EFI cannot perform a secure boot:

>>>>>>>>>>>>>> fallback.efi  <<<<<<<<<<<<<<<<<<<<<<<

THAT THE POISONOUS FILE !!!
If you replace it by the one from , you have copied from a shim-0.8-10 package, the system does not reboot, by stays ONE MINUTE showing this: (no movie required to got it !!!!)
  System Boot Order not Found, Initializing default
  Creating boot entry "Boot00<xx>" with label "Fedora" 
  for file "EFI\fedora\shimia32.efi"
   
  Load Image failed : 14
  Device Path; "PciRoot(0) ..(I do not copy this long path)...\EFI\fedora\shimia32.efi"
+ hexa boot code  8 lines x 16 columns of bytes !!!!!

AFTER ONE MINUTE OF PAUSE, the system go back to UEFI monitor, ans so on in an endless loop !!!!
===================

Where does this info "EFI\fedora\shimia32.efi" come from ?
FROM EFI/fedora/BOOT.CSV

On my system, once the 2 bad file are corrected:
[root@encelade BOOT]# pwd
/boot/efi/EFI/BOOT

[root@encelade BOOT]# ls -l ../fedora/BOOT.CSV*
-rwx------. 1 root root 104 Feb 28 00:19 ../fedora/BOOT.CSV
-rwx------. 1 root root 104 Dec  4 22:14 ../fedora/BOOT.CSV.0.8-10
-rwx------. 1 root root 112 Oct  4 17:39 ../fedora/BOOT.CSV.13-0.7
So a keep a copy from the both package: shim-0.8, and shim-x64-13-0.7

[root@encelade BOOT]# cat ../fedora/BOOT.CSV.13-0.7
��shimia32.efi,Fedora,,This is the boot entry for Fedora
[root@encelade BOOT]# cat ../fedora/BOOT.CSV.0.8-10
��shim.efi,Fedora,,This is the boot entry for Fedora

It's obvious that 
shimia32.efi
has nothing to do in our x86 architecture .

If I correct just ONLY BOOT.CSV, its does not boot (but endless loop again)
so
AGAIN >>>>>>>> fallback.efi  <<<<<<<
is the week point.

AFTER A CLEAN INSTALLATION of shim-x64, with dnf
only replacing this file with the one from shim-0.8-10

AND BOOT.CSV from shim-0.8-10
all is going fine with the HP old implemented UEFI monitor
=========
In summary in Fedora 27, shim-x64 , does not provide a good alternate booting mode when all other have failed !!!!

I ask now to the developer and packager of these shim packages:
COULD THIS BE CORRECTED ???

just a mistake writen in my comment 45.
ext2 module is not loaded toot late.
The fact is that any shim.efi have basic module embedded (ext2, font)
but not png. That's why you must provide this from an external file .

BUT

Is secure boot, only shim.efi is loaded, because this is the only file signed by a private key from Microsoft.
A full UEFI monitor can check validity of shim.efi signature , because  it has a certificate with corresponding Microsoft public key.

So I suppose that when UEFI mon has checked this successfully, it give this information to shim.efi executed program, which continue its secure boot process.

Shim.efi in this case cannot call outside program (like png.module, not signed by microsoft !) otherwise, the security boot process could be compromised by this "little" code !!!

THAT'S WHY YOU HAVE NOT COLORED BACKGROUND in secure boot !!!

(at least if you provide it in PNG format: I did not found information about any emmbedded image format module in shim.efi !

Then with the Redhat publickey , embedded in shim.efi (or BOOTX64.EFI: the same code) (embedded before signon by Microsoft of course), shim.efi read the grub module signed by a redhat private key, and if checked successfully, inform grub that it has been loaded and verified successfully , and give it the redhat certificate with public key, embedded in shim.efi .

grub loader, read the simple text grub.cfg, where no malicious code can be hidden, and load after checking the signature , the only file signed, and recognised as such by re-computing with the public key provided by shim.efi:
mainly: linuxefi -> /boot/vmlinuz-....
        initrdefi -> /boot/initramfs
The kernel is also informed by grub that it's signature was checked ,
and now linux kernel cannot accept to load module not signed !

THAT'S WHY YOU HAVE NO PROPRIETARY kernel module loaded in this situation, because they are not signed at compiling time because, they have closed source code embedded!

==========
So secure boot is NOT just for fun ! But as important as SELinux for the application and libs.

Hello,

Just for the record: Problem does NOT occur on a Lenovo Thinkpad T460S UEFI Boot environment (Version N1CET63W 1.31 2017-12-19, Secure Boot disabled). Everything works as expected.

So old Thinkpad T430S UEFI boot is affected, newer models obviously might work.

(In reply to josh from comment #37)
> @David Berlioz - it's pretty simple.  
> 
> Boot to a F27 Live DVD
> Download the shim RPM from a F26 repository using firefox (or use wget as in
> comment #34)
> mount <root partition> /mnt
> mount </boot partition> /mnt/boot
> mount </boot/efi partition> /mnt/boot/efi
> mount --bind /dev /mnt/dev
> mount --bind /proc /mnt/proc
> mount --bind /sys /mnt/sys
> copy the downloaded RPM to /mnt/tmp
> chroot /mnt
> yum remove shim-x64
> yum install /tmp/shim*.rpm
> exit
> reboot
> 
> THe hardest part is getting the F27 Live DVD burned if you can't boot the
> machine...

Hello
How do I find the name of the /boot partition?
My 'parted -l' says:
Disco /dev/sda: 512GB
Dimensione del settore (logica/fisica): 512B/4096B
Tabella delle partizioni: gpt
Flag del disco: 

Numero  Inizio  Fine    Dimensione  File system  Nome                          Flag
 1      1049kB  274MB   273MB       fat32        EFI System Partition          avvio, esp
 2      274MB   290MB   16,8MB                   Microsoft reserved partition  msftres
 3      290MB   81,7GB  81,4GB      ntfs         Basic data partition          msftdata
 6      81,7GB  82,7GB  1074MB      ext4
 8      82,7GB  83,8GB  1074MB      ext4
 9      83,8GB  204GB   121GB                                                  lvm
 4      204GB   205GB   523MB       ntfs         Basic data partition          nascosta, diag
 5      205GB   266GB   61,6GB      ntfs         Basic data partition          msftdata
 7      266GB   512GB   246GB                                                  lvm

So, I assume my /boot/efi is /dev/sda1.
/dev/sda2 is perhaps noacuse it says microsoft?
Could /boot be one of 6 or 8?

Lenovo x240, BIOS 2.42, secure boot disabled, the same problem encountered after upgrade to f27.

I resolved it by going into BIOS settings, disabling "Boot Order Lock", rebooted, machine reseted boot order and automatically rebooted, went into BIOS, reenabled "Boot Order Lock" and now everything is OK.

(In reply to Jaroslav Škarvada from comment #50)
> Lenovo x240, BIOS 2.42, secure boot disabled, the same problem encountered
> after upgrade to f27.
> 
> I resolved it by going into BIOS settings, disabling "Boot Order Lock",
> rebooted, machine reseted boot order and automatically rebooted, went into
> BIOS, reenabled "Boot Order Lock" and now everything is OK.

Thank you for your solution!
I had the same problem with my Lenovo X260, your solution did the trick.

Similar problem here with Fedora 27 and 28 on a Sony Vaio Pro, which has a restricted BIOS so that the various workarounds involving BIOS settings cannot be used.

However, the system does boot, but the message in attachment 1 [details] does flash up briefly, without the Reset System line.

I checked with a couple of other distributions and the machine boots cleanly on those.

Tried the solution in comment #37 https://bugzilla.redhat.com/show_bug.cgi?id=1512410#c37 but this didn't work.

(In reply to lothar.teworte from comment #53)
> Similar problem here with Fedora 27 and 28 on a Sony Vaio Pro, which has a
> restricted BIOS so that the various workarounds involving BIOS settings
> cannot be used.
> 
> However, the system does boot, but the message in attachment 1 [details]
> does flash up briefly, without the Reset System line.
> 
> I checked with a couple of other distributions and the machine boots cleanly
> on those.
> 
> Tried the solution in comment #37
> https://bugzilla.redhat.com/show_bug.cgi?id=1512410#c37 but this didn't work.

Hi Lothar,

I also have the issue on a Sony Vaio Pro and used a workaround that didn't involve bios settings. See my Comments 7, 8 and 10 earlier in this thread. Hope it works for you too.

In case you don't have an EFI directory lying around like described, you can make a livemedia with an older Fedora version (e.g. 26) to obtain them.

Cheers, Fjalar

Well, I upgraded to fc28 and this issue is still there. But my workaround still works. Remove shim-x64 and install the shim-x64 from fc26.

wget https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/26/Workstation/x86_64/os/Packages/s/shim-0.8-10.x86_64.rpm

This problem appears after I upgrade to FC29. My God.

Indeed !!
An now the solution of shim from Fedora 26 is NO MORE a bug turn around.

The problem is new: no more endlessloop, BUT

With shim-x64-15-2 from Fedora 29
or   shim-0.8      from Fedora 26
the fallback initial programm , respectively EFI/BOOT/fbx64.efi for the first package, and EFI/BOOT/fallback.efi for the second

Show the grub menu from EFI/fedora/grub.cfg

So fallback chains normally to grubloader first stage, but whatever Linux entry of my multiboot PC I choose,  I get a grub error:
- - - - - - -
 error ../../grub-core/kern/dl.c:431:symbol  'grub_efi_allocate_pages' not found.
  press any key to continue
- - - - - -

Only the chain entry toward windows is working

So is it a shim bug ???
or a grub bug ???

Ok, this problem is also signalled in bug: 1643802
https://bugzilla.redhat.com/show_bug.cgi?id=1643802

my Comment 57 is not complete:
=============================
If fact there is always endless loop by default,when shimx64.efi is not usable because an incomplete implementation of standard UEFI , in a poor an early UEFI monitor. 
And the responsible of this loop is the BAD EFI/BOOT/fbx64.efi, till NOT corrected from the beginning of Fedora 27.

But you can chain normally to grubmenu, if you are using EFI/fedora/grubx64.efi, choosing it manually by navigating in EFI fat system tree from your UEFI monitor!

To avoid this manual choice , and get an automatic boot
a short bug turn around :
=========================
  is to make a copy of EFI/fedora/grubx64.efi
   in EFI/BOOT/BOOTX64.EFI

and then AT least you chain to grub menu choice !

 **AND there you got the problem signalled in bug: 1643802 (link in comment 58    above)**
See the solution in my comment on this link

NOTE
==== 
On HP Elitebook 8740W, installing or upgrading to Fedora 29, give an endless loop, whith standard boot, either from
   -> UEFI boot entrie stored in monitor flash EEPROM
    standard one (listed with "efibootmgr -v ", once booted in UEFI mode) are
    something like
        Boot0004* fedora HD(1,gpt,< GPT PARTUUID of UFI part.>,0x800,  
                 0xff801)/File(\EFI\fedora\shimx64.efi) 
    or from
   -> the fallback programm when this one has failed: EFI/BOOT/BOOTX64.EFI
    This last one, insert a new entry in UEFI monitor flash EEPROM, with the programm pointed by EFI/fedora/GRUBX64.CSV (shimx64.efi par défaut), supposed to be a good one for the next reboot, and then give hands to fbx64.efi, and loops.


I have tried to point on grubx64.efi, in EFI/fedora/GRUBX64.CSV:
then you can see that EFI/BOOT/BOOTX64.EFI has inserted this new PATH in new entry created. But because the buggy implementation of HP Elitebook UEFI monitor, the next boot this entry is not sucessfully used, and the monitor chains again on EFI/BOOT/BOOTX64.EFI ... and ... the endless loop.

Hello,

I just wanted to say that the problem did not appear when upgrading from Fedora 27 to 28 and 29 on the same mentioned T430, even when I used the correct shim-x64 package as designed. So at least for me, the problem vanished.

However, I took comment #50 and comment #51 as inspiration and disabled the boot order lock in the BIOS settings upfront. Maybe this did the trick.

Regards,
Andreas

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. 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 '28'.

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

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 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.