You enabled Secure Boot and the NVIDIA driver vanished
You flip the Secure Boot toggle in your UEFI firmware to stop bootkits from loading. You reboot into Fedora. The desktop environment starts, but your GPU acceleration is gone. The terminal shows the NVIDIA kernel module refused to load. Your system fell back to the open-source nouveau driver, or worse, you are staring at a black screen with a frozen cursor. The hardware is fine. The driver is installed. The firmware just drew a line in the sand.
What's actually happening
Secure Boot is a firmware feature that verifies the cryptographic signature of every piece of code that runs before the operating system takes over. The Linux kernel itself is signed by Fedora's distribution key. Third-party kernel modules are not. The proprietary NVIDIA driver ships as a precompiled kernel module. When Secure Boot is active, the kernel refuses to load any module that lacks a valid signature. This is a security boundary, not a bug.
Think of it like a corporate building with badge readers. The kernel is the main door. Fedora's key is the master badge. The NVIDIA driver is a contractor showing up without a badge. The door stays locked. The system needs a way to trust that contractor. That way is the Machine Owner Key, or MOK. MOK acts as a local signing authority. Once you enroll it, the kernel treats modules signed with that key as trusted.
Fedora handles this through the akmod-nvidia or kmod-nvidia packages. The akmod variant rebuilds the driver against your exact kernel version every time you update the kernel. The kmod variant ships a prebuilt module for the current release. Both packages include a script that generates a local certificate and places it in /etc/pki/akmods/certs/. The missing step is usually just the reboot and the firmware UI prompt. The kernel does not automatically enroll keys. You must tell the firmware to trust them.
Run journalctl -xe after a failed boot to see the exact refusal. The x flag adds explanatory text to error codes and the e flag jumps to the end of the log. Most sysadmins type this muscle-memory style. You will see a line stating that the module signature is missing or the required key is not enrolled. The kernel is doing exactly what Secure Boot requires.
The fix
You have two paths. Enrolling the MOK keeps Secure Boot active and maintains the firmware security boundary. Disabling Secure Boot removes the boundary entirely. Enrolling the key is the standard approach. Here is how to trigger the enrollment process and complete it.
First, check whether the key already exists on your system. The package manager creates it during installation, but it might not be enrolled yet.
sudo mokutil --list-enrolled
# Checks if a MOK certificate is currently trusted by the kernel
# An empty output means the key is not enrolled yet
# A long hex string means it is already registered
If the output is empty, you need to register the key. The akmod package provides the certificate in a standard location. Import it into the firmware's pending queue.
sudo mokutil --import /etc/pki/akmods/certs/public_key.der
# Reads the pre-generated public key from the akmods certificate directory
# Prompts for a password that you will type during the firmware UI
# Stores the key in the firmware's pending enrollment queue
The command will ask for a password between eight and twenty characters. This password is only used for the enrollment step. It is not stored on disk. Remember it. You will need it in the next minute.
After the command finishes, reboot the machine. Do not skip the restart. The firmware requires a cold boot cycle to present the MOK manager interface. You will see a blue or purple screen titled "Manage Machine Owner Keys" before the GRUB menu appears. If you miss it, the system will boot normally but the driver will remain blocked.
Navigate the MOK manager using the arrow keys. Select "Enroll MOK" and press Enter. Choose "Continue" when asked to proceed. Type the password you created during the import step. The firmware UI does not show asterisks as you type. This is normal. Press Enter again. Select "Yes" to confirm the enrollment. The system will reboot a second time automatically.
If the blue screen does not appear, your firmware might be hiding it behind a fast boot timer. Interrupt the boot by pressing any key when the manufacturer logo appears, or hold Shift during startup to force the UEFI menu. You can also trigger the MOK manager manually by running sudo mokutil --export and checking the system log, but the reboot prompt is the standard path.
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Once Fedora loads, confirm the kernel accepted the signed module. Run the NVIDIA system management interface.
nvidia-smi
# Queries the loaded NVIDIA kernel module for GPU status
# Returns a table showing driver version, GPU name, and memory usage
# An error here means the module still failed to load
Cross-reference the output with the kernel log. The journalctl command shows whether the module loaded cleanly or hit a signature verification error.
journalctl -xe | grep -i nvidia
# Filters the system journal for NVIDIA-related events
# The -x flag adds explanatory context to error codes
# The -e flag jumps to the end of the log for recent boots
Look for lines containing Loading module nvidia followed by module verification: loaded. If you see module verification failed: signature and/or required key missing, the enrollment did not stick. Reboot and repeat the MOK manager steps.
Check the loaded kernel modules to confirm the proprietary stack is active.
lsmod | grep nvidia
# Lists all currently loaded kernel modules matching the nvidia pattern
# Shows the module name, size, and dependency count
# Multiple entries indicate the full driver stack is running
Run `journalctl first. Read the actual error before guessing.
Common pitfalls
The firmware UI behaves differently across manufacturers. Some systems use a blue screen, others use a gray text interface, and some hide the prompt behind a GRUB timeout. If you boot straight into Fedora without seeing the key manager, the firmware skipped the prompt. Interrupt the boot sequence and access the UEFI setup. Look for a "Secure Boot" or "Key Management" section. Some motherboards require you to clear the existing keys before enrolling new ones. Select "Clear Secure Boot Keys" if the enrollment option is grayed out.
Another frequent issue is the nouveau driver loading first. The open-source driver claims the GPU before the proprietary module can initialize. Blacklist the fallback driver to prevent the conflict. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
# /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
# Prevents the kernel from loading the open-source NVIDIA driver
options nouveau modeset=0
# Disables kernel mode setting for nouveau to avoid display conflicts
After creating the file, rebuild the initramfs so the change takes effect on the next boot.
sudo dracut --force
# Regenerates the initial ramdisk with the updated module blacklist
# Ensures nouveau is excluded before the root filesystem mounts
Reboot and verify again. If the system still refuses to load the driver, check whether Secure Boot is actually active in the firmware. Some UEFI implementations report Secure Boot as enabled but do not enforce signature checks. Run mokutil --sb-state to confirm the kernel sees it as active. If it reports disabled, the firmware toggle is misaligned. Fix the setting in the UEFI menu before attempting enrollment.
Kernel updates can also break the driver temporarily. The akmod-nvidia package automatically rebuilds the module on boot, but the rebuild takes time. If you update the kernel and the driver fails to load, wait for the akmods service to finish. Check its status with systemctl status akmods. The service runs in the background and signs the new module with your enrolled MOK. Do not force a reboot while it is running.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use MOK enrollment when you want to keep Secure Boot active and maintain firmware-level protection against bootkits. Use Secure Boot disabled when you are running legacy hardware, dual-booting with older Windows installations, or debugging kernel modules that cannot be signed. Use the nouveau driver when you need out-of-the-box compatibility without proprietary software and can accept reduced performance on modern GPUs. Use the AMD open-source stack when you are running Radeon hardware and want fully integrated, kernel-maintained drivers without third-party signing steps. Stay on the proprietary NVIDIA stack when you require CUDA compute, hardware video encoding, or specific desktop effects that nouveau does not support.