Ubuntu 24.04 Boots to a Black Screen or Boot Loop: 6 Fixes That Usually Solve It

December 9, 2025 • February 3, 2026 • Read: 22 min • Views: 39

Was this helpful?

You reboot after an update and the machine repays your trust with a black screen. Maybe the vendor logo flashes, maybe you see a blinking cursor, maybe it “reboots” forever like it’s practicing for a marathon. On a laptop it’s annoying. On a remote box it’s a career-limiting event.

This is not a vibes problem. It’s usually one of a handful of very specific failure modes: graphics initialization, a bad kernel/initramfs pairing, Secure Boot refusing a module, a display manager faceplant, a storage/filesystem hiccup, or GRUB getting confused about what “root” means today. Below are six fixes that solve the vast majority of Ubuntu 24.04 black-screen/boot-loop cases—and a fast playbook to figure out which one you’re actually dealing with.

Fast diagnosis playbook (check this first)

When you’re staring at a black screen, your job is to identify which stage of boot failed. Don’t shotgun fixes randomly. You’ll create a second incident on top of the first.

Step 1: Did the kernel boot at all?

Signs it didn’t: instant reboot loop, no disk activity after firmware splash, no GRUB menu, can’t get to TTY, nothing in journal for the last boot.
Likely culprits: GRUB/EFI path issues, wrong root UUID, broken initramfs, corrupt EFI System Partition, firmware boot order drift.
Move to: Fix 6 (GRUB/bootloader) and Fix 3 (initramfs/kernel set).

Step 2: Kernel boots, but you never get a login (GUI)

Signs: you can switch to a TTY (Ctrl+Alt+F3), ping works, SSH works, but display is black or returns to login repeatedly.
Likely culprits: GPU driver mismatch, GDM/Wayland issues, Secure Boot blocked module, broken Xorg/Wayland session.
Move to: Fix 2 (GPU/nomodeset) and Fix 4 (Secure Boot/MOK), then Fix 1 (logs).

Step 3: It boots “sometimes” or only after hard power cycles

Signs: intermittent hang, fsck prompts, delayed boot, “Started GNOME Display Manager” never appears, or random freezes around storage probing.
Likely culprits: filesystem errors, failing disk, NVMe timeouts, full root filesystem, bad resume-from-hibernate config.
Move to: Fix 5 (storage/fs) and the tasks in Practical tasks for disk health and space.

One operational rule: if SSH is available, do everything over SSH and keep a root shell open. It’s less glamorous than thrashing at a local console, but it’s how you avoid making things worse.

Interesting facts and context (why this happens)

Ubuntu 24.04 is an LTS (Long Term Support), which means it’s conservative in some ways—but it still rides newer kernels and graphics stacks than older LTS point releases.
“Black screen” is often a display pipeline failure, not a system failure. Many machines are fully booted with networking up; the screen is just lying to you.
Wayland became the default for many Ubuntu desktop installs years ago, and it changed where failures show up (compositor vs. Xorg) and how to debug them.
NVIDIA’s proprietary driver is still the #1 cause of post-update “boots to black” on desktops. Not because it’s evil—because it hooks deep into kernel/GL and is sensitive to ABI changes.
Secure Boot doesn’t “break Linux,” but it can prevent unsigned kernel modules from loading, which looks exactly like “the driver vanished.”
initramfs is a tiny early-boot filesystem created from your system’s drivers and scripts; if it’s missing storage drivers or has stale module paths, the kernel boots and then can’t mount root.
GRUB’s job got harder with UEFI, because you’re not just loading a bootloader from an MBR anymore—you’re navigating firmware boot entries, EFI files, and vendor quirks.
Boot loops are frequently systemd’s “restart on failure” doing its job, which is great for daemons and awful for humans without logs.
A full root filesystem often presents as a graphics problem because the display manager can’t write state, logs, or auth tokens, so it crashes or loops.

One (paraphrased idea) from Werner Vogels, former AWS CTO, that applies here: “Everything fails, all the time; design and operate assuming that.” Treat a black screen as a normal failure mode with a playbook, not a personal insult.

Joke #1: A black screen is just your computer’s way of asking for fewer surprises and more logging. It’s not wrong.

The 6 fixes that usually solve it

Fix 1: Get a console and read the boot logs like you mean it

Before you “fix” anything, you need evidence. Your targets:

Kernel ring buffer (driver errors, GPU faults, storage timeouts)
systemd journal (service crash loops, display manager failures)
Previous boot logs (if the system rebooted mid-boot)

If the machine is local, try switching to a TTY: Ctrl+Alt+F3. If it’s remote, try SSH. If neither works, you’re in bootloader/initramfs territory—skip ahead to Fix 3 and Fix 6.

What you’re looking for is not “an error” but a pattern: repeated GPU resets, “Failed to start GDM,” “drm” failures, “EXT4-fs error,” “nvme timeout,” or Secure Boot module rejection.

Fix 2: GPU/driver reset (NVIDIA, AMD, Intel) and the “nomodeset” triage

Graphics issues tend to split into two categories:

The kernel modesetting path is broken (you hang early, black screen, maybe a blinking cursor).
The display manager/compositor path is broken (kernel boots, but GUI won’t start or loops).

Triage move: use nomodeset temporarily to get a boot and collect logs. This is not the “fix.” It’s the pry bar that gets the lid open.

If this is NVIDIA, the “fix” is often: get to a TTY, purge the broken driver, boot with the open driver or nouveau temporarily, then reinstall a known-good NVIDIA package that matches your kernel. If it’s AMD/Intel, it’s more commonly a kernel regression or a stale initramfs missing firmware.

Wayland vs Xorg matters too. GDM can be configured to fall back to Xorg when Wayland misbehaves with certain drivers. Don’t treat that as defeat; treat it as a containment strategy.

Fix 3: Rebuild initramfs and verify your kernel set

When Ubuntu updates kernels, it also builds new initramfs images. If the initramfs build fails (disk full, interrupted upgrade, postinst script failure), you can end up with:

GRUB pointing to a kernel that exists but an initramfs that doesn’t
initramfs present but missing modules/firmware due to build errors
a kernel that boots but can’t mount root, causing boot loops

Your move: boot into an older kernel from GRUB if available, then rebuild initramfs for all installed kernels. If no older kernel works, use recovery mode or a live ISO + chroot.

This fix is also where you clean up a half-installed kernel package set. A broken DKMS module (common with NVIDIA or VirtualBox) can also abort initramfs generation.

Fix 4: Secure Boot, MOK enrollment, and why your module “disappeared”

Secure Boot is great when you want to know what code got to execute at boot. It’s less great when you forget you enabled it, then install third-party drivers that require kernel modules.

Typical symptom: after an update, you boot to black screen or GUI fails, and logs show module load failures. For NVIDIA, you’ll see it in journalctl and dmesg. For other DKMS modules, you may see a DKMS build succeed but modules fail to load due to signing issues.

The fix is to either:

properly enroll the Machine Owner Key (MOK) and sign modules, or
temporarily disable Secure Boot in firmware to confirm causality (then decide what your policy is).

If you’re running production endpoints, “disable Secure Boot forever” is rarely an acceptable standard. Use it as a diagnostic lever, not a permanent lifestyle.

Fix 5: Repair filesystem/storage issues that masquerade as “graphics”

Here’s a dirty secret: a lot of “black screen” reports are actually storage failures. The system boots until it hits:

a corrupted filesystem that triggers emergency mode
a root filesystem that’s 100% full, causing services to fail in surprising ways
an NVMe device throwing timeouts, stalling udev and systemd

And because the display manager is near the end of the boot chain, it gets blamed. It’s like yelling at the waiter because the kitchen ran out of gas.

Fixing this involves checking disk health, confirming you can mount root read-write, running fsck where appropriate, and ensuring there’s enough free space for journal, upgrades, and GPU shader caches.

Fix 6: GRUB and bootloader repairs (UEFI, EFI partition, and wrong root)

If you never reliably reach the kernel, you’re in bootloader land. Ubuntu 24.04 on modern hardware is almost always UEFI booting from an EFI System Partition (ESP). Common failures:

ESP full or corrupted
Firmware boot entry points to a missing EFI file
GRUB config points at the wrong root UUID after disk cloning or repartitioning
Dual-boot changes from Windows updates altering boot order

The fix is to confirm the ESP is mounted, reinstall GRUB for UEFI, regenerate grub.cfg, and validate UUIDs in /etc/fstab and GRUB’s view of disks.

Joke #2: UEFI firmware has a personality, and it’s the kind that “forgets” your boot entry right before a deadline.

Practical tasks: commands, what output means, what you decide

Below are real tasks I run in incident mode. Each includes: the command, sample output, what it means, and the decision you make.

Task 1: Confirm whether you can reach a TTY and what kernel you’re on

cr0x@server:~$ uname -a
Linux server 6.8.0-41-generic #41-Ubuntu SMP PREEMPT_DYNAMIC Tue Sep 10 12:34:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

What it means: The kernel is running. This is not a “can’t boot” problem; it’s a “can’t get a usable session” problem (GUI, drivers, services, or storage delays).

Decision: Focus on logs (Task 2/3) and display/GPU (Task 6–10), not GRUB surgery yet.

Task 2: Inspect the previous boot’s critical errors

cr0x@server:~$ journalctl -b -1 -p err --no-pager | tail -n 30
Sep 22 08:11:02 server kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel
Sep 22 08:11:03 server gdm3[1223]: Failed to start session: Failed to open display
Sep 22 08:11:03 server systemd[1]: gdm.service: Main process exited, code=exited, status=1/FAILURE
Sep 22 08:11:03 server systemd[1]: gdm.service: Failed with result 'exit-code'.

What it means: Secure Boot signing or module verification is implicated, and GDM is failing because the GPU stack didn’t come up.

Decision: Go to Fix 4 (Secure Boot/MOK) and Fix 2 (driver recovery). Don’t waste time reinstalling GNOME.

Task 3: Find the boot stage where the system stalls

cr0x@server:~$ systemd-analyze blame | head -n 15
1min 12.340s dev-nvme0n1p3.device
  45.122s network-online.target
  18.090s plymouth-quit-wait.service
  12.881s systemd-journald.service
  11.004s snapd.seeded.service

What it means: The kernel and systemd are alive; a device unit (NVMe partition) is taking over a minute. That’s often timeouts, retries, or a flaky drive.

Decision: Treat as storage reliability issue (Fix 5). Expect dmesg to show NVMe timeouts.

Task 4: Check dmesg for GPU resets, storage timeouts, or firmware missing

cr0x@server:~$ dmesg -T | egrep -i "nvidia|amdgpu|i915|drm|nvme|EXT4-fs error|I/O error|firmware" | tail -n 40
[Mon Sep 22 08:12:01 2025] nvme nvme0: I/O 114 QID 7 timeout, aborting
[Mon Sep 22 08:12:08 2025] EXT4-fs (nvme0n1p3): recovery complete
[Mon Sep 22 08:12:10 2025] i915 0000:00:02.0: [drm] GuC firmware load failed

What it means: Multiple red flags: storage timeouts, ext4 recovery, and missing i915 firmware. Any of these can lead to a black screen.

Decision: Prioritize storage health and firmware packages. If the disk is dying, no amount of display tweaks will save you.

Task 5: Verify free space (a boring check that fixes surprising boot issues)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3    97G   97G     0 100% /

What it means: Root is full. Services that need writes (gdm, journald, apt triggers, user sessions) will fail in weird ways, including login loops and black screens.

Decision: Free space immediately (logs, old kernels, caches). Then rerun pending package configuration and rebuild initramfs if needed (Fix 3).

Task 6: Check which GPU and driver stack the system thinks it has

cr0x@server:~$ lspci -nnk | egrep -A3 "VGA|3D|Display"
00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P GT2 [8086:46a6]
	Subsystem: Lenovo Device [17aa:3a21]
	Kernel driver in use: i915
	Kernel modules: i915

What it means: Intel i915 is the active driver. Black screen could be firmware, kernel regression, or display manager/Wayland behavior.

Decision: If dmesg shows firmware load failures, install the missing firmware and rebuild initramfs (Fix 3). If it’s Wayland-specific, try Xorg fallback (Task 10).

Task 7: Check whether GDM is failing or looping

cr0x@server:~$ systemctl status gdm --no-pager
● gdm.service - GNOME Display Manager
     Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2025-09-22 08:11:03 UTC; 2min 12s ago
   Main PID: 1223 (code=exited, status=1/FAILURE)

Sep 22 08:11:03 server gdm3[1223]: GdmDisplay: Session never registered, failing
Sep 22 08:11:03 server systemd[1]: gdm.service: Failed with result 'exit-code'.

What it means: The display manager didn’t start a working session. This can be GPU driver, Wayland issue, permissions, or disk-full symptoms.

Decision: Pull GDM logs (Task 8) and decide whether to switch to Xorg or temporarily use a different display manager for containment.

Task 8: Extract the GDM and GNOME Shell logs from the current boot

cr0x@server:~$ journalctl -b -u gdm --no-pager | tail -n 80
Sep 22 08:10:59 server gdm3[1102]: Enabling debugging
Sep 22 08:11:02 server gdm3[1223]: Gdm: GdmDisplay: no session desktop files installed
Sep 22 08:11:03 server gdm3[1223]: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

What it means: “No session desktop files” suggests damaged packages or a partially completed upgrade, not purely a GPU issue.

Decision: Validate package state (Task 11), then reinstall the desktop session packages if needed. Don’t keep rebooting hoping it fixes itself.

Task 9: Temporary “nomodeset” boot to get a working console/GUI baseline

cr0x@server:~$ grep -n "GRUB_CMDLINE_LINUX_DEFAULT" /etc/default/grub
6:GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

What it means: nomodeset is enabled persistently in GRUB. That will often allow boot but disables proper GPU acceleration and can cap resolutions.

Decision: Use this only as a diagnostic crutch. Once the real driver/firmware is fixed, remove nomodeset and regenerate GRUB (Task 16).

Task 10: Force GDM to use Xorg instead of Wayland (common containment move)

cr0x@server:~$ sudo sed -n '1,80p' /etc/gdm3/custom.conf
# GDM configuration storage
[daemon]
# Uncomment the line below to force the login screen to use Xorg
WaylandEnable=false

What it means: Wayland is disabled for GDM. This often stabilizes systems with certain NVIDIA setups or compositing regressions.

Decision: If this resolves the black screen, keep it as a short-term mitigation and plan a driver/kernel update window later.

Task 11: Check for a broken upgrade (half-configured packages, DKMS failures)

cr0x@server:~$ sudo dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 linux-image-6.8.0-41-generic   Linux kernel image for version 6.8.0 on 64 bit x86 SMP

What it means: The kernel package didn’t finish configuring—often due to initramfs build failure, disk full, or DKMS error.

Decision: Fix prerequisites (space, DKMS errors), then run dpkg --configure -a and rebuild initramfs (Fix 3).

Task 12: Rebuild initramfs for all kernels

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-40-generic

What it means: initramfs images were successfully generated. If you saw errors here, they matter; scroll up and fix them rather than rebooting into hope.

Decision: If generation succeeds, update GRUB and reboot. If it fails due to DKMS, address the module build/signing issue first (often Fix 4 for Secure Boot).

Task 13: Identify installed kernels and pick a fallback in GRUB

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii/{print $2}'
linux-image-6.8.0-40-generic
linux-image-6.8.0-41-generic
linux-image-generic

What it means: You have at least two kernels. That’s your safety net.

Decision: If 6.8.0-41 fails, boot 6.8.0-40 from “Advanced options for Ubuntu” and repair from there (Fix 3 / Fix 2 depending on symptoms).

Task 14: Verify Secure Boot state from the running system

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

What it means: Secure Boot is enabled, so unsigned third-party modules can be blocked.

Decision: If you rely on NVIDIA or other DKMS modules, ensure MOK enrollment and module signing are correct (Fix 4). Don’t keep reinstalling drivers without addressing signing.

Task 15: Check whether the NVIDIA kernel module is loaded (if applicable)

cr0x@server:~$ lsmod | egrep '^nvidia|nouveau'
nouveau              2795520  2

What it means: The system is using nouveau, not the proprietary NVIDIA module. That could be intentional, or it could mean NVIDIA failed to load.

Decision: If you need proprietary NVIDIA for CUDA/3D, check journal for module load failures and Secure Boot issues (Fix 4), then reinstall the correct driver version (Fix 2).

Task 16: Update GRUB config after changes

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
Found linux image: /boot/vmlinuz-6.8.0-40-generic
Found initrd image: /boot/initrd.img-6.8.0-40-generic
done

What it means: GRUB sees both kernels and initramfs images. Good.

Decision: If GRUB does not list expected images, stop and inspect /boot capacity and filesystem health (Fix 5).

Task 17: Check EFI System Partition mount and free space (UEFI boot issues)

cr0x@server:~$ findmnt /boot/efi
TARGET    SOURCE         FSTYPE OPTIONS
/boot/efi /dev/nvme0n1p1 vfat   rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro

What it means: ESP is mounted and writable (for now). If it’s missing, GRUB installs may “succeed” but not actually land where firmware expects.

Decision: If ESP isn’t mounted, mount it, check /etc/fstab, and repair GRUB/EFI entries (Fix 6).

Task 18: Run a filesystem check when the system is in emergency mode or from a live environment

cr0x@server:~$ sudo fsck -f /dev/nvme0n1p3
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p3: recovering journal
/dev/nvme0n1p3: clean, 512345/6553600 files, 8123456/26214400 blocks

What it means: Journal recovery happened and the filesystem is clean now.

Decision: If fsck reports uncorrectable errors or recurring corruption, stop treating this as a software issue. Replace the disk and restore.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A mid-sized company ran a fleet of Ubuntu workstations for developers and a handful of on-prem GPU boxes for model training. One Monday morning, several desktops updated over the weekend and came up “dead”: black screen, fans spinning, no GUI.

The on-call engineer assumed it was a GNOME regression because “the login screen is black, so it must be the desktop.” They remotely reinstalled desktop packages via rescue shell, restarted GDM, and tried a few different display managers. No luck. Meanwhile, more machines were auto-updating into the same state.

The actual failure mode: Secure Boot had been enabled in firmware on a batch of laptops due to a BIOS update policy. The proprietary GPU driver module was no longer accepted without proper MOK enrollment. The machines were booting fine; the graphics stack wasn’t.

The turnaround came when someone did the unsexy thing: journalctl -b -p err and read it end-to-end. The module verification errors were right there. Once they standardized on either enrolling MOK during driver installation or switching the affected machines to Xorg temporarily, the fleet recovered quickly.

The lesson wasn’t “Secure Boot bad.” It was “assumptions are expensive.” When the screen is black, the kernel logs are your reality.

Mini-story 2: The optimization that backfired

A different team wanted faster patch compliance on employee endpoints. They tuned unattended upgrades to apply automatically and reboot overnight. On paper, great: fewer known vulnerabilities hanging around, fewer manual reboots, fewer “I’ll do it later.”

Then a driver-kernel mismatch hit a subset of machines with discrete GPUs. The reboot happened quietly at 3 a.m. The next morning, users arrived to black screens and a helpdesk queue that looked like a denial-of-service attack—except self-inflicted.

The “optimization” was assuming reboots are a harmless commodity. In reality, reboots are production changes: kernel, initramfs, drivers, firmware, and bootloaders all get exercised. If you don’t have staged rollouts, canaries, or at least a “don’t reboot if last boot was bad” gate, you’re just playing roulette at scale.

They fixed it by implementing phased rollouts (even a crude ring-based schedule), keeping at least two known-good kernels, and ensuring remote access stayed available (SSH enabled, console access documented). Unattended upgrades stayed—but with guardrails. Boring, effective.

Mini-story 3: The boring but correct practice that saved the day

A finance org ran Ubuntu on a few hundred laptops and some shared workstations. Their security posture was strict, so Secure Boot stayed enabled. They also had a simple but disciplined practice: every machine kept two kernels installed, and they routinely validated that GRUB showed “Advanced options” with multiple entries.

When a kernel update caused a boot regression on a particular hardware model, they didn’t need heroics. Users were instructed to select the previous kernel from GRUB. IT had a short script to pin the bad kernel version and hold updates until the fix landed.

What made it work wasn’t technical brilliance. It was operational muscle memory: “If a new kernel fails, boot the previous one, collect logs, then remediate.” They also had a habit of checking free space on / and /boot during routine maintenance, which prevented the classic initramfs build failure due to a full filesystem.

The incident didn’t become a crisis because the organization treated bootability as a reliability feature—tested, preserved, and documented. Predictability beats cleverness.

Common mistakes: symptom → root cause → fix

1) Symptom: Black screen, but you can SSH in

Root cause: Display manager failing (GDM) due to GPU driver mismatch, Wayland issues, or disk full.
Fix: Check systemctl status gdm and journalctl -u gdm. If NVIDIA, validate module load + Secure Boot (Fix 4). Try Xorg fallback (Fix 2 / Task 10). Check disk usage (Task 5).

2) Symptom: Boot loop after kernel update; GRUB appears briefly

Root cause: Broken initramfs or kernel postinst failure; sometimes DKMS broke during upgrade.
Fix: Boot an older kernel, run dpkg --configure -a, then update-initramfs -u -k all and update-grub (Fix 3).

3) Symptom: “Started GNOME Display Manager” never appears; long stalls

Root cause: Storage delays (NVMe timeouts), fsck waits, or a failing drive.
Fix: Use systemd-analyze blame and dmesg filtering for nvme/I/O (Task 3/4). Run fsck as needed (Task 18). Replace suspect hardware (Fix 5).

4) Symptom: Login loop (enter password, returns to login)

Root cause: Full disk, broken user session files, wrong permissions in home, or GDM/Wayland crash.
Fix: Check df -h, fix space; inspect journalctl for session errors; try Xorg fallback; confirm home permissions. Restart gdm after remediation.

5) Symptom: Black screen immediately after selecting Ubuntu in GRUB

Root cause: Kernel modesetting regression or GPU driver deadlock early in boot.
Fix: Temporary nomodeset in GRUB to boot, then repair driver/firmware and remove nomodeset (Fix 2).

6) Symptom: No GRUB menu; straight to firmware or “no boot device”

Root cause: EFI boot entry missing, ESP corrupted/unmounted, disk not detected.
Fix: Verify firmware boot order, mount ESP, reinstall GRUB in UEFI mode via chroot if needed (Fix 6). If disk missing, it’s hardware.

Checklists / step-by-step plan

Checklist A: If you can reach a TTY or SSH (most common case)

Confirm kernel is running: uname -a.
Pull previous boot errors: journalctl -b -1 -p err.
Check disk space: df -h / and also df -h /boot, df -h /boot/efi.
Check GDM status: systemctl status gdm and journalctl -u gdm.
Check GPU driver state: lspci -nnk, lsmod, and dmesg -T for drm/gpu errors.
If NVIDIA + Secure Boot enabled: confirm with mokutil --sb-state and decide on MOK enrollment (Fix 4).
Repair package state: dpkg --audit, then dpkg --configure -a if needed.
Rebuild initramfs: update-initramfs -u -k all, then update-grub.
Containment if needed: force Xorg in /etc/gdm3/custom.conf and restart gdm.
Reboot once—one clean reboot, not five angry ones—then re-check logs.

Checklist B: If you cannot reach TTY/SSH (bootloader/initramfs path)

At boot, force GRUB menu (hold Shift or press Esc depending on firmware timing).
Try “Advanced options” and boot an older kernel.
Try recovery mode and “root” shell. If you get a shell, proceed with Checklist A from log inspection and disk checks.
If no installed kernel boots: use a live Ubuntu ISO, mount root, chroot, then rebuild initramfs and reinstall GRUB (Fix 3 + Fix 6).
Verify ESP mount and rebuild EFI boot entries.
Only after software remediation fails: suspect disk/controller hardware.

Checklist C: The “stop making it worse” rules

Don’t purge random packages until you’ve captured logs from journalctl -b -1 and dmesg.
Don’t keep rebooting; you overwrite the evidence and you stress failing hardware.
Don’t pin the system to nomodeset permanently unless it’s a kiosk and you enjoy low resolution and weirdness.
Don’t disable Secure Boot permanently as a reflex. Decide intentionally: security policy vs. operational simplicity.

FAQ

1) How do I know if it’s “just the GUI” and not the whole system?

If you can switch to a TTY (Ctrl+Alt+F3) or SSH in, the kernel booted and systemd is running. Then you’re debugging graphics/display manager or late-boot storage delays, not GRUB.

2) Does “nomodeset” fix the problem?

No. It often lets you boot by avoiding kernel modesetting, which gives you a foothold to repair drivers/firmware. Treat it like a spare tire.

3) Why does an NVIDIA driver update cause a black screen after a kernel update?

The proprietary NVIDIA stack depends on kernel interfaces and builds modules (often via DKMS). If the module build fails, or Secure Boot blocks it, the display stack can’t start.

4) What’s the quickest single log command that usually tells the truth?

journalctl -b -1 -p err is a strong start, especially after a boot loop. It filters to errors from the previous boot, when the failure occurred.

5) Can a full disk really cause a black screen?

Yes. GDM, GNOME Shell, and even authentication components need to write files. If / is full, you can get login loops, session failures, and a “blank” desktop.

6) Should I switch from Wayland to Xorg?

If you’re blocked and need the machine usable today, yes—switching GDM to Xorg is a reasonable containment step. Then schedule time to fix the underlying driver/kernel issue.

7) How do I recover if I can’t even see the GRUB menu?

Try forcing it with Esc/Shift during boot. If firmware never hands off to GRUB, you may need a live ISO to repair the EFI boot entry and reinstall GRUB (Fix 6).

8) Is this more common on desktops than servers?

Yes. Servers often run without a GUI and with conservative driver needs. Desktops combine GPUs, compositors, and frequent driver changes—more moving parts, more failure modes.

9) If fsck “fixes” things once, am I done?

Not necessarily. One recovery after an unclean shutdown is normal. Repeated filesystem repairs or NVMe timeouts are a reliability signal: watch SMART/health and plan replacement.

Conclusion: next steps that prevent repeat incidents

Ubuntu 24.04 black screens and boot loops are rarely mysterious. They’re usually one of six things: GPU drivers, initramfs/kernel mismatch, Secure Boot module policy, display manager/Wayland issues, storage/filesystem failures, or GRUB/EFI drift. The trick is to identify the stage of failure fast, then apply the fix that matches the evidence.

Next steps that actually reduce future pain:

Keep at least two kernels installed and confirm GRUB shows them.
Make free space checks routine for /, /boot, and /boot/efi.
If you use NVIDIA and Secure Boot, standardize MOK enrollment and module signing procedures instead of improvising per machine.
Stage updates and reboots. A reboot is a change event, whether you respect it or not.
When something fails, capture journalctl -b -1 output before you start “fixing.” Logs don’t lie; humans do.