Dennis HilkLinux Fix LabDE

Boot, GRUB & systemd-boot

Secure Boot rejects a bootloader or kernel image

A boot-chain signature rejection occurs before normal driver loading; verify the signed loader, kernel and trust path without erasing firmware keys.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Firmware or shim displays a signature/security violation before Linux starts.
  • GRUB rejects a selected kernel with bad shim signature.

Relevant environment

UEFI Secure Boot using distribution shim/GRUB or a signed systemd-boot/UKI chain. This differs from a kernel module signature denial after boot.

Recognizable messages (synthetic examples)
error: bad shim signature.

Check the boot image trust chain rather than rebuilding an unrelated kernel module; this line does not distinguish unsigned from revoked or malformed images.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • An unsigned or untrusted image may have replaced a signed boot component.
  • A revoked older loader or inconsistent vendor/custom key chain can fail even when a file has a signature; signed does not automatically mean trusted.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read Secure Boot state from a working installed or rescue session using shim/MOK tooling; this does not alter keys.

mokutil --sb-state

Interpret the result: Enabled confirms enforcement context for this session. The rejected image and which stage rejected it still need to be identified from the boot screen.

Check 2

Replace the path with the actual rejected EFI/UKI image; sbverify from sbsigntool lists signatures without modifying it.

sbverify --list /boot/efi/EFI/Linux/example.efi

Interpret the result: A signature can be present yet not trusted or can be revoked. Absence supports checking whether an unsigned artifact replaced the intended package image.

Evidence-guided next steps

Restore the supported signed boot chain

If a local unsigned artifact replaced a supported distribution component, recover through trusted distribution media and reinstall its matching signed loader/kernel packages into the verified ESP. Preserve the existing trusted alternate entry.

Precautions: Do not erase firmware PK/KEK/db keys or blindly downgrade revoked loaders. Keep disk-encryption recovery information available when changing measured boot files.

Recovery / rollback: Boot the preserved currently trusted entry or supported recovery media; a revoked old image may be unusable as rollback.

Did this solution help you?

Share this solution#

Align an intentional custom signing chain

If a custom kernel/UKI is intentional, sign it with the known key trusted by the relevant loader or firmware stage using that setup’s documented workflow. Verify the whole chain rather than enrolling unrelated module keys.

Precautions: Know which trust database each stage uses and keep a trusted recovery image. Signature presence alone is not an end-to-end verification.

Recovery / rollback: Select the preserved distribution-signed entry and restore the prior custom-image configuration if the new chain cannot boot.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.