Unable to boot latest Kinoite deployment (bad shim signature)

When trying to boot into the latest 39.20240406.0 deployment of Kinoite, I get an error and am unable to boot. The error states “bad shim signature”.

Currently I am booting into the previous day’s deployment (39.20240405.0) without issue. No difference in overlays between this deployment and the latest one that is not booting.

I see that there is a version difference in the kernel of the working deployment (6.7.11-200) and the one that fails to boot (6.8.4-200).

Error

rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
  fedora:fedora/39/x86_64/kinoite
                  Version: 39.20240406.0 (2024-04-06T00:38:38Z)
               BaseCommit: 4c1bfbfabcca637e0b1bf51ac963eddfd344030df8c9197375fdbdd9d53f378b
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
                     Diff: 12 upgraded
      RemovedBasePackages: firefox firefox-langpacks 124.0.1-2.fc39
          LayeredPackages: cockpit cockpit-machines cockpit-ostree cockpit-podman doas qt-virt-manager rocm-clinfo rocm-opencl rocminfo tmux vim zsh

● fedora:fedora/39/x86_64/kinoite
                  Version: 39.20240405.0 (2024-04-05T02:11:55Z)
               BaseCommit: 2915bf1585a364f0e5fee5068c791dd03fc98120344d5bc80c442b2341e89c90
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
      RemovedBasePackages: firefox firefox-langpacks 124.0.1-2.fc39
          LayeredPackages: cockpit cockpit-machines cockpit-ostree cockpit-podman doas qt-virt-manager rocm-clinfo rocm-opencl rocminfo tmux vim zsh
                   Pinned: yes

AvailableUpdate:
        Version: 39.20240406.0 (2024-04-06T00:38:38Z)
         Commit: 4c1bfbfabcca637e0b1bf51ac963eddfd344030df8c9197375fdbdd9d53f378b
   GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
           Diff: 12 upgraded
1 Like

Tried a “clean” update by removing all overlays (rpm-ostree reset) and then updating rpm-ostree upgrade, but still get the same error.

Do you have Secure Boot enabled ? Also can you test the previous commit/deployment ?

Version: 39.20240406.0 (2024-04-06T00:38:38Z)
BaseCommit: 4c1bfbfabcca637e0b1bf51ac963eddfd344030df8c9197375fdbdd9d53f378b

I do have secure boot enabled.

I am currently booting without issue with the previous deployment (20240405). But I am unable to test a deployment earlier than that, as when the “bad” deployment (20240406), it removed all but 20240405. However I have updated daily and haven’t encountered this until now.

Do you know if you need to update Grub? I still think this is a SecureBoot issue. Check if you have any available Grub updates.

How do I check for Grub updates?

Sorry for the late reply, went for a walk in the park ! :evergreen_tree: Maybe we could try to trigger GRUB to update its configuration to reflect the changes. So in the broken deployment

fedora:fedora/39/x86_64/kinoite
                  Version: 39.20240405.0 (2024-04-05T02:11:55Z)
               BaseCommit: 2915bf1585a364f0e5fee5068c791dd03fc98120344d5bc80c442b2341e89c90
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
      

run :

grub2-mkconfig -o /boot/grub2/grub.cfg

reboot

Hopefully this will get everythng where it needs to be.

1 Like

Sorry, I’m not understanding exactly what you mean. When you say I should run grub2-mkconfig “in the broken deployment”, how can I do that? I’m unable to boot into the broken deployment.

1 Like

rpm-ostree deploy <commit>

This is your broken commit 2915bf1585a364f0e5fee5068c791dd03fc98120344d5bc80c442b2341e89c90

I think Tab completion should help here. Then run the :

grub2-mkconfig -o /boot/grub2/grub.cfg

reboot


Optional: Boot into the New Deployment: At this point, you’re technically already switched to the new deployment, but the changes won’t take effect until the next reboot. If you want to immediately boot into the new deployment without rebooting, you can use tools like
systemctl reboot --boot-loader-entry=TARGET (where TARGET is the name of the bootloader entry for the desired deployment) .


I have to leave for the night, If you need help please post and we can continue further tomorrow.

Thanks for your help so far.

The broken commit is actually 4c1bfbfabcca637e0b1bf51ac963eddfd344030df8c9197375fdbdd9d53f378b

Not sure if that changes anything as far as instructions go.

Is running grub2-mkconfig going to change something that is not going to be able to roll back? In case it doesn’t work or makes things worse. As far as I know, things in /boot are not tracked and versioned by rpm-ostree.

I don’t think it will work on the atomic editions.It is discouraged or maybe not even supported. To get kernel arguments in/changed you use rpm-ostree normally. AFAIK, it’s ostree that handles the grub modifications. You may have to use the /etc dropins for grub in order to do what you want.
To do it the “traditional Grub2 way” may require making the system live as in with rpm-ostree --apply-live?

1 Like

It will not change anything as for the instructions, I just used the commit I thought was the broken one. I’ll be limited today, but if you need more help I can help you all day tomorrow.

Give it a go and keep us posted on your progress.

Thanks for the help. I’ve decided to just disable secure boot, which solves this issue for me. In the end, I think this is the fastest and easiest way to move past this issue for now.

I had the same problem on Silverblue. The issue appears to be caused by rpm-ostree based Fedoras not updating the bootloader. A while back I was already affected by the same or a similar issue on arm64 based systems. So I tried the same fix that worked back then.

cp /sysroot/ostree/deploy/fedora/deploy/<deployment>/usr/lib/ostree-boot/efi/EFI/fedora/* /boot/efi/EFI/fedora/

This included a couple of 32-bit (?) versions which I deleted. Now I was able to boot the new deployment.

And because this was so much fun and I was still unable to update the UEFI dbx I continued by trying to make fwupdmgr happy.

So I updated the following files in the same way:

/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/fbx64.efi

And I also deleted the following file:

/boot/efi/EFI/fedora/shimx64-fedora.efi

This file appears to be unnecessary now and isn’t included in the new updated files from /sysroot/ostree/deploy/fedora/deploy/<deployment>/usr/lib/ostree-boot/efi/EFI/fedora

Now I was finally able to update the UEFI dbx.

Please note that I don’t understand half of what I did there and that I made backups before I tried this.

Yes, that’s likely the root cause. I think Fedora 40 is going to fix this somewhat (Changes/FedoraSilverblueBootupd - Fedora Project Wiki). I’ll try updating the bootloader once I upgrade to F40, then try re-enabling secure boot at that time.

Surprise ! :party:

This is tracked in rebase to SB40 fails to boot on notebook ("vmlinuz has invalid signature") · Issue #543 · fedora-silverblue/issue-tracker · GitHub

1 Like