A black screen after Ubuntu starts is a symptom, not a diagnosis. The safest approach is to identify how far the machine boots before changing drivers, kernel parameters, or packages. A system that reaches a TTY or responds over SSH needs a different repair path from one that never shows firmware or GRUB, and both differ from a complete freeze.
First determine whether Ubuntu is still running behind the black screen. That single distinction prevents many unnecessary and risky repairs.
Identify which black-screen state you have
1. No firmware logo, GRUB menu, or display output
If the screen stays blank from power-on, the problem may be outside Ubuntu: display input, cable, dock, monitor, GPU output, firmware settings, or hardware initialization. Test another display or cable and disconnect unnecessary docks or adapters before changing the operating system.
2. GRUB or boot messages appear, then the screen turns black
This points more strongly toward a kernel, graphics-driver, display-mode, or early graphical-startup problem. Note the last visible message and whether keyboard indicators still respond.
3. Ubuntu runs, but the graphical login does not appear
Try a virtual console with Ctrl+Alt+F3. If a login prompt appears, the kernel and core system are running. The fault is likely in the display manager, desktop session, graphics stack, or a recent package change.
4. The machine is completely frozen
A true freeze usually means there is no working TTY, no SSH response, no useful keyboard response, and sometimes no network response. Treat this as a broader kernel, hardware, firmware, or low-level driver investigation rather than only a desktop problem.
The line “/dev/... clean, X/Y files, P/Q blocks” is usually a filesystem-check status message. It does not, by itself, prove that the filesystem caused the black screen.
Start with observations, not repairs
Before changing anything, record:
- Whether firmware and GRUB are visible.
- Whether an older kernel boots.
- Whether Ctrl+Alt+F3 opens a TTY.
- Whether the machine answers ping or SSH.
- Whether the failure began after a kernel, graphics-driver, firmware, or package update.
- Whether the disk is full or the filesystem reported actual errors.
Photograph the last visible screen if possible. A precise last message is more useful than a general description such as “Ubuntu will not boot.”
Test an older kernel from GRUB
If GRUB is available, open Advanced options for Ubuntu and choose the previous kernel without “recovery mode” first. This is a reversible test: it does not remove the newer kernel.
Expected result: If the older kernel reaches the desktop, the problem is probably tied to the newer kernel, its modules, or its interaction with the installed graphics stack.
Verification: After logging in, run `uname -r` to confirm which kernel is active.
Rollback consideration: Keep the known-good kernel installed until the newer path is verified. Do not purge kernels merely because one boot failed.
Use a TTY to check the graphical login
When Ctrl+Alt+F3 gives you a login prompt, sign in and inspect the display manager:
`systemctl status display-manager`
Purpose: Shows the display-manager unit’s current status and recent service information.
Expected result: An active service suggests the problem may be farther down in the session or graphics stack. A failed service should show a recent error and a unit name.
Verification: Record the exact failed unit and its error before restarting anything.
Next, inspect the current boot:
Purpose: Displays warning-and-higher messages from the current boot.
Then inspect the previous boot if the failure forced a restart:
`journalctl -b -1 -p warning`
For kernel-only messages from the previous boot, use:
`journalctl -k -b -1`
Purpose: Helps separate a display-manager failure from a kernel, GPU, firmware, or module error.
Expected result: Look for repeated errors involving the display manager, DRM, GPU driver, firmware loading, or a recently changed package. One isolated warning is not automatically the cause.
Verification: Match timestamps to the moment the screen went black.
Save relevant logs before experimenting: `journalctl -b -1 > previous-boot.txt`. A preserved baseline makes it easier to tell whether a change improved the fault or merely changed the symptoms.
Use nomodeset only as a temporary diagnostic
From the GRUB editor, temporarily adding `nomodeset` to the Linux boot line can test whether early graphics mode-setting is involved. This change applies only to that boot unless you deliberately make it permanent.
Expected result: The system may reach a basic low-resolution display if normal graphics mode-setting is the blocker.
Important limitation: `nomodeset` disables normal kernel mode setting and accelerated rendering; it is a diagnostic fallback, not a universal repair. A successful boot with it is evidence for further graphics diagnosis, not a finished repair.
Rollback: Reboot without the temporary parameter. Do not add it permanently to GRUB until the hardware, driver, and kernel cause is understood.
Check recent changes before replacing drivers
If the failure began immediately after an update, review recent package activity:
`grep -E " install | upgrade | remove " /var/log/apt/history.log`
Purpose: Identifies recent kernel, graphics, display-manager, and desktop package changes.
Expected result: A change close to the first failed boot becomes a testable lead, not proof of causation.
Verification: Compare package timestamps with the last known-good boot.
Avoid random driver purges. First identify the hardware with `lspci -nnk | grep -A3 -E "VGA|3D|Display"` and record the driver currently in use. A replacement plan should include a known-good kernel, recovery access, and a way to reverse the package change.
Separate black-screen symptoms from disk and filesystem problems
Low free space is a separate condition worth checking rather than assuming the filesystem caused the black screen. From a TTY or recovery shell, inspect capacity with `df -h` and inode use with `df -i`.
Do not delete files until the affected mount is identified. For that separate scenario, use my guide to fixing Ubuntu when the disk is full and it won't boot.
Actual filesystem errors require a different path. Never run `fsck` against a mounted filesystem. Use recovery mode or suitable offline media, verify the correct device, and preserve important data before repair.
Do not flash firmware, purge graphics packages, delete files from `/boot` or `/var/lib`, or add multiple undocumented kernel parameters as a trial-and-error bundle. Make one reversible change at a time and keep a recovery path.
When hardware or firmware becomes the stronger suspect
Escalate beyond the desktop stack when:
- There is no firmware or GRUB output on any known-good display.
- Multiple kernels fail identically before user space starts.
- The machine freezes under another operating system or live environment.
- Logs repeatedly show GPU resets, firmware-load failures, machine-check events, or storage I/O errors.
- The issue follows a specific dock, monitor, cable, GPU port, or firmware setting.
At that point, test with minimal peripherals, known-good display connections, vendor diagnostics, and a live environment. Firmware updates should be performed only with the correct model, stable power, verified instructions, and a recovery method.
A safe diagnostic order
- Confirm power, display input, cable, dock, and monitor behavior.
- Determine whether firmware and GRUB are visible.
- Try a previous kernel from Advanced options.
- Test whether a TTY or SSH session works.
- Read display-manager, current-boot, previous-boot, and kernel logs.
- Check disk blocks and inodes.
- Use one temporary graphics test only when the evidence supports it.
- Identify hardware and recent package changes before altering drivers.
- Keep a known-good kernel and recovery route until normal boot is stable.
The objective is not to find the fastest command. It is to locate the failing layer and make the smallest reversible change that tests a clear hypothesis.
