Bad Shim Signature | Fedora Silverblue |

error: ../../grub-core/kern/efi/sb.c:182:bad shim signature 
error: ../../grub-core/loader/i386/efi/linux.c:258:you need to load the kernel first
 
 Press any key to continue..

So i have some boot entries with ostree, for the system to work i have to boot on the previous pinned entry one, since the first one (the last updated one) looks corrupted

rpm-ostree status

State: idle
Deployments:
  fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240628.0 (2024-06-28T01:04:36Z)
               BaseCommit: 0e3b27a3929e9578dce841d1bdd324ddd22855e84ffe6cebe3b81b35a9bdd271
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
                     Diff: 236 upgraded, 1 removed, 1 added
      RemovedBasePackages: firefox firefox-langpacks 127.0.2-1.fc40
          LayeredPackages: inxi openssl

● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240602.0 (2024-06-02T00:42:37Z)
               BaseCommit: 9316d62339d12ec7cb98678f812cfa109e3d776839b76822ebee3eb7d1dce144
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
      RemovedBasePackages: firefox firefox-langpacks 126.0-7.fc40
          LayeredPackages: inxi openssl

the first one is the problem

Already did rpm-ostree upgrade , but didnt solve, same problem

Added bug-reported, silverblue

There are several topics available to address the issues with Bad Shim Signature here on the forums.

Here are some links :

  • This link beiong the most recent and containing the bug report, and lins to follow for more troubleshooting :

This is covered in the Common Issues category - Boot might fail with "vmlinuz[…] has invalid signature" in atomic desktops

1 Like

looks like is a common problem in the last update. I dont understand if is a upgrade problem that could be fix by fedora (so doing a rpm-ostree upgrade will fix when fedora releases a fix) or if is something im my pc that i need to fix

rephrasing , if i wait will fedora fix the issue when i run rpm-ostree upgrade again in the short time ?

looks complicated all this workaround, needing to reinstall the system
I installed silverblue to not have these types of problem , have a system that just works, looks like i was wrong

looks complicated all this workaround, needing to reinstall the system

You don’t need to reinstall the system…just a few commands…

The workaround has been used successfully many times and is only a few commands that need to be run from the terminal. I would encourage you to try it out. (I’ve used it myself on multiple systems).

rephrasing , if i wait will fedora fix the issue when i run rpm-ostree upgrade again in the short time ?

You’ll have to wait for a long time until Fedora 41 rolls around, see below:


The details of the problem are a bit gory, but I’ll try to give an explanation.

The architecture of ostree/rpm-ostree is such that the contents of the /boot partition is not managed as part of ostree commits. So when a new bootloader is released, it is not automatically applied as part of the rpm-ostree upgrade path.

The proposed solution to this problem is the use of bootupd. Since it involves manipulating the bootloader, it has been held back from use in Atomic Desktops until we have better certainty that it will work reliably. Going forward, we expect to see bootupd used as part of the Atomic Desktops in Fedora 41 and beyond.

The actual problem that folks are hitting is related to how the kernel is signed for use with Secure Boot. As I understand it, Microsoft controls the private keys that are used to sign the kernel for use with Secure Boot. When they decide to revoke an existing private key or tell the industry to use a new private key for signing kernels, this means that the bootloaders (i.e. the shim package) need to be updated to recoginze the new key.

Since Atomic Desktops don’t update the shim binaries as part of the upgrade process (as explained above), users that older versions of shim on their systems will be unable to boot the newer signed kernels when using Secure Boot.

(I’m not an expert in the areas of Secure Boot/kernel/shim, so corrections/clarifications are welcome)

1 Like

No need to reinstall. The quickest/easiest fix is to disable secure boot in your UEFI/BIOS.

i read the workaround and he didnt mention to disable secure boot on Bios, so just to confirm, i dont need to disable secure boot ?

Correct, disabling Secure Boot is not required.

To clarify, there’s 2 ways to work around this issue:

  1. Disable secure boot. This will in effect ignore the signature check at boot, allowing your system to boot to the latest version, albeit without your system having secure boot. Secure boot will need to be kept disabled for your system to keep booting until bootupd is deployed in F41, which will update the bootloader for you (in effect running the workaround commands for you).
  2. Do the workaround commands yourself. This will replace your shim and bootloader to have the latest signatures so that your system can boot the latest version. This will also allow you to keep secure boot enabled.
2 Likes

thanks guys, this is the best linux community

do you recommend leave the backup file there in case any problem or the best practice is to remove ?

No harm in leaving it for at least a few updates to make sure nothing is wrong. Unless you are low on space in your EFI partition, which could lead to other issues when the system tries to write new files there during an update.

1 Like

strange part is this kind of error ever happend in my dnf system i dont know whether i have been infected with something so or ostree system is actually creates this kind of errors
i have been using opensuse also micro os as i have many devices but never face any such issues
maybe i use ostree on laptop but other 2 are on desktop

The difference is that systems that use dnf for package management will happily update your shim and bootloader.

As explained earlier in the thread, the /boot partition (where the EFI binaries, shim, bootloaders live) is not managed as part of rpm-ostree/ostree, which is why this issue is only being observed on ostree based systems.

1 Like

This is lack of feature i think this issue need to be addressed so people can simply install and forget.

Agreed. The expected solution will be the use of bootupd which is expected to be included in the Atomic Desktops as part of Fedora 41.

3 Likes

Bro do you know if using bootupd in the future will prevent of windows on grub asking everytime the gigant bitlock key when boot it or is a different problem ?

They should not use windows at the first
Place. Hence we don’t need to worry about that. But if someone who have ditch windows and installed this and face this type of issue they will be forced to go back to windows again which is bad for then and the community as a whole.
If still they want dual boot they should Use dnf fedora.