Bluefin no longer boots after update ("bad shim signature")

Bluefin and Aurora
1

EDIT from Jorge: See marked solution.

My Bluefin-DX (gts) updated today, and no longer boots with the latest deployment. I can boot by selecting the previous entry in grub. I have also pinned that now to ensure I don’t lose it (sudo ostree admin pin booted).

The error message displayed on boot is (typos mine):

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

I do have secure boot enabled, I think I remember enrolling a BIOS/UEFI key a while back (ujust enroll-secure-boot-key is in my shell history). As I say the the previous image boots just fine.

Details

Some details of the newest unbootable deployment:

> rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:1f8cb5cb6d8bf22d754d20f51f1d1a625ff6a61a7f618356341c1d5703ffe4f8
                  Version: 39.20240618.0 (2024-06-18T16:53:19Z)
                     Diff: 9 upgraded, 7 removed, 7 added

● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:0165b1ae64333aeaffc50a40cefa00c798c7ecfd1da15209a74b31d73c3a5aff
                  Version: 39.20240617.0 (2024-06-17T20:06:13Z)
                   Pinned: yes

Changelog:

> ujust changelog
rpm-ostree db diff --changelogs
ostree diff commit from: booted deployment (33ed52111b780e8d6e4529f46be64f94b05a28e68fbe877b4a9546a860fddb8e)
ostree diff commit to:   pending deployment (b76c8c47c2e20508cc72495866b99871377557358a802cb44c59a9e81d4f97db)
Upgraded:
  dmidecode 1:3.5-1.fc39.x86_64 -> 1:3.6-1.fc39.x86_64
    * Sat Jun 01 2024 Jonathan Wright <jonathan@almalinux.org> - 1:3.6-1
    - update to 3.6 rhbz#2276863

    * Wed Jan 24 2024 Fedora Release Engineering <releng@fedoraproject.org> - 1:3.5-3
    - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

    * Fri Jan 19 2024 Fedora Release Engineering <releng@fedoraproject.org> - 1:3.5-2
    - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild

  kcli 99.0.0.git.202406160821.9b2f99a-0.fc39.x86_64 -> 99.0.0.git.202406180617.3754408-0.fc39.x86_64
  kernel 6.8.11-200.fc39.x86_64 -> 6.9.4-100.fc39.x86_64
  kernel-core 6.8.11-200.fc39.x86_64 -> 6.9.4-100.fc39.x86_64
  kernel-modules 6.8.11-200.fc39.x86_64 -> 6.9.4-100.fc39.x86_64
  kernel-modules-core 6.8.11-200.fc39.x86_64 -> 6.9.4-100.fc39.x86_64
  kernel-modules-extra 6.8.11-200.fc39.x86_64 -> 6.9.4-100.fc39.x86_64
  kernel-tools 6.8.11-200.fc39.x86_64 -> 6.9.4-100.fc39.x86_64
  kernel-tools-libs 6.8.11-200.fc39.x86_64 -> 6.9.4-100.fc39.x86_64
    * Wed Jun 12 2024 Justin M. Forbes <jforbes@fedoraproject.org> [6.9.4-100]
    - Turn off libbpf dynamic for perf on F39 (Justin M. Forbes)
    - Revert "cpupower: Bump soname version" (Justin M. Forbes)
    - Drop soname for libcpupower.so since we reverted the bump (Justin M. Forbes)

    * Wed Jun 12 2024 Justin M. Forbes <jforbes@fedoraproject.org> [6.9.4-0]
    - Add libbpf workaround for F39 to patches (Justin M. Forbes)
    - Linux v6.9.4

    * Thu May 30 2024 Justin M. Forbes <jforbes@fedoraproject.org> [6.9.3-0]
    - Linux v6.9.3

    * Sun May 26 2024 Justin M. Forbes <jforbes@fedoraproject.org> [6.9.2-0]
    - redhat/configs: fedora: aarch64: Re-enable CUSE (Neal Gompa)
    - Linux v6.9.2

Removed:
  kmod-evdi-6.8.11-200.fc39.x86_64-1.14.4-1.fc39.x86_64
  kmod-kvmfr-6.8.11-200.fc39.x86_64-0.0.git.21.ba370a9b-1.fc39.x86_64
  kmod-openrazer-6.8.11-200.fc39.x86_64-100.0.0.git.530.886f986d-1.fc39.x86_64
  kmod-v4l2loopback-6.8.11-200.fc39.x86_64-0.13.1-1.fc39.x86_64
  kmod-wl-6.8.11-200.fc39.x86_64-6.30.223.271-49.fc39.x86_64
  kmod-xone-6.8.11-200.fc39.x86_64-0.0.git.115.fdbb71f1-1.fc39.x86_64
  kmod-xpadneo-6.8.11-200.fc39.x86_64-0.9.6-2.20240423git73be2eb.fc39.x86_64
Added:
  kmod-evdi-6.9.4-100.fc39.x86_64-1.14.4-1.fc39.x86_64
  kmod-kvmfr-6.9.4-100.fc39.x86_64-0.0.git.21.ba370a9b-1.fc39.x86_64
  kmod-openrazer-6.9.4-100.fc39.x86_64-100.0.0.git.530.886f986d-1.fc39.x86_64
  kmod-v4l2loopback-6.9.4-100.fc39.x86_64-0.13.1-1.fc39.x86_64
  kmod-wl-6.9.4-100.fc39.x86_64-6.30.223.271-49.fc39.x86_64
  kmod-xone-6.9.4-100.fc39.x86_64-0.0.git.115.fdbb71f1-1.fc39.x86_64
  kmod-xpadneo-6.9.4-100.fc39.x86_64-0.9.6-2.20240423git73be2eb.fc39.x86_64
1 Like
2

Can you turn off secure boot and try again? You’re the 2nd person to report this.

3

Latest deployment boots fine if I disable Secure Boot (using it to type this now).

Apologies, did I miss an existing post or bug report somewhere? I did a quick search but didn’t see an existing one.

4

We just got the first report a bit ago, seems to be this one:

Kyle is working on a build now so that we can sign our images, hope to push this asap. In progress PR here:

1 Like
5

Acknowledged.

I’ll not try any of the manual fixes described in those links - as you expect to push a fix to Bluefin itself, correct?

6

Yeah bazzite is unaffected, just Bluefin and upstream Fedora. Once this merges and the images build you should just be able to run an upgrade to the latest image with the fixes and then turn secure boot back on.

8

Thanks very much! Take your time - the workarounds are fine in the meantime.

9

Hi everyone,

I just want to let you all know, I had this issue on stock Silverblue as well! It doesn’t appear to only be a UBlue issue!

I followed this guide here, after booting into an older, working snapshot, then I was able to reboot into newer snapshots again, without disabling secure boot: Boot might fail with "vmlinuz[…] has invalid signature" in atomic desktops - Fedora Discussion

I hope this helps someone!
Thanks for all your hard work devs!

  • Dan
1 Like
10

Yeah we’re going to see if we can fix this without having to do all that, hang tight if you can or just stay on yesterday’s image.

1 Like
11

Ok we got this in the next set of builds, give it a shot.

In a related issues, I was still having a hard time getting it to work but then I realized I had not ever enrolled my secure boot keys! (yikes!)

I did a ujust enroll-secure-boot-key and then I was sorted. Please leave feedback in this thread!

2 Likes
12

lol, seems like this is the issue I was facing when prepping my Surface Pro with Bluefin to give to my dad for Father’s Day. Will try again once this issue is fixed!

2 Likes
13

New image works on my machine with secure boot enabled. \o/

If anyone else pinned the working deployment like I did, don’t forget to unpin it sometime (sudo ostree admin pin --unpin <N>).

> rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:a870bcf951b52edefbb5636c4e28e32349e546f98d406099a88c22cd314fbaec
                  Version: 39.20240619.0 (2024-06-19T18:20:57Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:1f8cb5cb6d8bf22d754d20f51f1d1a625ff6a61a7f618356341c1d5703ffe4f8
                  Version: 39.20240618.0 (2024-06-18T16:53:19Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:0165b1ae64333aeaffc50a40cefa00c798c7ecfd1da15209a74b31d73c3a5aff
                  Version: 39.20240617.0 (2024-06-17T20:06:13Z)

> sudo dmesg | grep 'secureboot'
[    0.000000] secureboot: Secure boot enabled
[    0.005051] secureboot: Secure boot enabled
1 Like
14

Pasting here from the announcements channel on the Discord:

If you’ve updated and your (Bluefin/Aurora) system is no longer booting, please do the following:

  1. Disable secure boot in your BIOS
  2. Boot into bluefin, and run ujust enroll-secure-boot-key and ujust update
  3. Reboot and follow the prompts.
  4. Reboot again into your bios and enable secure boot once more.

You are only affected by this if you did not enroll our key during the initial install, which also means that you have not had any of our kmods enabled all this time. The root cause of the bug is still under investigation, but we can confirm it affects upstream Fedora. Thank you for your understanding. Existing users with working systems can start from step 2 to ensure their system will remain functional during this time.

1 Like
15

Post from Fedora:

17

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.