Bad shim signature in 40.20240617.0 deployment

[0rzech]

Describe the bug
The latest Silverblue deployment is unbootable, because of

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

OS version:

fedora:fedora/40/x86_64/silverblue
                Version: 40.20240617.0 (2024-06-17T00:42:18Z)
             BaseCommit: c7bdc9ecab9df0609da0e04b685ca7608174e6cb81d49e1cf4b70b798557018e
           GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC

Additional context
The system has secure boot enabled, obviously.

[0rzech]

Ok, I guess this is another variant of #120 and #543 ?

[0rzech]

Yep, this is another variant of the aforementioned issues. Workaround from #543 (comment) helped.

[juhp]

I just ran into this too - so am I now forced to run those workaround commands to get later deployments working?

Might be better to keep this ticket open?

[0rzech]

You have to run those commands.

Yeah, perhaps it would be better not to close this issue, so others affected will have it easier to find it.

[travier]

I've updated the title of #543 to mention this error. Closing to keep things in a single place.

[juhp]

Those commands worked for me

It would be nice to make it into a little shell script, which could be run with sudo

[dubst3pp4]

I've just rolled back to image 40.20240614.0. Can I expect that there will be a new image soon, so that I can skip 40.20240617.0? Or do I have to run the mentioned commands anyway?

[JeanLuX]

Same issue with Fedora Kinoite 40.20240618.0 on my Asus G14 2022 with Secure Boot.
No issue with 40.20240614.0

[0rzech]

@dubst3pp4 You have to run those commands. AFAIU, updating bootloader, shims etc. is currently scheduled for rpm-ostree-based F41 and perhaps will be backported to F40: #120 (comment) .

@JCenatus AFAIU, because the problem is with signatures, any deployment past 40.20240617.0 will not work until #120 and #543 are solved, or until you apply the workaround.

And until the aforementioned issues are fixed, such problems can reoccur in the future.

[JeanLuX]

@dubst3pp4 You have to run those commands. AFAIU, updating bootloader, shims etc. is currently scheduled for rpm-ostree-based F41 and perhaps will be backported to F40: #120 (comment) .

@JCenatus AFAIU, because the problem is with signatures, any deployment past 40.20240617.0 will not work until #120 and #543 are solved, or until you apply the workaround.

And until the aforementioned issues are fixed, such problems can reoccur in the future.

Thanks but I am reluctant to execute manual commands on a system that is supposed to be a model of stability and reliability due to its immutability system :/.

I don't mind waiting for an official fix, especially since it seems this isn't the first time it's happened. Last time, it was fixed very quickly.

Additionally, since I have version 40.20240614.0, do you know of a way to update to version 40.20240616.0, please?

[juhp]

@JCenatus there won't be a fix (anytime soon by the looks of it) - I was also "scared" initially, but it's actually just copying a few deployed efi files over from /usr to /boot, so yeah it's not a seamless process but let's hope it will be once F41 is available in some months.

[0rzech]

@JCenatus I think @juhp's interpretation of the situation is on point. The workaround makes a backup copy of replaced files and then copies newer versions of those files from current deployment to efi partition. In future this will happen automatically, along with updating the bootloader itself.

I didn't test that, but perhaps disabling secure boot until the fix is ready might allow you to skip the workaround, but I think it's not worth it to disable secure boot, given the workaround is simple and has helped me and other people.

In general, I recommend reading the linked issues and their comments to better understand what's happening and what to expect... and what not to do. 😉

[dubst3pp4]

@juhp @0rzech Thanks for the detailed explanation! Although I'm with @JCenatus, I will try the mentioned steps...

[dubst3pp4]

@juhp @0rzech Thanks for the detailed explanation! Although I'm with @JCenatus, I will try the mentioned steps...

worked without problems. Thanks again.

[travier]

Let's keep things in a single place: #543