Introduction
It was a perfectly normal day. I opened my laptop, ready to get some work done, and then…
BAM.
A black screen. Not a gentle fade to black, but more like my computer shouting, “I’ve had enough of your crap!”
The same operating system that had been working perfectly just five hours earlier had suddenly decided it had had enough of life.
I wasn’t too worried though. After all, I had ChatGPT on my side.
Three hours later…
Yeah… my confidence crumbled faster than my phone battery at 2%.
What followed was a three-hour rabbit hole involving NVIDIA drivers, multiple Linux kernels, Secure Boot, DKMS, Xorg, GDM, journalctl, systemd, and more terminal commands than I’d like to admit.
Somehow, against all odds (and probably a little divine intervention), we managed to fix it. And honestly? I enjoyed every minute of the chaos. It was like a wild adventure—except with more curse words and less danger.
So I decided to document the entire debugging journey—not just because it might help someone who runs into the same issue, but also because I deserve a little sympathy after spending three hours arguing with my laptop.
(And if the solution seems painfully obvious to you… please let me enjoy my victory. Don’t take this away from me.😤
The Problem
After rebooting my laptop, I was greeted with just a black screen. No login screen, no desktop… just nothing.**
At first, I tried to enter TTY using Ctrl + Alt + F3, but that wasn’t working either. Since I wasn’t able to reach TTY directly, I had to take a different route. By editing the GRUB boot entry and booting into multi-user.target, I forced Linux to start in text-only mode, giving me access to a terminal.**
For this, I edited the GRUB boot entry and appended systemd.unit=multi-user.target to the end of the kernel command line (after quiet splash).
That was the first breakthrough, though. The operating system wasn’t completely dead… only the graphical interface was failing to wake up.
First Clues and Initial Assumptions
Before touching any command and making blind changes, I made some observations:
- The laptop successfully passed the BIOS and GRUB screens.
- Ubuntu started booting but wasn’t able to reach the login screen.
- Booting into
multi-user.targetworked, and I was able to access the terminal. - The issue appeared after a reboot; the laptop was working fine a few hours ago.
These observations immediately ruled out a few possibilities:
- Corrupted filesystem
- Completely broke operating system
- Hardware failure preventing Linux from booting
The problem seemed to be somewhere in the graphics stack
Initial Hypothesis and Wrong Assumptions
At this point I knew exactly one thing: the operating system could boot, but the graphical interface couldn’t.
I just didn’t know “WHY”
The Linux graphics stack isn’t exactly my area of expertise, so here comes our dearest and probably everyone’s favourite CHAT GPT !!!
(Yes, yes… cue the applause. 👏👏👏)
So now instead of throwing random fixes, we tried to figure out the most plausible causes that can cause these symptoms.
Our initial suspects were:
- NVIDIA driver issues
- Secure Boot blocking unsigned kernel modules
- A failed DKMS build after a kernel update
- GDM (GNOME Display Manager) failing to start
- Xorg configuration issues
- Problems with NVIDIA kernel modules loading during boot
(Obviously, ChatGPT listed these out after several log checks, commands for which I didn’t even know existed—at least not before this crisis.)
The Investigation Begins: Is the NVIDIA driver broken?
We started off with the NVIDIA drivers because it seemed to be the most obvious thing to check since I was facing a graphics issue. Also, my laptop has a hybrid setup of AMD + NVIDIA, so it made the case stronger.
At this point ChatGPT gave me multiple commands to inspect the current driver installation. Following are some of the commands:
- uname -r: Shows the currently running Linux kernel version.
- lsb_release -a: Shows the Ubuntu version
- nvidia-smi: Checks whether the NVIDIA driver is loaded and the GPU is accessible.
- ubuntu-drivers devices: shows recommended NVIDIA drivers for your hardware
- lsmod | grep nvidia: checks whether NVIDIA kernel modules are currently loaded or not
- modprobe nvidia: Manually loads the NVIDIA kernel module
- dkms status: Verifies whether NVIDIA kernel modules were successfully built for the installed kernel.
- journalctl -b: Shows logs from the current boot
- journalctl -b -p err: Shows error messages from the current boot
- journalctl -u gdm: Shows logs related to GDM
- cat /var/log/Xorg.0.log: Shows Xorg errors
- systemctl status gdm: shows if the display manager is running
- systemctl start gdm: Manually starts the graphical logic manager
- modinfo nvidia: Displays metadata about the NVIDIA kernel module.
- update-initramfs -u: Rebuilds the initial RAM filesystem used during boot.
Phase 1: Verifying the NVIDIA Driver
Our first assumption was that the NVIDIA driver itself was broken. Since my laptop uses hybrid graphics (AMD + NVIDIA), this seemed like the most likely culprit.
Commands
nvidia-smi
ubuntu-drivers devices
lsmod | grep nvidia
modprobe nvidia
dkms status
modinfo nvidia
Enter fullscreen mode Exit fullscreen mode
These commands helped answer a few important questions:
- Was the driver installed?
- Were the kernel modules present?
- Had DKMS built the modules for the current kernel?
- Could the modules be loaded manually?
Although the driver installation looked healthy, something still wasn’t adding up. The modules existed, but they weren’t consistently available during boot.
Phase 2: Is Something Preventing the Driver from Loading?
Since the driver itself looked healthy, we shifted our attention to the boot process.
We checked whether Secure Boot was refusing to load unsigned modules and searched the boot logs for anything suspicious.
Commands used:
mokutil --sb-state
mokutil --list-enrolled
journalctl -b
journalctl -b -p err
journalctl -k
Enter fullscreen mode Exit fullscreen mode
Everything looked surprisingly normal.
Secure Boot wasn’t blocking anything, and the logs didn’t point towards a broken driver, which ruled out another major suspect.
Phase 3: Following the Graphics Stack
Since Linux itself was booting correctly, the next suspect was the graphical stack.
We inspected GDM and Xorg to see whether the display manager was crashing during startup.
Commands:
systemctl status gdm
journalctl -u gdm
cat /var/log/Xorg.0.log
Enter fullscreen mode Exit fullscreen mode
The logs confirmed that something in the graphics initialisation sequence wasn’t working correctly, but they still didn’t explain why.
At this point we had eliminated almost every obvious suspect.
The Breakthrough!!!
After spending hours chasing different hypotheses, we finally stumbled upon something that completely changed the investigation.
ChatGPT suggested manually loading the NVIDIA kernel module before attempting to start the graphical interface. It gave me the following commands:
modprobe nvidia
sudo systemctl start gdm
Enter fullscreen mode Exit fullscreen mode
I honestly wasn’t expecting much. I ran the commands, pressed Enter… and a few seconds later, my login screen appeared. After three hours of staring at a black screen, I felt a wave of relief.
The Root Cause
The experiment showed that the NVIDIA driver worked perfectly once its kernel modules were loaded.
The problem was timing.
During a normal boot, the GNOME Display Manager (GDM) was starting before the NVIDIA modules were available.
Since GDM couldn’t initialise the graphics driver, the graphical session failed, leaving me staring at a black screen.
When I manually executed:
sudo modprobe nvidia
The missing kernel modules were loaded into memory.
Immediately after that,
sudo systemctl start gdm
worked without any complaints because everything GDM needed was finally available.
The Solution
Now that we knew what was happening, the fix became surprisingly straightforward.
Instead of manually running:
sudo modprobe nvidia
sudo systemctl start gdm
Enter fullscreen mode Exit fullscreen mode
After every reboot, I decided to automate the process.
I created a small systemd service called:nvidia-preload.service
Its only job was to load the required NVIDIA kernel modules before the display manager started.
*[Unit]*
*Description=Preload NVIDIA kernel modules*
*Before=display-manager.service*
*After=systemd-modules-load.service*
*[Service]*
*Type=oneshot*
*ExecStart=/sbin/modprobe nvidia*
*ExecStart=/sbin/modprobe nvidia_modeset*
*ExecStart=/sbin/modprobe nvidia_uvm*
*ExecStart=/sbin/modprobe nvidia_drm*
*RemainAfterExit=yes*
*[Install]*
*WantedBy=graphical.target*
Enter fullscreen mode Exit fullscreen mode
Once enabled, sudo systemctl enable nvidia-preload.service, the system booted normally every single time.
No manual intervention.
No GRUB edits.
No recovery mode.
Just a normal desktop.
Conclusion
This was one of those great Linux debugging sessions where you have to look at a level of code you have never seen before. Multiple monitors, broken graphics stacks and graphics driver issues are quite common in Ubuntu and Linux distros. The good thing is that it’s open source, and you can literally do anything in Linux as per your wish. And yes, the online community is also pretty great, with lots of helpful people out there whose data our beloved AI model is trained on…
ChatGPT has been a lifesaver in these kinds of situations. I liked the way that it pretty much behaved like an actual programmer and looked at multiple logs and figured out the solution. It didn’t magically know the answer; it helped me understand unfamiliar concepts, interpret logs, and systematically narrow down the root cause.
Glossary:
TTY (Teletype Terminal): A text-only console that lets you log into Linux even when the graphical desktop fails to start.
GRUB: The bootloader that starts Linux and lets you temporarily modify boot parameters before the operating system loads.
quiet: A kernel boot parameter that suppresses most boot messages, keeping the startup process clean and uncluttered.
splash: Displays the Ubuntu splash screen during boot instead of showing detailed kernel and service logs.
systemd: The init system used by most modern Linux distributions. It starts and manages system services after the Linux kernel finishes booting.
systemd.unit=: A kernel boot parameter that tells “which target (boot mode) to start after the system boots.
multi-user.target: A text-only boot target that starts networking and essential system services but skips the graphical desktop, making it useful for troubleshooting.
NVIDIA Driver: Software that allows Linux to communicate with and use the NVIDIA graphics card.
Secure Boot: A UEFI security feature that allows only trusted and digitally signed software (including kernel modules) to run during boot.
Kernel Module: A piece of code that can be loaded into the Linux kernel to add support for hardware or system features without rebuilding the kernel.
DKMS (Dynamic Kernel Module Support): A framework that automatically rebuilds third-party kernel modules (like NVIDIA drivers) whenever the Linux kernel is updated.
Kernel Update: An update to the core of the operating system. Since drivers interact directly with the kernel, they may need to be rebuilt after a kernel upgrade.
GDM (GNOME Display Manager): The service responsible for displaying the login screen and starting the GNOME desktop session.
Xorg (X.Org Server): The traditional display server that manages communication between the operating system, graphics drivers, and graphical applications.
Graphics Stack: The collection of software components—including graphics drivers, display servers (like Xorg), and display managers (like GDM)—that work together to provide the graphical desktop.
Boot: The process of starting a computer, beginning with the firmware and ending with the operating system becoming usable.
Unsigned Kernel Module: A kernel module that hasn’t been digitally signed with a trusted key. When Secure Boot is enabled, Linux may refuse to load such modules.
Hybrid Graphics: A laptop configuration with both an integrated GPU (AMD/Intel) and a dedicated NVIDIA GPU.
GPU (Graphics Processing Unit): The hardware responsible for rendering graphics and running the desktop environment.
modprobe: A Linux utility used to load kernel modules (such as hardware drivers) into the running kernel.
답글 남기기