Fedora Installation Fails with UEFI Secure Boot: How to Fix
You boot the Fedora USB, see the GRUB menu, select "Install Fedora Workstation," and the screen goes black. Or you get a cryptic "Security Violation" message and drop back to the BIOS. The installer refuses to run. Your hardware supports UEFI, Secure Boot is enabled, and Fedora thinks your machine is compromised. This happens most often on laptops with NVIDIA GPUs, older motherboards with buggy firmware, or systems where a previous OS left the key database in a bad state.
What Secure Boot is actually checking
Secure Boot is a UEFI feature designed to prevent unauthorized code from running during the boot process. The firmware checks digital signatures against a database of trusted keys stored in the motherboard. Fedora ships with a valid signature chain. The bootloader is signed by Red Hat, which is cross-signed by Microsoft. The kernel and initramfs are signed by Red Hat. In theory, Fedora should boot on any machine with a compliant UEFI implementation.
In practice, firmware vendors make mistakes. Some implementations reject valid signatures due to bugs. Some wipe the key database on a BIOS update. Some fail to load unsigned third-party drivers like the NVIDIA proprietary driver during the live session. The result is the same: the boot process halts before the installer loads.
Think of Secure Boot like a bouncer checking IDs at a club. Fedora has a valid ID signed by a trusted authority. The bouncer should let Fedora in. If the bouncer is drunk, the ID is smudged, or the bouncer doesn't recognize the authority, Fedora gets turned away. The fix is either to convince the bouncer to check the ID correctly, or to ask the bouncer to step aside.
Disable Secure Boot to complete the install
The most reliable way to install Fedora on problematic hardware is to disable Secure Boot. This removes the signature check entirely. You can re-enable Secure Boot after installation if needed. Fedora works perfectly well without Secure Boot. The feature is optional.
Restart your computer and press the firmware entry key immediately after the manufacturer logo appears. Common keys are F2, F12, Del, or Esc. The exact key depends on your hardware. Look for a message on the splash screen or check the manufacturer documentation.
Navigate to the Security or Boot tab in the firmware setup. Locate the Secure Boot option. Change the setting to Disabled. Save your changes and exit. The system will reboot. Start the Fedora installation from your USB drive. The installer should load without errors.
Check for a "Fast Boot" option in the firmware. Disable Fast Boot if it exists. Fast Boot can skip initialization steps that Fedora needs. It can also leave disks in a state that prevents dual-boot setups from working correctly.
Check for a "CSM" or "Legacy Boot" option. Disable CSM. Fedora requires a pure UEFI environment. CSM can cause boot conflicts and breaks the Secure Boot chain even when Secure Boot is enabled.
Reboot before you debug. Half the time the symptom is gone after a clean firmware save cycle.
Enroll a Machine Owner Key for unsigned drivers
If you must keep Secure Boot enabled, you can enroll a Machine Owner Key. This allows you to sign kernel modules that aren't included in the Fedora repository. This is useful for proprietary drivers or custom kernel modules. The live installer might still fail if it tries to load an unsigned driver. Disabling Secure Boot is usually faster for the initial install. You can enroll the key and sign modules after Fedora is running.
Generate a self-signed certificate and private key. You will use this key to sign modules later.
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -days 3650 -nodes
# Generate a certificate and key pair for module signing
# -nodes prevents password protection so automated builds can sign modules
# The certificate is valid for ten years to avoid frequent renewal
Import the certificate into the firmware. This triggers a reboot into the MOK manager.
sudo mokutil --import MOK.crt
# Send the certificate to the firmware for enrollment
# The system will reboot and show a blue MOK manager screen
# You must set a password and enroll the key in the firmware UI
Follow the prompts in the blue MOK manager screen. Select "Enroll MOK". Enter the password you set during the import. Select "Continue" and "Yes" to confirm. The system will reboot into Fedora. The key is now trusted. You can sign modules with the private key and load them with Secure Boot enabled.
Run sudo dnf upgrade --refresh after install to ensure shim and grub2 are up to date. Firmware bugs sometimes get workarounds in newer bootloader packages. The --refresh flag forces dnf to download fresh metadata and ignore cached package lists.
Verify the boot state
Once Fedora is installed, check whether Secure Boot is active. The kernel reports the state accurately. The BIOS UI can lie or show stale information.
mokutil --sb-state
# Confirm the kernel recognizes the Secure Boot policy
# Output of 'SecureBoot enabled' means the feature is active
# Output of 'SecureBoot disabled' means the feature is off
Check the shim logs if boot fails after re-enabling Secure Boot. Shim is the first stage bootloader. It handles the signature verification before handing off to GRUB.
journalctl -t shim -b -1
# Review shim logs from the previous boot
# -b -1 targets the boot before the current one
# Look for 'signature verification failed' messages
Use journalctl -t shim for boot signature issues. The generic journalctl -xe output is too noisy for this specific problem. The shim logs show exactly which file failed verification and why.
Check the enrolled keys if shim reports a missing key.
mokutil --list-enrolled
# Display currently trusted keys to verify the database isn't empty
# The output shows SHA256 hashes of the enrolled certificates
# Compare against known Fedora keys if you suspect corruption
Trust the package manager. Manual file edits drift, snapshots stay. If you modify bootloader files, use grub2-mkconfig or dnf to restore them.
Common pitfalls and error messages
The Security Violation message means the signature check failed. The file is modified, the key is missing, or the firmware implementation is broken. This error appears on the screen before the OS loads. You cannot proceed until the violation is resolved.
The Boot device not found error can occur when Secure Boot blocks the boot path. The firmware refuses to load the bootloader because it isn't signed. Disable Secure Boot or ensure the bootloader is signed and enrolled.
NVIDIA proprietary drivers are a frequent cause of failure. The live image does not include the signed NVIDIA driver. If your hardware requires the NVIDIA driver to display the installer, Secure Boot will block it. Disable Secure Boot for the install. Install the nvidia-driver package after Fedora is running. You can then sign the module with your MOK or keep Secure Boot disabled.
Some Dell and Lenovo BIOS versions require a specific order of operations. You may need to disable Secure Boot, save, reboot, re-enter the BIOS, and disable it again. The firmware caches the state incorrectly on the first attempt.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Bootloader configuration lives in /etc/default/grub. Changes there persist across updates. Changes in /usr/lib/grub/ get overwritten on package upgrade.
If the boot menu is gone, GRUB rescue is your friend, not your enemy. Secure Boot issues rarely delete the boot menu. If the menu is missing, the problem is likely a corrupted EFI partition or a misconfigured boot order, not Secure Boot.
When to disable, keep, or enroll keys
Disable Secure Boot when you are installing Fedora on hardware with buggy firmware or proprietary drivers that lack signatures.
Keep Secure Boot enabled when you are running a standard Fedora Workstation install with only open-source drivers.
Enroll a Machine Owner Key when you need to load unsigned kernel modules like custom drivers or development tools while keeping Secure Boot active.
Clear the Secure Boot key database when the firmware rejects valid signatures and you cannot disable Secure Boot due to corporate policy.
Stay on the upstream Workstation if you only deviate from the defaults occasionally.