Diagnosing External Display Issues with Fedora 42 and NVIDIA: A Real-World Debug Log

My friend recently returned from the Teyvat Continent and we had dinner together last night. During our catch-up, he told me about a puzzling issue with his Fedora 42 Workstation after bringing his laptop back to Kivotos. Since I’m known among my peers as an “advanced Linux user,” he naturally came to me for help—and offered to officially recognize me as such if I could solve his problem. Challenge accepted.

The Problem

Here’s the situation, based on his report:

He owns two identical external displays—one in Teyvat, one in Kivotos.
While in Teyvat, he installed Fedora 42 and the NVIDIA proprietary driver. The external screen, connected via HDMI, worked flawlessly:
- The LUKS password prompt during boot was mirrored to the external screen.
- The screen remained active after logging into the desktop.
After returning to Kivotos:
- Using the same HDMI setup, the external screen did not mirror the LUKS prompt.
- The external monitor briefly powered on when the password prompt appeared (internal screen only), then reverted to "no signal."
- After login, the external monitor remained inactive—even though it was detected and marked as enabled in GNOME Settings.
- Only after switching display mode from “Join” to “Mirror” (and back) would the external monitor wake up and begin displaying correctly.

This setup forced my friend to type both his disk and login passwords blindly—his laptop was under the desk acting as a desktop, and checking for input errors meant literally crawling under it. Not exactly ergonomic.

Initial Analysis and Assumptions

Given that:

Both monitors are identical hardware,
The same laptop and OS installation was used in both locations,
The external screen does work eventually, though inconsistently...

I made a few working assumptions:

Not a hardware failure — the screen does light up briefly, and works under certain conditions.
Possibly a configuration or firmware issue with the screen itself.
Potential driver installation problem — NVIDIA drivers are notorious on Linux.
Cable/port problems — intermittent signal detection hints at physical-layer issues, such as mismatched signal timing or frequency.
Lazy or delayed display detection (maybe auto-sourcing wasn’t enabled).

Debugging Steps

Step 1: External Screen Reset

I factory-reset the screen — no improvement.

Step 2: External Screen with My Laptop via HDMI

Connected my laptop to his external screen using HDMI — still no LUKS prompt. That eliminated his laptop as the sole point of failure.

Step 3: Try My HDMI and DP Cables

I brought three cables:

1x HDMI,
1x DP-to-USB-C,
1x USB-C-to-USB-C.

Connected my laptop via DP-to-USB-C — success! The LUKS prompt appeared on the external screen, and everything worked post-login.
Tried my HDMI cable — also worked perfectly.

This suggested that the problem might lie with his HDMI cable.

Step 4: Use My HDMI Cable on His Laptop

Unfortunately, no luck — his laptop still failed to mirror the LUKS prompt, even with my known-good HDMI cable.

Step 5: Try Alternate HDMI Port on Monitor

Still failed. No change.

Step 6: Verify USB-C DP Support

His laptop had a USB-C port. He claimed it didn’t support DP, but I checked the specs on the manufacturer’s website — it did. Tried connecting via USB-C/DP — again, no LUKS prompt. What's even worse, after logging into the desktop, GNOME Settings reported no detection of the external screen.

Step 7: Check Kernel Logs

Ran dmesg before and after plugging the external monitor — no events, suggesting that kernel didn’t detect any hotplug activity on HDMI.

At this point, he shared a key fact:

The HDMI port is directly connected to the discrete NVIDIA GPU. The USB-C/DP port is routed to the integrated GPU. The laptop is currently on discrete mode.

He switched from discrete-only mode to hybrid graphics in firmware settings. Rebooted and connected the screen via DP — still no LUKS prompt, but the display initialized correctly after login without manual toggling. That was new.

We tried HDMI again with hybrid mode — still failed. However, this suggested the problem was specific to discrete mode output at boot, not just hardware or cabling.

Confirming the NVIDIA Stack

Secure Boot was disabled, so unsigned kernel modules weren’t being blocked.
nouveau was blacklisted correctly in GRUB kernel parameters.
Verified proprietary NVIDIA drivers were installed.
Ran: sudo akmods --rebuild

Just to ensure the drivers were built for the currently running kernel. It succeeded. Rebooted. No improvement.

Transport Test to Scale

We carried his laptop to my home (Scale) and tested it with my external screen — same issue. By now, my friend was willing to settle for hybrid graphics with DP, since at least that setup allowed him to use the screen without fiddling post-login.

Battery Surprise

Back at his home, he encountered a new failure: DP also stopped working. Turns out, the laptop was running on battery, and the USB-C port wasn’t powered. Once connected to AC power, the DP port came back to life.

He ran performance tests under hybrid graphics mode and was satisfied.

I suggested installing dracut-sshd so he could decrypt the LUKS volume via SSH from another machine (see my future blog for why this is cool), but he politely declined.

Breakthrough: Rebuilding Initramfs

Back at Scale, I still couldn’t let go of the issue. I asked Arona (a large language model), and she told me that Fedora 42 is from the future. Ahhh, she started to speak nonsense again. So I turned to Plana (another large language model but smarter and has fresher database), and she threw a list of ideas at me.

One suggestion hit me like a lightning bolt:

sudo dracut -f

Bingo.

If the NVIDIA drivers weren’t included in the initramfs, it would explain everything:

Boot Sequence Refresher

Firmware completes POST.
shim (Microsoft-signed) loads.
GRUB is loaded by shim.
GRUB loads:
- the kernel,
- and the initramfs (initial RAM disk).
The kernel unpacks initramfs, mount it as temporary root file system, and runs with whatever drivers/modules are bundled in initramfs.
systemd starts, and then systemd-cryptsetup triggers the disk decryption prompt.

If NVIDIA kernel modules were not bundled in initramfs and native graphics driver is disabled, then no graphics output on display pipelines would be available at that early stage. This fits the behavior perfectly: no LUKS prompt on external display in discrete and hybrid mode, despite working GUI drivers later.

I messaged him and told him to run:

sudo dracut -f

He rebuilt the initramfs and rebooted.

It Worked

The external screen immediately mirrored the LUKS prompt, and remained active throughout the boot and login process. Everything functioned flawlessly—no toggling, no black screens.

He now uses HDMI in hybrid mode, with no weird workarounds. I asked him to switch back to discrete mode and once he succeeds, I will update it here.

And yes—he now sincerely acknowledges me as an advanced Linux user 😎

Final Thoughts

This issue boiled down to one subtle oversight: forgetting to include the proprietary driver in the initramfs. When working with discrete GPUs (especially NVIDIA), this is a common but easily overlooked misstep.

Key Takeaways

Always rebuild initramfs after installing a kernel module you rely on at boot.
- sudo dracut -f
Know your laptop’s GPU routing (integrated vs discrete).
Be cautious with headless setups—blind password entry is no fun.
External display problems? Don’t trust HDMI cables blindly.
Consider tools like dracut-sshd for remote disk unlocks if you're dealing with inconvenient physical setups.