Problem upgrading to Fedora 41 - Blocked executable in the ESP, ensure grub and shim are up to date

Ask Fedora
1

Full error:

Blocked executable in the ESP, ensure grub and shim are up to date: /run/media/root/SYSTEM/EFI/HP/SystemRecovery/bootmgfw.efi 
Authenticode checksum [f74947590a87a005023e9ef89cdf0c38d8d582ca4173f8201cebc443ef796790] is present in dbx

This is from “Discover” as well as command line: fwupdmgr update
I dual boot windows 10 and fedora 40.
The efi file in question is on the windows EFI partition.
Google search shows there are many ocurrences of this problem, some of which have dangerous recommendations, but none of which have solutions.
As far as I can see, there’s no way to “update” bootmgfw.efi.
So is it possible to do the upgrade or not, and if so, how.
Thanks!

2

Do you have a file named HP/SystemRecovery/bootmgfw.efi somewhere in the efi file system (aka ESP)? The efi file system is usually mounted on /boot/efi.

If so, this file seems to become blacklisted by Microsoft, and therefore either needs to be updated or removed.

The error message refer to it as
/run/media/root/SYSTEM/EFI/HP/SystemRecovery/bootmgfw.efi
so also check there and also find out what is mounted there using the command

lsblk -f
1 Like
3 
root@fedora:/etc# lsblk -f
NAME   FSTYPE FSVER LABEL            UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                      
├─sda1 vfat   FAT32                  77F9-9280                             579.8M     3% /boot/efi
├─sda2 ext4   1.0                    75c828cc-0b53-4aee-8a4c-cfd91934c446  569.7M    35% /boot
└─sda3 btrfs        fedora           3b52caef-e5a8-48dc-9044-24a5996a37cb    1.4T     0% /home
                                                                                         /
sdb                                                                                      
├─sdb1 ntfs         Windows RE tools 2331D9983FE7411E                                    
├─sdb2 vfat   FAT32 SYSTEM           E569-8CBF                               272M    24% /media/win_efi
├─sdb3                                                                                   
├─sdb4 ntfs         Windows          3CBC5106ED1B5B0E                      433.5G    53% /run/media/phil/Windows
├─sdb5 ntfs                          89BDE21912B8A73E                                    
├─sdb6 ntfs                          D07853EC3816F22F                                    
└─sdb7 ntfs         Recovery Image   D4F87A89C1432FEE                                    
sdc                                                                                      
sr0                                                                                      
zram0                                                                                    [SWAP]

/dev/sbd2 wasn’t mounted, so I mounted it. That’s where the offending efi file is. Interestingly, there are 2 versions:

root@fedora:/etc# ll $(find /media/win_efi/ -name bootmgfw.efi)
-rwxr-xr-x. 1 root root 1616728 Mar 18  2014 /media/win_efi/EFI/HP/SystemRecovery/bootmgfw.efi
-rwxr-xr-x. 1 root root 1597408 Oct  9 10:04 /media/win_efi/EFI/Microsoft/Boot/bootmgfw.efi

Maybe something can be done there? My machine is HP…

4

I suggest you don’t mount that file system. There is nothing useful there when running Fedora.

EFI/Microsoft/Boot/bootmgfw.efi is for booting windows, and the other one os for some HP stuff.

I assume that when booting into Windows, it will also want to update the dbx. After all, the dbx you update with fwupd comes from Microsoft.

5

Thanks Villy. I just mounted it to take a peek :grinning:.
I know nothing about dbx or how to update it.
It seems that microsoft updates EFI/Microsoft/Boot/bootmgfw.efi but the boot process is using EFI/HP/SystemRecovery/bootmgfw.efi.
Maybe I could just copy EFI/Microsoft/Boot/bootmgfw.efi to EFI/HP/SystemRecovery/bootmgfw.efi ?
Would there be an action to do with dbx?
…
On second thought, never mind the boot process. This whole thing is to satisfy the Fedora software update. The boot works just fine as-is and I don’t want to do anything to break it.

6

Whenever it is discovered that some .efi program has a security issue, said .efi program will be blacklisted by the updated dbx file. If UEFI is then asked to load this blacklist .efi program it gets a security violation and the program won’t run. You don’t update dbx, Microsoft does.

7

Thanks! Now, just to be absolutely clear, I’ve attached some screenshots

1-problematic-update
1-problematic-update933×404 74.5 KB

2-problematic-update-details
2-problematic-update-details933×459 68.3 KB

3-problematic-update-link
3-problematic-update-link645×115 13 KB

Also efibootmgr info (condensed)

BootCurrent: 0000
BootOrder: 0001,0000,0008,0007,000D,0004,0006,000C,000E
Boot0000* Fedora	HD(1,GPT,aad43d6d-f33b-4675-b6be-e66072912a6a,0x800,0x12c000)/\EFI\fedora\shimx64.efi
Boot0001* Windows Boot Manager	HD(2,GPT,6b413ded-a60a-4c43-a449-644be3aff19b,0x200000,0xb4000)/\EFI\Microsoft\Boot\bootmgfw.efi ...
Boot0004* USB Floppy/CD	...
Boot0006* Hard Drive	...
Boot0007* USB Floppy/CD	...
Boot0008* USB Hard Drive	...
Boot000C* Realtek PXE B02 D00	...
Boot000D* ATAPI CD-ROM Drive	...
Boot000E* CD/DVD Drive 	BBS(CDROM,,0x0)...

The problem I’m trying to solve is to make the Fedora 41 upgrade possible. If it is not possible or possible with risk to break booting, then I will simply stick with Fedora 40.

8

2 more screenshots
4-bootmgfw-files

5-EFI-dir-tree
5-EFI-dir-tree485×863 28.3 KB

9

Maybe @vekruse is suggesting that this is not possible since that partition doesn’t even get mounted during a Fedora boot session, and that is what will be running when you do the system upgrade from f40 to f41?

I also interpret his suggestion to you that you wait to see if that HP manufacturer recovery efi file gets addressed the next time you boot Windows. In that case, since you’ll be booting from the drive containing Windows, it will mount the EFI partition on that disk.

Good luck!

10

Thank you both. Seeing as it seems to be strictly a windows issue, I’ve placed a query in the HP Community forum. I’ll update this if I get an answer.

11

I got courageous and backed up EFI/HP/SystemRecovery, deleted it and ran the UEFI dbx update and the other updates. When successfully completed and before rebooting, I restored the backed up EFI directory and rebooted. It seems to have gone well as the Fedora 41 update is now running. Thanks again for the comments.

12

I’m glad to learn you got your update done.

Looking back at my comment to you, I see that I misstated my point: I meant that it would’ve been impossible for youi to mess up that HP recovery efi file during a Fedora system upgrade because that partition isn’t even mounted while you’re booted into Fedora.

13

On the contrary. Don’t mount that partition and the contents becomes irrelevant. Besides, you can upgrade to Fedora 41 even if you haven’t installed the dbx upgrade.

1 Like
14

The original message was this

Blocked executable in the ESP, ensure grub and shim are up to date: /run/media/root/SYSTEM/EFI/HP/SystemRecovery/bootmgfw.efi 
Authenticode checksum [f74947590a87a005023e9ef89cdf0c38d8d582ca4173f8201cebc443ef796790] is present in dbx

At that point EFI/HP/SystemRecovery was not mounted. The UEFI dbx update threw that error all by itself. I mounted it afterward to investigate. So Fedora 41 upgrade depended on UEFI dbx update, and UEFI dbx update failed. This is the sequence of events:

  1. Fedora 41 upgrade requires UEFI dbx upgrade
  2. UEFI dbx upgrade fails because of SYSTEM/EFI/HP/SystemRecovery/bootmgfw.efi
  3. I mount the fs and remove SYSTEM/EFI/HP/SystemRecovery
  4. I retry UEFI dbx upgrade and succeed
  5. I restore SYSTEM/EFI/HP/SystemRecovery
  6. I proceed with Fedora 41 upgrade which succeeds
  7. I unmount the fs - probably could have done that before step 6
15

Based on this detail

/run/media/root/SYSTEM/EFI/HP/SystemRecovery/bootmgfw.efi

it must have been mounted on /run/media/root/SYSTEM.

16

Yes, you’re right. What I meant to say was that it wasn’t me who mounted it (in response to your advice not to mount it).