Installing graphics drivers on Linux starts with a choice that Windows users may not expect: whether a separate driver installation is needed at all. AMD graphics usually use the driver stack supplied by the distribution. NVIDIA users often need an extra package, but the correct package depends on the GPU generation, distribution and kernel.
The safest approach is to use your distribution’s driver tools, verify that applications actually use the GPU, and troubleshoot the failing layer before replacing anything. A black screen, missing monitor and game crash can have different causes. Treating all three with the same driver reinstall is troubleshooting by lottery.
This guide covers NVIDIA and AMD desktop graphics, including Secure Boot, hybrid laptops, Wayland, missing acceleration and recovery after an update. If you are still assessing a machine before installation, start with checking Linux hardware compatibility.
Choose the Right Graphics Driver Stack
A Linux graphics driver is not one interchangeable download. The kernel driver controls the hardware, while libraries outside the kernel provide graphics interfaces such as OpenGL and Vulkan. Firmware and the desktop’s display components also take part. Mesa’s RADV documentation describes the division between the AMD kernel driver and its Vulkan driver.
This distinction matters during diagnosis. A working desktop does not prove that Vulkan works. A working Vulkan game does not prove that suspend, video decoding or every monitor connection works.
AMD: Start With the Distribution’s Packages
For ordinary desktop use and gaming on supported Radeon hardware, use the graphics stack included with your distribution. This normally means the amdgpu kernel driver, Mesa graphics libraries and the required firmware. AMD’s Linux GPU driver guidelines recommend distribution packages for many desktop configurations, including supported APUs and discrete graphics cards.
Do not install a vendor package simply because the Driver Manager shows no optional AMD driver. That can be the expected result: the necessary software is already installed.
Professional application certification and GPU computing are separate decisions. A requirement from a CAD application or compute framework deserves its own compatibility check. It does not mean every Radeon desktop needs a replacement graphics stack.
NVIDIA: Match the GPU Generation Before Choosing a Branch
NVIDIA provides both open and proprietary kernel modules. Its open modules support Turing and newer architectures, and became the suggested default starting with the 560 series. Maxwell, Pascal and Volta require the proprietary kernel module instead. These are hardware restrictions, not preferences; see NVIDIA’s kernel module compatibility guidance.
Also distinguish NVIDIA’s open kernel modules from Nouveau. They are different driver projects. Selecting an NVIDIA package labelled “open kernel” does not mean selecting Nouveau, nor does it make every component of the NVIDIA driver stack open source.
Older cards need particular care. The 580 series is the final Linux driver branch supporting Maxwell, Pascal and Volta, as recorded in NVIDIA’s Unix legacy driver support notice. Installing a newer branch will not add support for those architectures.
For much older hardware, check whether a maintained driver remains available before changing distributions or kernels. The practical options may include an open driver, a supported older software combination or replacing the card. Our guide to running Linux on older computers covers the broader trade-offs.
Prepare Before Changing Drivers
Record your distribution release, running kernel, GPU model and current driver before making changes. On a laptop, record both graphics devices rather than assuming the NVIDIA or AMD badge identifies the only GPU.
Also note whether Secure Boot is enabled and whether the problem began after a kernel update, driver update, firmware change or monitor replacement. That timeline is often more useful than a screenshot of a black display.
Before installation:
- Finish pending system updates and restart if requested.
- Save open work and connect a laptop to reliable power.
- Keep a known working kernel available in the boot menu.
- Create a recoverable backup and retain access to installation or recovery media.
A snapshot can help reverse package changes, but do not assume it protects personal files or a failed disk. Use a proper desktop backup and recovery plan before changing software that could remove access to the graphical session.
Choose one driver packaging route. If you previously used a vendor installer, establish how it was installed and how to remove it before switching to distribution packages. Do not layer another installation method over an unexplained existing setup.
Install NVIDIA Drivers Through Your Distribution
Use the driver manager or documented package procedure for your exact distribution release. Package names copied from another distribution, or from an older tutorial, are not a reliable installation plan.
Driver packages also differ from application packages. Some include prebuilt kernel modules; others build a module for the installed kernel. If you are unfamiliar with repository and dependency handling, review how APT, DNF and Pacman manage packages before attempting manual repairs.
Ubuntu
For Ubuntu Desktop, use Additional Drivers rather than downloading the standalone NVIDIA installer. Ubuntu’s NVIDIA installation instructions recommend Ubuntu packages and the tested desktop driver offered for the hardware.
- Open Software Updater, install available updates and restart when required.
- Open Additional Drivers and wait for hardware detection to finish.
- Select the appropriate tested NVIDIA desktop driver, then choose Apply Changes.
- Complete any requested Secure Boot enrollment and restart after installation finishes.
Avoid selecting a server package just because its version number looks suitable. For a normal desktop, use the desktop recommendation. Let hardware detection identify compatible branches rather than copying a version number from a guide.
If the installation reports an error, resolve it before rebooting where possible. Record the failed package name and error text; “the installation stopped” leaves too much room for guesswork.
Linux Mint
Linux Mint provides Driver Manager under Menu, Administration. Select the appropriate available driver, apply the changes and restart. These steps are documented in the Linux Mint hardware driver installation guide.
Wait for the package operation to finish. Closing the window, restarting during installation or beginning another package operation makes an otherwise routine change harder to diagnose.
Fedora and Other Distributions
On Fedora Workstation, NVIDIA installation can involve a third-party repository and a module signing workflow. Fedora’s NVIDIA installation design for GNOME Software includes driver installation followed by enrollment of a locally generated signing key.
Check the available procedure for your Fedora release and desktop edition. If the graphical software manager offers multiple driver sources, choose one documented route and stay with it. Do not combine competing repository packages because they share the NVIDIA name.
The same discipline applies to Debian, Arch, openSUSE and their derivatives. Follow the instructions for the distribution you actually run. On an image based or atomic desktop, use its host driver procedure rather than assuming instructions for a conventional package managed installation apply.
Complete Secure Boot Enrollment
When a driver installation asks you to enroll a Machine Owner Key, that enrollment is part of the installation. An installed module can still fail to load if the system does not trust its signing key.
The usual enrollment screen appears during restart, before the desktop loads. Select Enroll MOK, confirm the request and enter the enrollment password created or displayed during installation. This may not be your normal account password. NVIDIA’s GNOME Software and MOK enrollment instructions show the sequence.
Only approve a key associated with an installation you deliberately started. If you missed the screen or entered the wrong password, repeat your distribution’s enrollment procedure rather than assuming the driver package needs replacing.
Disabling Secure Boot should not be the first repair. Establish whether the module built successfully, whether it was signed, and whether the corresponding key was enrolled.
Install or Update AMD Graphics Support
For an AMD desktop, begin with a complete distribution update rather than a separate driver download. Update the supported kernel, firmware and Mesa packages together, then restart before judging the result.
If the GPU is newer than the distribution’s installation image, check its supported hardware update options. A more recent supported installation image or kernel track is preferable to assembling an unexplained mixture of development packages.
Check that firmware is installed and that no previous troubleshooting change prevents the driver from loading. Boot options such as nomodeset can interfere with normal AMD graphics operation, while module blocklists can prevent amdgpu from loading at all. These checks appear in the ArchWiki AMDGPU loading guidance.
Do not treat every AMD card as identical. Older Radeon hardware may use a different kernel driver depending on the GPU and kernel combination. A driver name copied from another machine is not enough evidence to force a switch.
If an application requires AMD’s packaged software, verify the supported distribution release, GPU and application version first. Keep the requirement narrow: needing a compute runtime does not automatically justify replacing a working desktop graphics configuration.
After an unsuccessful vendor installation, return through its documented removal procedure. Do not manually delete graphics libraries until you know which packages own them and what will restore them.
Verify That Hardware Acceleration Actually Works
Verification should answer three separate questions: does Linux detect the GPU, does the intended kernel driver control it, and does the affected application render on it?
Start with the desktop’s About or System Information panel. Record the graphics devices it lists, then inspect the application that matters. A browser, game and video editor can use different graphics paths, so one successful test does not settle every case.
The NVIDIA System Management Interface, commonly named nvidia-smi, can report the NVIDIA driver and GPU state. However, detecting the NVIDIA card does not prove a particular game uses it. Check the game’s renderer information, diagnostic overlay or application logs as well.
OpenGL and Vulkan information tools can identify the renderer used by a test application. If those tools are unfamiliar, our Linux terminal guide provides the groundwork for reading diagnostic output without changing system settings.
A renderer labelled llvmpipe means that test is using Mesa’s CPU based software renderer rather than the intended GPU. The Mesa LLVMpipe documentation identifies it as a software rasterizer. On a local desktop where GPU acceleration is expected, that is a useful fault indicator.
Record whether each test runs locally, through remote access or inside a virtual machine. Compare like with like. A remote session’s renderer is not necessarily evidence of what the physical desktop uses.
Check Wayland and Hybrid Graphics Separately
Do Not Assume Every Display Problem Requires X11
Identify the session type before following display server advice. Check the desktop’s session information or login screen, and record whether the failure affects Wayland applications, older applications running through Xwayland, or both.
If another session type is installed and supported, testing it can help narrow a problem. Treat that as a comparison, not proof that one display system is universally broken. Do not make an absent X11 session a prerequisite for repairing a current desktop.
Keep driver, desktop and display configuration changes separate. Updating the driver, changing session type and disabling several monitor features at once may hide the symptom, but it also hides the cause. For desktop related differences, see our GNOME and KDE Plasma comparison.
Hybrid Laptops Need Application Level Checks
A hybrid laptop may use its integrated GPU for the desktop and a discrete GPU for selected workloads. That arrangement is not evidence that the discrete driver failed. PRIME supports graphics offloading between devices; the ArchWiki PRIME documentation covers these arrangements and their troubleshooting considerations.
Where the desktop offers a “Launch using Discrete Graphics” option or equivalent, test the affected application through that route. Check its renderer afterward rather than relying on the menu selection alone.
Test external outputs individually too. Record which connector, adapter and display are involved, and whether the problem changes with a different graphics mode. Do not assume every laptop port follows the same route to the GPU.
Forcing every application onto the discrete GPU is a poor diagnostic shortcut. First establish whether offloading works, then choose a daily configuration that balances performance with laptop battery life.
Troubleshoot the Symptom, Not Just the Driver Name
Begin with the smallest repeatable test. Record when the problem occurs, what changed immediately before it started, and whether it affects one application or the whole session.
| Symptom | First comparison | Useful evidence |
|---|---|---|
| Black screen after an update | Previous kernel and one directly connected display | Boot log and driver loading errors |
| Desktop works, game fails | Another graphics application and the game’s reported renderer | Game log and graphics library versions |
| Only one monitor fails | Another cable, connector and simpler display mode | Resolution, refresh rate and connection path |
| Failure after suspend | Fresh boot compared with resume | Logs covering the suspend and resume period |
| Only a packaged application fails | Another supported package format | Application runtime and graphics extension information |
Black Screen After Installing or Updating NVIDIA
First distinguish a missing image from a failed boot. Does the monitor report no signal, does the login screen appear, or does the screen go blank only after signing in? Those are different starting points.
If a previous kernel is available, test it without removing the new one. If the previous kernel works, focus on the module installation for the newer kernel before replacing the entire driver stack.
For configurations that build modules locally, check the build result and matching kernel headers. For prebuilt modules, check that the package covers the running kernel. Also verify signing and enrollment where Secure Boot applies.
An NVIDIA “Driver/library version mismatch” after an update can mean newer libraries are installed while the old kernel module remains loaded. A restart can bring them back into agreement; Ubuntu documents this case in its NVIDIA module installation and troubleshooting guidance. Finish pending package work before restarting.
If the mismatch remains after rebooting, compare the installed package versions and repositories. Repeatedly reinstalling one package will not necessarily repair components supplied by another route.
Games Fail but the Desktop Works
Check the game’s actual GPU and graphics API before changing the desktop driver. Try another application using the same API, then compare whether the failure follows one game or the wider graphics path.
For native Steam installations, verify the required graphics libraries for both architectures. Valve’s Steam for Linux requirements include both 64 bit and 32 bit graphics drivers. A working 64 bit desktop is not a complete test of those requirements.
Install the libraries matching your GPU through the distribution’s documented Steam procedure. Do not accept a package for the wrong vendor simply because a package manager offers it as a possible dependency.
Once the graphics path works, investigate game settings, compatibility tools and individual title issues through our guide to Steam and Proton on Linux. Keep those changes separate from driver repairs.
A Flatpak Application Fails While Native Applications Work
Flatpak applications use runtime graphics components rather than simply sharing every host library. Flatpak’s graphics extension documentation describes extensions selected using the active graphics driver, including NVIDIA driver information.
Update the application and its runtimes after a host driver change. Then compare another graphics application before replacing host packages. If the fault stays inside one Flatpak application, investigate that application and runtime first.
Our guide to native packages, Flatpak and Snap explains the packaging differences. Changing package format can be a diagnostic comparison, but it should not conceal an unresolved system fault.
Missing Monitors, Flicker or Incorrect Refresh Rates
Reduce the display setup to one monitor connected directly to the computer. Temporarily remove docks, adapters and extra displays. Start with a conservative resolution and refresh rate, then restore the original configuration one change at a time.
If the failure appears only after enabling a feature such as variable refresh rate, fractional scaling or HDR, record that boundary. Test the feature separately from driver updates so the result stays useful.
Check the physical connection as well. A different cable or port is a sensible comparison, especially when the problem affects only one display. Reinstalling Mesa cannot test a cable.
Freezes, GPU Resets and Failures After Suspend
Collect logs around the failure rather than searching only for the driver name. Preserve messages immediately before and after the event, and record the workload, connected displays and whether the machine had resumed from sleep.
AMD fault reporting can involve kernel driver and firmware state; the kernel’s AMD GPU debugging documentation covers how those faults are investigated. A timeout or reset message is evidence of a failure, not a diagnosis of defective hardware by itself.
Return overclocking or undervolting settings to defaults before comparing software versions. Test a fresh boot separately from suspend and resume, and compare one change at a time.
Use journalctl to inspect boot and kernel logs, including the previous boot where available. Save the evidence before another update makes the original software combination harder to reconstruct.
Recover Without Making the Failure Worse
Use the least disruptive route that restores access. Try a previous kernel, a supported recovery entry or a text console before removing packages. If the computer still responds, avoid repeated forced power cuts while package operations may be running.
Undo changes in reverse order. If the failure followed a driver branch switch, return through the same driver manager or package route. If it followed a custom configuration change, preserve a copy and reverse that change before altering unrelated packages.
Do not delete every package containing “NVIDIA,” “AMD” or “Mesa.” Read the proposed removal transaction. If it includes the desktop environment or a large collection of unrelated applications, stop and establish why.
Use our Linux boot recovery guide when the problem extends beyond graphics. A driver fault and a damaged boot configuration need different repairs.
If installed recovery options are unavailable, a bootable Linux USB drive can provide access for backing up files and inspecting the system. Avoid reinstalling the operating system before preserving both your data and the evidence of what failed.
Keep a Working Configuration Maintainable
After restoring graphics, test the tasks that matter: normal login, your usual applications, external displays, video playback, and suspend and resume. Repeat the original failing workload rather than treating one successful boot as a complete result.
Keep a short record of the working kernel, driver branch and relevant package versions. Before a major change, check hardware support and retain a recovery route. Avoid permanent update freezes as a substitute for diagnosis; use a planned approach to Linux security updates instead.
If you need help, provide the distribution release, kernel, exact GPU model, driver package versions, session type and relevant logs. Explain what reliably triggers the fault and which comparisons you have already tried. Remove account names, serial numbers and other private details before posting logs publicly.
The useful endpoint is a supported driver configuration that renders on the intended GPU and survives your normal workload. Keep the installation route simple, verify each layer, and let repeatable evidence decide the next change.