How to Fix a Black Screen After Login in elementary OS

A black screen after entering your password in elementary OS is one of those gremlins that can catch even seasoned Linux users off guard. You type your credentials, hear the familiar chime, and then nothing. Sometimes the mouse cursor floats on a blank canvas; other times the screen stays entirely dark as if the laptop has decided to take an unscheduled arvo nap.

The root cause is almost always tied to the Pantheon desktop layer failing to start correctly. A misbehaving graphics driver, an interrupted system update, or a recently tweaked dconf setting can all interrupt Gala, the window manager, before it has a chance to draw the panels and dock. The good news is that the Pantheon session keeps enough behind the scenes that you can almost always recover without resorting to a full reinstall.

Why Pantheon Fails to Load After Sign-in

When you log in, LightDM hands control to the Pantheon session, which launches Gala, the wingpanel, and Plank in a specific order. If any of those components crashes immediately, the display server has nothing left to render. elementary OS 8 relies on Wayland by default, and the transition from X11 has introduced a new class of failures that didn't exist in earlier releases.

A common trigger is a kernel upgrade that lands before the proprietary NVIDIA driver has been rebuilt. The session tries to load the module, fails silently, and LightDM doesn't catch the error. Hardware-accelerated paths in Mutter, which Gala depends on, also break on certain Intel and AMD GPUs when the mesa packages drift out of sync with the kernel.

Another culprit is a corrupted dconf database. If your laptop lost power mid-update or you experimented with custom themes from Plank, the settings daemon can refuse to start. Without it running, the shell never reaches the stage where it draws wallpaper and icons. None of these scenarios are unrecoverable, but each requires a slightly different approach.

Confirming Your Graphics Driver Situation

Before changing anything, it's worth identifying the GPU and the driver stack in use. Boot to a TTY using Ctrl+Alt+F2, sign in with your username and password, and run lspci -k | grep -A 3 VGA. The output will tell you whether you're running the nouveau, amdgpu, or nvidia module. If the line is missing entirely, the kernel didn't pick up your hardware at all.

For NVIDIA owners, elementary OS does not ship the proprietary driver by default, but many users add it through the standard Ubuntu-style PPA workflow. After a kernel bump, the DKMS build often lags behind by a day or two. Check whether the module exists with lsmod | grep nvidia. An empty result is your smoking gun. Users on older Kepler cards sometimes need the legacy 470 driver, which has its own maintenance cadence.

AMD and Intel hardware generally works out of the box with the in-kernel amdgpu and i915 drivers, but a regression in mesa can leave you staring at a blank screen. Running glxinfo | grep "OpenGL renderer" from the TTY tells you whether software rendering has kicked in. If it reports llvmpipe, your hardware acceleration is gone, and you should avoid the proprietary NVIDIA path entirely on that machine.

Repairing the Session From a Virtual Console

The fastest path back to a working desktop usually starts at a virtual console. Press Ctrl+Alt+F2 (or F3 through F6) to leave the graphical session, then log in with your normal credentials. From there, you can poke around the system without needing a visible desktop.

If the black screen appeared immediately after running apt upgrade, check the package list with dpkg --configure -a and complete any interrupted installations. A half-installed mutter or gala package is a frequent cause. Once that is clean, try sudo systemctl restart lightdm to reload the display manager. You should land back on the login screen.

For those running Pantheon over Wayland, switching to X11 for the current session can be a useful diagnostic. Edit /etc/lightdm/lightdm.conf and set greeter-session=lightdm-gtk-greeter under the [LightDM] section, then force an X session with sudo lightdm --session-child x11. Reboot and you'll boot into the X session instead. If the desktop comes back, you've narrowed the problem down to a Wayland-specific driver bug, which is valuable information for bug reports. Members of the Melbourne Linux Users Group have noted similar issues during quarterly meet-ups, where the discussion often turns to which GPU vendors play nicest with composited Wayland sessions.

Disabling the Compositor as a Short-Term Workaround

Gala is the compositor for Pantheon, and it sometimes refuses to start when an experimental extension or a hand-edited schema breaks under its feet. You can disable it temporarily without uninstalling anything by editing the session file. From the TTY, run sudo nano /usr/share/xsessions/pantheon.desktop and append --no-compositor to the Exec= line.

After a reboot, you'll get a working but unaccelerated desktop. It's not pretty, and there's no fancy shadow rendering, but it confirms that the rest of the stack is healthy. From there, you can re-enable the compositor once you've tracked down the offending configuration. This approach is particularly useful when you've just migrated from elementary OS 7 to 8 and your old tweaks don't survive the transition cleanly.

If the no-compositor session also fails, the problem sits deeper than Gala. In that case, your next step is to reset Pantheon shell settings rather than try to coax the compositor into cooperating.

Resetting Pantheon and DConf to a Known State

Pantheon stores most of its preferences in dconf, and a corrupted schema is surprisingly easy to recover from. From the TTY, log in and run dconf reset -f /org/pantheon/ followed by dconf reset -f /org/gnome/. This wipes your customisations but also restores defaults that the shell can boot from. Once done, sudo systemctl restart lightdm brings the display manager back up.

The reset is aggressive, so back up anything you'd like to keep first with dconf dump /org/pantheon/ > ~/pantheon-backup-$(date +%F).ini. Keep that file somewhere safe, even an external drive or a folder synced through your NBN connection to a home server. If you later want your tweaks back, you can selectively re-import them with dconf load /org/pantheon/ < pantheon-backup.ini.

When dconf doesn't hold the misconfiguration, look at the session autostart files in ~/.config/autostart/. A leftover .desktop file from an old version of an application can launch something that crashes the shell immediately. Disable them one by one with chmod 000 ~/.config/autostart/problematic-app.desktop until the desktop boots cleanly. If you've also been wrestling with Pantheon's mail and calendar integrations, the same careful approach used in configuring-elementary-s-calendar-and-mail-apps-with-google-services applies to dconf edits more broadly, since small, testable changes beat sweeping rewrites every time.

Preventing the Issue From Coming Back

Once you're back on a working desktop, a few habits will keep you from seeing the same problem recur. Hold off on apt full-upgrade for a couple of days after a new kernel is published, especially if you're running NVIDIA's proprietary stack. The DKMS rebuild window is short, but skipping the very first upgrade after a kernel change has saved many an Australian sysadmin from an after-hours callout.

Snapshot your working dconf state regularly and stash it in version control. A simple cron job that runs dconf dump / > ~/.config/dconf-snapshot.ini once a week gives you a clean rollback point. Pair this with Timeshift so the underlying system packages can also be restored. elementary OS doesn't ship Timeshift by default, but it integrates well with the rest of the system once installed.

Finally, keep an eye on journalctl -b -p err after each reboot. Errors logged during the boot sequence often hint at what's about to go wrong on the next graphical login. If you see repeated mutter or gala crash reports, capture the output and post it on the elementary OS community forums. The collective knowledge there is what keeps edge cases like the post-login black screen from becoming brick walls.

Keep a live USB with the current elementary OS image in a drawer. The next time the screen goes dark after sign-in, you'll be able to boot from it, mount your root partition, and undo whatever change caused the trouble without losing any data, a recovery plan that fits on a keyring and works even on the worst arvo.