The install itself was not the hard part. The hard part was getting Fedora Plasma 44 to behave like a normal desktop after the install, with Secure Boot still on and NVIDIA actually loading instead of sulking at boot.

This is the cleaned-up version of what I ended up doing. I am keeping the install part short and the Secure Boot plus NVIDIA part upfront, because that was the part that consumed the time.

What I was trying to do

I wanted Fedora Plasma 44 on a desktop drive, without turning Secure Boot into a permanent casualty just to make the graphics stack work.

The target was simple enough:

  • install Fedora Plasma 44 on the chosen desktop drive. The entire drive. Dual boot with Windows.
  • keep the install straightforward
  • keep UEFI intact
  • make NVIDIA work properly under Secure Boot
  • confirm the desktop loads normally after login

The short version

If you want the sequence without the noise, it was this:

  1. Install Fedora Plasma 44 to the selected drive.
  2. Boot once with Secure Boot disabled if the NVIDIA module gets rejected.
  3. Confirm the desktop loads and nvidia-smi works.
  4. Import Fedora’s akmods signing certificate with mokutil.
  5. Re-enable Secure Boot in UEFI.
  6. Enroll the key in the blue MOK screen.
  7. Boot Fedora again and verify the NVIDIA module still loads.

That sounds neat now. It did not feel neat while I was doing it.

The install part, kept brief

I used the Fedora installer and selected the desktop drive for the full install. Fedora aligned the EFI partition on that disk automatically when I chose the whole drive, which was what I wanted.

The installer itself was quick enough. The part that ate time was the post-install boot and the NVIDIA signing path.

If you are doing the same thing, do not overcomplicate the install. Get Fedora onto the drive first. Do not try to solve the graphics issue before the system has actually booted into the desktop once.

First boot: the real problem shows up

After the install, the desktop did not behave properly with Secure Boot enabled. During boot, NVIDIA briefly fell back to another driver, and Plasma would not come up cleanly.

That is the point where you start suspecting KDE, the installer, the drive, the firmware, and maybe the whole universe.

The actual issue was narrower than that: Secure Boot was rejecting the locally built NVIDIA kernel module.

So the next step was not to change everything. It was to make the desktop boot first, then fix the signing path properly.

Disable Secure Boot temporarily and confirm the desktop works

For the first sanity check, I disabled Secure Boot in UEFI and booted Fedora again.

That confirmed the important bit immediately: the desktop loaded after login.

At that point the system was fundamentally fine. The problem was not Plasma itself. The problem was the trust chain for NVIDIA.

If you are following along, keep the test narrow:

  • do not change TPM settings
  • do not switch to legacy boot
  • keep the machine in UEFI mode
  • only change Secure Boot for the test

Check the NVIDIA driver

Once Fedora booted successfully, I checked the driver with:

nvidia-smi

I also checked the loaded module and the session type:

lsmod | grep nvidia
echo $XDG_SESSION_TYPE

What I wanted to see was:

  • nvidia-smi showing the RTX 3080 Ti
  • NVIDIA modules loaded
  • a Wayland session under Plasma

That was enough to prove the driver itself was not broken. Secure Boot was just refusing to trust the module signature.

Enroll the Fedora NVIDIA signing key

Fedora and RPM Fusion handle this with MOK enrollment. The akmods signing certificate lives at:

/etc/pki/akmods/certs/public_key.der

With Secure Boot still disabled, I checked that the certificate was there:

sudo ls -l /etc/pki/akmods/certs/public_key.der

Then I checked the module signer:

modinfo -F signer nvidia

If the module has been built and signed correctly, this should return a signer name.

To import the certificate into the Machine Owner Key list, I ran:

sudo mokutil --import /etc/pki/akmods/certs/public_key.der

That asks for a temporary password. This is not your Fedora password. It is only used once during the MOK enrollment screen.

To confirm the request was queued, I checked:

mokutil --list-new

Re-enable Secure Boot and finish the enrollment

After the import request was in place, I went back into UEFI and turned Secure Boot back on.

On the next boot, Fedora opened the blue MOK Manager screen. That is the part where you have to stay awake and use the keyboard like it is 2009.

The sequence was:

  • Enroll MOK
  • Continue
  • Yes
  • enter the temporary password
  • reboot

The screen does not show characters while you type the password. That is normal.

Verify the setup after Fedora boots

Once Fedora loaded again, I checked the secure boot state:

mokutil --sb-state

And then I checked the NVIDIA side again:

modinfo -F signer nvidia
nvidia-smi
lsmod | grep nvidia

The result I wanted was:

  • Secure Boot enabled
  • the akmods key enrolled
  • the NVIDIA module showing a signer
  • nvidia-smi working normally
  • Plasma loading after login without drama

That is the point where the install stops being an install headache and starts being a usable desktop.

If NVIDIA still fails after enrollment

If nvidia-smi still fails after enrolling the key, rebuild the modules and regenerate initramfs:

sudo akmods --force --rebuild
sudo dracut --force

Then check the signer again:

modinfo -F signer nvidia

If the module still does not sign correctly, reboot and make sure Fedora is booting through the normal installed UEFI entry, not some unusual alternate path. The signed shim path matters here.

What I would keep in mind next time

The useful lesson was not “Fedora is hard”. The useful lesson was more specific:

  • the install was fine
  • the desktop was fine
  • the NVIDIA issue was a trust-chain problem, not a Plasma problem
  • Secure Boot did not need to stay disabled permanently
  • MOK enrollment was the correct fix

That matters because it keeps the machine usable for both Fedora and Windows without making Secure Boot a temporary convenience setting you forget about later.

Final state

At the end of the process, Fedora Plasma 44 was installed on the desktop drive, Secure Boot was enabled, the MOK key was enrolled, and the NVIDIA driver loaded normally.

That is the version I would call done.

It was not glamorous, but it worked.

Verification checklist

If you are doing the same setup, these are the commands worth running once the dust settles:

mokutil --sb-state
mokutil --test-key /etc/pki/akmods/certs/public_key.der
modinfo -F signer nvidia
nvidia-smi
lsmod | grep nvidia
echo $XDG_SESSION_TYPE

Expected outcome:

  • Secure Boot enabled
  • key enrolled
  • NVIDIA module signed
  • NVIDIA GPU detected
  • Plasma session running normally
  • Wayland active if that is what you expect on your setup

The Gotcha Part

This is the part most of the time people forget to do. If you install Fedora on a full drive, Fedora may write the EFI boot record on that drive itself. This is good, but there is a gotcha part in it. Windows bootloader will not detect the install, so there will be no entry for Fedora to boot.

There is a simpler fix to this.

In the UEFI BIOS, set your boot disk priorities; set the Fedora drive first, then USB, and after that Windows.

Let me explain.

The Fedora GRUB already detected the Windows bootloader, and GRUB has an entry for it. So, if you load the Fedora GRUB, you will have access to both of them.

Why this still feels harder than it should

Linux desktops have come a long way, and on the technical side, they can be excellent. Privacy is better, control is better, and stability is often better than people expect.

But the user experience still has friction that Windows users notice immediately. Too many distros, too many slightly different defaults, and too often you still end up in the console to finish what should have been a routine desktop setup.

That is discouraging for people coming from Windows, especially if they just want the machine to work and not become a weekend project.

Linux still wins where I care most: privacy, control, predictability, and stability. But if a desktop needs a driver signing dance, a firmware detour, and a console cleanup before it behaves like a normal computer, then the platform is still asking too much from regular users.

That is the part Linux desktop people need to admit out loud. It is not a lack of power. It is a lack of comfort. Until the setup path stops feeling like administration, Windows will keep the easier pitch for most people.