Bad shim signature on boot for kernel 7.1.4-201.secureblue.1.fc44 (kinoite-nvidia-open-hardened 44.20260721.0)

[ProPlayerOfSPFS]

Summary

kinoite-nvidia-open-hardened:latest deployment 44.20260721.0 fails Secure Boot verification on boot with "bad shim signature". The prior deployment (44.20260719.0) boots cleanly with Secure Boot enabled, no changes made to Secure Boot config between the two boots.

Environment

• Image: ghcr.io/secureblue/kinoite-nvidia-open-hardened:latest
• Broken deployment digest: sha256:cf2e86c755f15e141dd6611292530213cc55d3ca3c0cad84e7c5b683390335cf
• Version: 44.20260721.0 (built 2026-07-21T05:31:21Z)
• Kernel: 7.1.4-201.secureblue.1.fc44 (upgraded from 7.1.3-201.secureblue.1.fc44,
  which boots fine)
• Hardware: MSI laptop, UEFI Secure Boot enabled

Error on boot:

error: ../../grub-core/kern/efi/sb.c:shim_lock_verifier_write:192:bad shim signature.
error: ../../grub-core/loader/i386/efi/linux.c:grub_cmd_initrd:260:you need to load the kernel first.

Press any key to continue...

What I've already ruled out

• MOK enrollment: confirmed present and correct via mokutil --list-enrolled
  (Issuer/Subject: O=secureblue, CN=secureblue secureboot key)
• ESP staleness: bootupctl status reports grub2-1:2.12-60.fc44, shim-16.1-5
  as "At latest version" — bootloader components are current, not out of sync
• Local config drift: previous deployment (44.20260719.0, kernel 7.1.3-201.secureblue.1.fc44)
  boots successfully under the exact same Secure Boot setup

This narrows it to the kernel build/signature for 7.1.4-201.secureblue.1.fc44 specifically.

Steps to reproduce

1. Pull 44.20260721.0 on a system already trusting the enrolled secureblue MOK key
2. Reboot into the new deployment
3. GRUB fails to load the kernel with the error above

Status as of this report

Re-checked via rpm-ostree upgrade --check and ujust update-system — still
resolving to the same broken tree (2d83229fbef54933cf2a3bb34bd36b5bcf29fbeccbcf34c9d570deec8f75a372),
no newer build has superseded it yet.

Possibly related (unconfirmed)

Noticed the latest secureblue/kernel release (7.1.4-201.secureblue.1, tag)
changelog mentions fix(cicd): remove retry from build post (#17). I haven't
reviewed that PR's contents and can't confirm it's related — flagging in case
it's useful context, not asserting causation.

Workaround

Pinned the previous working deployment via ostree admin pin booted before
upgrading, so no downtime — just documenting for anyone else who hits this.

NOTE: THIS ISSUE HAS BEEN WRITTEN UP BY AN AI AGENT(Anthropic Claude Sonnet 5), with a human in the loop.