Fixing 2–3 Minute Login Delay on Ubuntu with NVIDIA (Xorg + nvidia-drm Issue)

I typed my password, hit enter, and then... nothing. Well, not nothing exactly. The screen stayed black. The cursor was there, mocking me. Two minutes passed. Then three. Finally, my desktop showed up like nothing had happened.

This went on for weeks. I kept telling myself I'd fix it later. Later came when I couldn't take it anymore.

If you've got an NVIDIA card running Xorg on Ubuntu and your login feels like waiting for a 2003 dial-up connection, this one's for you.

Chasing the Wrong Problem

Like most people, I started where I always do. Systemd.

I ran systemd-analyze to check boot times. Everything looked normal. Then I tried systemd-analyze --user blame to see if any user services were hanging. Nothing stood out. I disabled a few things I didn't need, hoping it would help.

It didn't.

I checked my startup applications. Nope. I looked at GNOME extensions. Still nope. I was sure this was a slow service or a misbehaving app.

Turns out I was completely wrong.

What Was Really Going On

Here's the thing about NVIDIA on Linux. It works, mostly. But every now and then, it does something weird that makes you question your life choices.

The problem was a DRM modeset ownership conflict. Sounds technical, but the idea is simple.

Why does this happen? Your guess is as good as mine. Some kernel versions handle the modeset handoff differently. A system update probably changed something. All I know is that nvidia-drm and Xorg ended up fighting over the same resource, and neither one wanted to back down.

The Fix (Spoiler: It's One Line)

After all that debugging, the solution is almost comically simple.

sudo nano /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=0"

sudo update-grub
sudo reboot

That's it. A single kernel parameter. nvidia-drm.modeset=0.

After the reboot, I logged in, held my breath, and... my desktop appeared instantly. Like it was supposed to all along. I actually sat there for a second, confused by the lack of waiting.

But Wait, Is There a Downside?

Good question. Disabling DRM modesetting means you're giving up some functionality.

If you're using Wayland instead of Xorg, this fix will break things. Wayland needs DRM modesetting to work properly. Same thing if you rely on PRIME Sync or GSP firmware features.

But if you're like me, running plain Xorg on a desktop with one monitor, you won't notice a thing. Everything renders the same. Games still work. Video playback is fine. The only difference is that your computer actually responds when you log in.

What I Learned

I spent hours chasing performance issues that didn't exist. Systemd logs, GNOME tweaks, kernel parameters, you name it. The whole time, the answer was hiding in dmesg output that I kept ignoring.

Next time something weird happens with my system, dmesg is the first place I'll check, not the last. The kernel usually knows exactly what's wrong. You just have to ask.

And honestly? Sometimes the dumbest fixes are the right ones. A single boot parameter that takes ten seconds to type saved me from 2-3 minutes of waiting every single day. Do the math on that over a few months and it's hundreds of minutes I'm not staring at a black screen.

My desktop appears when I log in now. No fanfare. No waiting. Just the way it should be.

You Might Also Like

• Ubuntu Server Security: The Pragmatic Linux Hardening Checklist
• How to Add a Directory to PATH in Linux (Permanent Fix)
• Distributed Tracing with OpenTelemetry
• Advanced GitHub Actions: Reusable Workflows