Ubuntu NVIDIA Login Loop or Frozen Desktop: Evidence-First Recovery Guide

2026 maintenance note: This is now an evidence-first recovery guide, not a promise that every login loop is an NVIDIA problem. The complete 2019 note is archived at the end and must not be executed as current guidance.

Table of Contents

Legacy boundary: Ubuntu 18.04 and Bumblebee

Ubuntu 18.04 LTS left standard security maintenance in May 2023. Ubuntu Pro/ESM is a separate coverage option, but it does not make an old desktop graphics recipe current. Check Canonical’s live Ubuntu release cycle and plan a tested migration to a supported Ubuntu release; do not attempt a release upgrade in the middle of an unbacked-up recovery.

The old ppa:bumblebee/stable recipe is not a current default. It adds a third-party package source and an older hybrid-graphics stack before establishing the cause. Canonical’s current NVIDIA installation guidance recommends Ubuntu-packaged drivers and ubuntu-drivers, and warns that drivers from other sources can overwrite packaged components and break Secure Boot. Do not blindly add a PPA, purge every NVIDIA package, disable Secure Boot, or install Bumblebee.

Safety model and stop conditions

Use a maintenance window, preserve unsaved work, and ensure important data and any disk-encryption recovery keys are available off the machine. Prefer a local console: a driver change can remove remote graphics or network-dependent access. Record one baseline, make one bounded change, then test before continuing.

Stop and get an administrator or Canonical support involved if the filesystem is read-only, storage reports I/O errors, encrypted data cannot be unlocked, the GPU is absent from PCI detection, APT reports unresolved package state, the system mixes a vendor .run installer with Ubuntu packages, or no tested console/recovery route exists. Do not “repair” those conditions by guessing package names or deleting configuration files.

Evidence	Likely branch	First bounded response
Root/home has no free blocks or inodes	Storage, not NVIDIA	Back up and free only identified data
Home is unwritable or narrowly misowned	Account/session setup	Repair only the confirmed path; never recurse blindly
Display-manager or user-session errors precede GPU errors	Session, extension, or display manager	Diagnose that component before changing drivers
NVIDIA GPU is absent from `lspci`	Firmware, hardware, passthrough, or power state	Stop driver churn and inspect the platform
Module is unsigned/rejected under Secure Boot	Module trust/enrollment	Use Ubuntu’s signed path or approved MOK workflow
Kernel/user-space NVIDIA versions differ	Incomplete transaction or pending reboot	Finish package consistency checks, then one controlled reboot
Keyboard/mouse fails while graphics is healthy	Input/kernel/session stack	Follow the input branch, not a GPU purge

1. Regain a console without changing the system

At the graphical login screen, try Ctrl + Alt + F3 (some hardware needs Fn) and sign in with a local administrator account. Keep the graphical session running initially so its logs remain available. If no TTY works, use “Advanced options for Ubuntu” and the matching kernel’s recovery entry in GRUB; Canonical documents this access pattern in its recovery-mode guide. A live USB is a last access route for backup and read-only inspection, not permission to guess partitions or run repair tools against mounted filesystems.

Capture the release, kernel, boot target, and display-manager state:

cat /etc/os-release
uname -r
systemctl get-default
systemctl status display-manager --no-pager

Expected evidence is a known Ubuntu release, the kernel actually booted, usually graphical.target, and a named display manager such as GDM, SDDM, or LightDM. A missing or failed display-manager unit is a different branch from an NVIDIA module that failed to load. Copy diagnostic output to a private case file; redact usernames, hostnames, home paths, IP addresses, device serials, and tokens before sharing.

2. Rule out disk, inode, mount, and home failures

A full filesystem, exhausted inodes, a read-only mount, or an unwritable home can return the user to the greeter even when the GPU works.

df -hT / "$HOME"
df -i / "$HOME"
findmnt -T /
findmnt -T "$HOME"
stat -c '%U:%G %a %n' /tmp "$HOME"
stat -c '%U:%G %a %n' "$HOME/.Xauthority" "$HOME/.ICEauthority" 2>/dev/null
test -w "$HOME" && echo 'home is writable' || echo 'home is NOT writable'

There should be working space and inodes, writable mounts, /tmp should normally be owned by root:root with mode 1777, and the home directory should be owned by the login user and writable by that user. The authority files may legitimately be absent, especially on Wayland. If one exact file is wrongly owned, back it up and repair only that path using the site’s account policy. Never run recursive chmod/chown over $HOME, never prescribe universal 755 permissions, and never erase dotfiles as a first test.

If space is exhausted, identify what grew, make a backup, and remove only confirmed disposable data. Do not use destructive globs against /var, $HOME, caches, logs, or kernels.

3. Read the display-manager and session evidence

readlink -f /etc/systemd/system/display-manager.service
loginctl list-sessions
journalctl -b -u display-manager --no-pager -n 200
journalctl --user -b --no-pager -n 200
journalctl -b -p warning..alert --no-pager -n 200

Look at timestamps immediately around one failed login. Authentication/PAM failure, a crashing shell extension, an Xorg/Wayland compositor failure, and a GPU module rejection need different fixes. A missing per-user journal is not proof that the session was healthy. Do not publish raw journals: they may contain account names, paths, connected-device details, network addresses, or application data. The Ubuntu-hosted `journalctl` manual explains boot, unit, priority, and tail filters.

Do not switch display managers or toggle Wayland/Xorg merely to “see what happens.” If evidence isolates one session type, back up the display-manager configuration, change one documented setting for that exact release, and retain a console rollback.

4. Identify the GPU topology before choosing a driver

lspci -nnk -d ::0300
lspci -nnk -d ::0302
sudo ubuntu-drivers list
command -v prime-select >/dev/null && prime-select query
command -v switcherooctl >/dev/null && switcherooctl list

The two PCI classes cover display/VGA and 3D controllers. Record each GPU, its PCI ID, “Kernel driver in use,” and candidate Ubuntu packages. No NVIDIA device in this evidence means package replacement is unlikely to help. No output from prime-select or switcherooctl can simply mean that tool is not installed.

A desktop with one discrete GPU, a laptop with integrated plus discrete GPUs, an eGPU, and a virtual-machine passthrough setup are different topologies. On hybrid hardware, determine whether the installed release uses PRIME selection, render offload, or another vendor-supported design. Do not layer Bumblebee, PRIME, hand-written xorg.conf, and multiple switching tools together.

5. Correlate Secure Boot, module, and kernel evidence

mokutil --sb-state
lsmod | grep -E '^(nvidia|nouveau)([[:space:]]|$)'
modinfo -F version nvidia 2>/dev/null
modinfo -F signer nvidia 2>/dev/null
nvidia-smi
journalctl -k -b --no-pager |
  grep -Ei 'nvidia|nouveau|NVRM|secure boot|module verification|lockdown'

Interpret absence carefully: a missing nvidia-smi executable is different from “No devices were found,” and both differ from a module-signature rejection. lsmod shows what is loaded now; modinfo describes a module available on disk. An NVRM: API mismatch points to kernel/user-space versions that do not match, often after an incomplete update or before a required reboot.

Ubuntu verifies kernel modules under Secure Boot. Prefer Ubuntu’s prebuilt signed driver path. If an approved DKMS package asks for Machine Owner Key enrollment, complete the one-time firmware-console workflow and keep its temporary password private. Do not disable Secure Boot as the first fix; it weakens a security boundary and can interact with encrypted-boot recovery. See Canonical’s UEFI Secure Boot documentation.

6. Audit package consistency and source provenance

These commands inspect state; they do not purge packages:

sudo dpkg --audit
sudo apt-get check
apt-mark showhold
dpkg-query -W 'nvidia-*' 'libnvidia-*' 'bumblebee*' 2>/dev/null
grep -RhsnE 'bumblebee|graphics-drivers' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

Stop before driver changes if dpkg --audit or apt-get check reports unfinished/broken state. Review held packages and confirm every NVIDIA/Bumblebee package and repository belongs to the intended Ubuntu release. Repository output can expose internal mirror names or embedded credentials, so redact it before sharing. Canonical’s package-management documentation explains the repository and APT model.

If an old PPA or vendor installer is present, do not blindly purge it while the desktop is inaccessible. Record its exact packages and source, obtain a backup/snapshot, and plan a version-compatible migration with a working console. A broad command such as removing nvidia can also remove unrelated libraries or the only working path and is intentionally not provided here.

7. Make one supported driver change, only when evidence justifies it

First meet all gates: a currently supported Ubuntu release (or an explicitly supported ESM plan), healthy APT state, recognized NVIDIA hardware, Ubuntu repositories selected, backup/recovery access, and a maintenance window. Refresh metadata and inspect Ubuntu’s candidates:

sudo apt update
sudo ubuntu-drivers list

If the list is empty, the GPU is legacy/unsupported, or third-party installer residue remains, stop and investigate rather than forcing a series number. For an ordinary supported desktop where ubuntu-drivers identifies a candidate and the driver branch is the diagnosed fault, the bounded Ubuntu-supported action is:

sudo ubuntu-drivers install

Read and record the proposed package transaction before accepting it. Canonical notes that ubuntu-drivers may remove an installed driver that conflicts with its selection. Do not run this during an unrelated package transaction, and do not combine it with a PPA, NVIDIA .run installer, or speculative manual branch.

After the transaction finishes without errors, audit it and reboot once. If package configuration or MOK enrollment reports failure, do not reboot blindly; preserve the console and resolve that specific error.

sudo dpkg --audit
sudo reboot

8. Treat frozen keyboard/mouse as a separate branch

A working greeter and desktop image with dead input does not prove an NVIDIA fault. Check whether the kernel sees devices and whether libinput/Xorg packages are present:

command -v libinput >/dev/null && sudo libinput list-devices
grep -E 'Name=|Handlers=' /proc/bus/input/devices
apt-cache policy xserver-xorg-input-all xserver-xorg-input-libinput
apt-get --simulate install xserver-xorg-input-all

libinput may be unavailable, and that absence should be recorded rather than hidden. Compare kernel input/HID messages with the session type and test a known-good wired device/port when practical. The xserver-xorg-input-all metapackage is relevant only if an Xorg installation is demonstrably incomplete; it does not repair Wayland, firmware, USB, Bluetooth, kernel HID, or hardware faults.

Only if the active session needs Xorg, the metapackage is missing, and the simulation proposes only expected packages should you apply this separate, reversible transaction:

sudo apt install xserver-xorg-input-all

If the simulation proposes removals, a release transition, or unrelated desktop changes, stop. Do not install the package merely because it appeared in the 2019 anecdote.

9. Verify the result and retain rollback evidence

After one reboot and one login attempt, capture fresh evidence rather than relying on the absence of a visible error:

systemctl is-active display-manager
loginctl list-sessions
nvidia-smi
journalctl -b -p err..alert --no-pager
if [ -n "${XDG_SESSION_ID:-}" ]; then
  loginctl show-session "$XDG_SESSION_ID" -p Type -p State -p Remote
fi

Verify login/logout twice, lock/unlock, keyboard and pointer, both integrated/discrete rendering paths if applicable, external displays, suspend/resume, and the applications that need GPU acceleration. Check that the expected module is loaded for the running kernel and that new logs do not show signature, API-mismatch, compositor, or input errors.

Keep the package history for rollback analysis:

grep -E '^(Start-Date|Commandline|Install|Upgrade|Remove|End-Date)' /var/log/apt/history.log | tail -n 80

If the change worsens boot, use GRUB’s previously installed kernel only as a reversible diagnostic, then restore the known-good snapshot or exact prior package plan. Do not invent a downgrade version: confirm it remains available for the running Ubuntu release and is compatible with its kernel. Escalate with the release, kernel, PCI IDs, package transaction, Secure Boot state, sanitized logs, and exact first failing boot. Ubuntu’s desktop help explains how to report an Ubuntu problem.

Official sources

Historical source archive (do not execute)

The following is the complete visible body of the 2019 source export, with trailing whitespace normalized only. No privacy or URL redaction was needed. To keep the whole source inside one inert fence in this site’s Markdown engine, one zero-width fence breaker was inserted into each of its eight inner triple-backtick markers; the displayed text is unchanged. The obsolete PPA and package commands are historical evidence, not instructions.

After the installation of ubuntu 18.04, I get trapped in a login loop. Then I found a solution online:

```
sudo add-apt-repository ppa:bumblebee/stable
```

```
sudo apt-get update
```

```
sudo apt-get install bumblebee bumblebee-nvidia
```

Voila! I logged in, and I found that the keyboard and mouse is unusable after logging in.

This is the solution to solve this:

```
sudo apt install xserver-xorg-input-all
```