How to Check Linux Hardware Compatibility Before Switching (2026 Guide)

There is a particular moment that happens to everyone who has ever migrated to Linux: the moment you realize that your wireless card does not work. You have already wiped Windows. The installer finished. The desktop loaded. You opened a browser, tried to connect to Wi-Fi, and nothing. You stare at the network manager. You run a few commands you found on a forum. You reboot. Still nothing. The hardware exists. Linux sees it. But the firmware blob that makes it functional is nowhere to be found, and the driver that ships with the kernel is a half-finished community port that supports three out of the seven radio frequencies your card uses.

This does not happen because Linux is broken. It happens because hardware compatibility is a genuinely complex topic that migration guides treat as a checkbox rather than a discipline. This guide treats it as a discipline.

Why Hardware Compatibility Is Not Just a Yes/No Question

The conventional wisdom around Linux hardware compatibility goes something like this: Intel graphics work great, AMD graphics work great, NVIDIA requires proprietary drivers, and wireless cards are a gamble. That framing is not wrong, but it is dangerously incomplete. It trains people to think about compatibility as binary when it is a spectrum with multiple independent dimensions.

Consider what "working" means for a piece of hardware:

• Detection means the kernel enumerates the device and knows it is there.
• A driver exists means a kernel module claims the device.
• Functional means the device performs its primary job.
• Fully functional means every capability the hardware supports is accessible.
• Stable means that functionality persists across kernel updates, sleep/wake cycles, and edge cases.

A device can be detected but have no driver. It can have a driver that enables basic function but leaves advanced features dark. It can work perfectly until you update the kernel and a dependency breaks. It can work on kernel 6.1 but fail on 6.6 because a maintainer changed an API. Every layer of that stack deserves examination before you commit to a switch.

The Linux kernel ships with thousands of hardware drivers. The drivers/net/wireless directory alone contains more than 80 distinct driver subdirectories as of recent kernel releases. Some of those drivers are mature and mainline. Some are community-maintained and receive irregular attention. Some depend on binary firmware blobs that must be installed separately from the linux-firmware package. Understanding which category your hardware falls into before you migrate is the difference between a smooth transition and a frustrating week of debugging.

The Infrastructure of Hardware Detection on Linux

Before running a single command, it is worth understanding what Linux does when it boots and encounters hardware. This knowledge transforms you from someone who runs commands and reads output into someone who understands what the output means.

The Device Enumeration Pipeline

When the kernel boots, it enumerates hardware by scanning several buses and interfaces. PCI enumeration works by reading Vendor IDs and Device IDs from the configuration space of each device on the PCI bus. These are 16-bit values assigned by the PCI regulatory consortium. Every legitimate PCI device carries a factory-programmed vendor ID — 8086 for Intel, 10de for NVIDIA, 1002 for AMD — and a device ID unique to that specific chip revision.

The kernel takes those IDs and matches them against a table inside each kernel module called pci_device_id. When a match is found, the kernel calls that driver's probe function. If no match is found, the device shows up in lspci output but has no driver bound to it. It appears in /sys/bus/pci/devices/ but its driver symlink points nowhere. This is the condition you want to detect before you migrate.

The sysfs virtual filesystem at /sys exposes this entire device tree at runtime. Every entry under /sys/bus/pci/devices/ corresponds to a physical PCI device, and inside each entry you can read the vendor, device, class, and subsys_vendor files directly. This is the same data that user-space tools like lspci read — they parse sysfs and the PCI ID database at /usr/share/hwdata/pci.ids.

USB devices follow a similar model. The kernel's USB subsystem matches devices by their USB Vendor ID and Product ID, and drivers register themselves against those ID pairs. The linux-firmware package provides binary blobs that many USB devices require beyond driver matching — particularly wireless adapters that need signed radio firmware before they will transmit.

The Firmware Problem

This is the single most misunderstood aspect of Linux hardware compatibility. Many people conflate "driver" and "firmware" as if they are the same thing. They are not.

A driver is kernel code that knows how to talk to a device. Firmware is binary code that runs on the device itself — a microcontroller or DSP embedded in your wireless card, GPU, NVMe controller, or Bluetooth adapter. The kernel driver loads the firmware into the device at initialization time. If the firmware file is missing, the device may partially initialize, initialize in a degraded mode, or fail entirely.

In a documented case involving a Raptor Lake CNVi Wi-Fi adapter (an Intel Wi-Fi 6E AX211), the device appeared in lspci output with the iwlwifi kernel module listed but no "Kernel driver in use" line — the driver was present but could not initialize because the firmware file version it required was absent from the installed linux-firmware package. The dmesg output showed a cascade of failed firmware load attempts as the driver tried progressively older firmware versions before giving up. The fix was manually downloading the correct firmware file from kernel.org and copying it to /lib/firmware.

Firmware absence can also create capability gaps rather than boot failures. Graphics cards from second-generation Maxwell onward cannot perform reclocking with the Nouveau open-source driver because the linux-firmware collection is missing the signed firmware blobs needed for the feature. The device works, but you lose performance management.

The Foundational Commands: Reading the Hardware Roster

lspci: The Primary Enumeration Tool

lspci is your starting point for everything connected to PCI buses, which includes your GPU, network controller, audio controller, NVMe drives, Wi-Fi card, and USB controllers. Run it as root for complete output:

$ sudo lspci -nn -k?
sudo lspci -nn -k
-nnShow both human-readable names AND raw numeric PCI vendor/device IDs in brackets — e.g. [8086:7a23]. The ID pair is what you search in external databases.
-kShow which kernel module is currently driving each device, plus which modules are available but not in use. A device with no "Kernel driver in use" line is unmanaged.

The -nn flag shows both the human-readable device name and the raw numeric PCI IDs in brackets. The -k flag shows which kernel driver is currently in use and which kernel modules are available for the device. This combination is the most information-dense single command in hardware compatibility investigation.

Sample output for a network controller:

02:00.0 Network controller [0280]: Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-E) [168c:002e] (rev 01)
        Subsystem: Lite-On Communications Inc AR9287 Wireless Network Adapter [11ad:6632]
        Kernel driver in use: ath9k
        Kernel modules: ath9k

What you want to see is a populated "Kernel driver in use" line for every piece of hardware that matters. If a device shows up in lspci but has no driver bound, that device is unmanaged. The PCI IDs in brackets give you a precise search target for researching driver availability.

# Filter for network and display devices
$ sudo lspci -nn -k | grep -A 3 -i "network\|wireless\|vga\|3d"

dmidecode: Reading the Firmware's Story About Itself

dmidecode reads the SMBIOS (System Management BIOS) tables — structured data that hardware manufacturers embed in firmware to describe the physical system. This data is entirely independent of the operating system.

# BIOS information
$ sudo dmidecode -t 0

# System information (manufacturer, model)
$ sudo dmidecode -t 1

# Memory device (each RAM module)
$ sudo dmidecode -t 17

# Quick memory slot inventory
$ sudo dmidecode -t 17 | grep -E "Size|Speed|Manufacturer|Part Number|Form Factor|Type:"

lshw: The Hierarchical Hardware Map

lshw (List Hardware) produces a complete hierarchical report by querying the kernel, DMI tables, and sysfs simultaneously. It covers storage, memory, firmware, and bus topology in a single unified view.

# Concise table view
$ sudo lshw -short

# Filter by device class
$ sudo lshw -class network
$ sudo lshw -class display
$ sudo lshw -class storage

# Export a full snapshot before migrating
$ sudo lshw -json > pre-migration-hardware-report.json

inxi: Quick Reporting

inxi is a Bash script that aggregates data from multiple sources and formats it for readability. Available in most distribution repositories.

# Full output with extended info, filtered sensitive data, repo info
$ inxi -Fxzr

# Graphics-specific check: driver, version, display resolution
$ inxi -Gxx

The Virtual Filesystems: Going Deeper Than Any Tool

Every tool described above is ultimately a user-friendly interface over raw kernel data structures exposed through virtual filesystems. Reading those structures directly gives you access to information that no packaged tool may surface.

/proc/cpuinfo

The flags field in /proc/cpuinfo lists CPU feature bits per core. The presence of vmx (Intel) or svm (AMD) indicates hardware virtualization support, required for KVM. If you plan to run virtual machines on Linux, confirming these flags before switching is essential.

# Confirm virtualization support
$ grep -E "vmx|svm" /proc/cpuinfo | head -1

/sys/class/drm and /sys/bus/pci/drivers

# Check DRM device enumeration (GPU claimed by driver?)
$ ls /sys/class/drm/
$ cat /sys/class/drm/card0/device/vendor

# Check whether iwlwifi has claimed your wireless device
$ ls /sys/bus/pci/drivers/iwlwifi/

# Check loaded modules for common drivers
$ lsmod | grep -i "nouveau\|nvidia\|amdgpu\|i915\|iwl\|ath"

If /sys/class/drm shows a card0 entry, the DRM driver has successfully claimed that GPU. If the directory only shows render nodes without display nodes, the GPU is unclaimed or running in a degraded mode.

GPU Compatibility: The Most Consequential Decision

Graphics hardware compatibility deserves extended treatment because it has more downstream effects than any other component. Your GPU choice affects display protocol support, gaming performance, virtualization capabilities, and driver stability exposure.

Intel

Intel integrated graphics have the most reliable Linux support of any GPU vendor. The i915 driver is fully open-source, maintained upstream in the Linux kernel, and supports all Intel integrated graphics from Sandy Bridge (2011) through the current generation. Wayland works without configuration. Hardware video decoding works through VA-API. For a migration-oriented user who wants zero surprises, a machine with only Intel integrated graphics is the lowest-risk starting point.

AMD

AMD's Linux story is one of the significant open-source transitions in GPU history. The AMDGPU kernel driver has been mainline since kernel 4.2 (2015) and supports all Graphics Core Next architecture GPUs and newer. The userspace driver is Mesa, which implements OpenGL, Vulkan, and other APIs entirely in open-source code.

In September 2025, AMD formally announced the end of its AMDVLK open-source Vulkan driver, throwing full support behind the Mesa RADV driver. In the official announcement on the AMDVLK GitHub repository, AMD stated that it was unifying its Linux Vulkan driver strategy by discontinuing AMDVLK and designating the community-driven RADV driver as the officially supported open-source Vulkan option for Radeon graphics. This consolidation had been building since May 2025, when AMD announced it would officially support Mesa RADV as part of its packaged Radeon Software for Linux and would drop its proprietary OpenGL and Vulkan components from that package.

What this means practically: AMD GPUs on Linux require no proprietary installer, no DKMS modules that break on kernel updates, and no separate configuration for Wayland. The driver ships with the kernel and Mesa ships with every major distribution. Firmware blobs from the linux-firmware package are still required for full functionality, but these are available in mainstream repositories.

NVIDIA

NVIDIA's Linux situation shifted materially in 2024–2025, and any advice predating those changes may be misleading.

Open kernel modules are now the default and the only option for Blackwell. For Blackwell and Grace Hopper, open-source GPU kernel modules are required and proprietary drivers are unsupported. For Turing, Ampere, Ada Lovelace, and Hopper architectures, NVIDIA recommends switching to the open-source GPU kernel modules. For Maxwell, Pascal, and Volta, the open kernel modules are not compatible — the proprietary driver remains the only option.

An important nuance: these "open kernel modules" refer specifically to the kernel-space portion of the driver stack. The userspace components — OpenGL, Vulkan, CUDA — remain closed-source. The driver remains out-of-tree and DKMS is still required.

Maxwell, Pascal, and Volta were dropped from the 590 driver series. In December 2025, the NVIDIA 590 driver series (590.44.01 Linux) dropped support for GeForce GTX 900 (Maxwell), GTX 1000 (Pascal), and consumer Volta GPUs. Arch Linux documented this in a news post, noting that the 590 driver no longer supports Pascal or older GPUs, and that the main NVIDIA packages now build exclusively on open kernel modules. The 580.xx branch is the last driver version offering full support for Maxwell, Pascal, and consumer Volta. NVIDIA has indicated security-only maintenance for those legacy branches through October 2028, after which support ends completely.

One important clarification on Turing: the GTX 1650 and GTX 1660 series (built on the TU117 and TU116 silicon) are Turing architecture and are therefore supported by the 590+ current driver series with open kernel modules. Only the RTX-branded nomenclature creates confusion — the architecture boundary for 590+ support is Turing, not the RTX product line.

Legacy driver situation as of early 2026:

# Identify your GPU and its PCI device ID
$ sudo lspci -nn | grep -i "vga\|3d\|display"

Take the four-digit hex device ID, look it up at pci-ids.ucw.cz, and cross-reference with NVIDIA's supported GPU list for the driver series your target distribution packages.

Wireless Networking: The Most Common Compatibility Problem

Wireless hardware compatibility is where migrations encounter problems at the highest rate. The reason is structural: wireless chips are complex devices that require legally sensitive radio firmware, and many vendors historically refused to open-source their drivers.

The situation has improved substantially over the past decade:

• The ath9k and ath10k drivers cover a large portion of Qualcomm Atheros wireless hardware in open-source form, with firmware loaded from linux-firmware.
• Intel's iwlwifi driver covers all current Intel Wireless products with good upstream kernel support. Even when the iwlwifi driver is present, the matching firmware file version must also be installed. Mismatches between kernel driver version and firmware version are a common and confusing failure mode.
• MediaTek's mt7921u driver covers the MT7921AU chipset (used in many USB Wi-Fi 6 adapters) and has been mainline since kernel 5.18, with LTS support from kernel 6.1 onward.
• Realtek: Several chipsets gained mainline in-kernel drivers in kernels 6.13 and 6.14. The rtl8811au and rtl8812au chipsets, which previously required the out-of-tree rtl88xxau driver, gained in-kernel support through the rtw88 driver series, with kernel 6.14 as the recommended baseline.

# Check PCI wireless hardware
$ sudo lspci -nn | grep -i "network\|wireless"

# Check USB wireless hardware
$ sudo lsusb | grep -i "wireless\|wifi\|802.11"

Take the [xxxx:xxxx] ID pair from lspci or lsusb output and search linux-hardware.org. This community-maintained database logs real-world probe results from machines running Linux, showing which driver handles the device, which distributions have tested it, and the kernel versions where support was added or improved.

Storage Controllers: A Quiet Risk

NVMe drives are well supported through the nvme driver. SATA drives have excellent support through the ahci driver. The risk area is proprietary RAID controllers and manufacturer-specific storage management.

Intel's RST (Rapid Storage Technology) RAID mode presents a common pre-migration trap. Some systems ship with SATA controllers set to RAID mode in BIOS, which Intel RST manages under Windows. Under Linux, this configuration causes NVMe drives to be invisible because the kernel expects AHCI mode. The fix is changing the SATA controller mode in BIOS from RAID to AHCI before installing Linux — but this change makes Windows unable to boot from the existing installation.

# Look for RST / RAID references in firmware data
$ sudo dmidecode -t 0 | grep -i "raid\|rst\|optane"

# Check SATA and NVMe controller driver binding
$ sudo lspci -k | grep -i "sata\|nvme\|raid"

The Live USB Method: Ground Truth Testing

All of the static analysis above is preparation. The ground truth test is booting your actual hardware from a live USB of your target distribution and running the checks there.

# After booting from a live USB:

# Check driver binding for all PCI devices
$ sudo lspci -k | grep -v "^$" | grep -E "driver|Kernel"

# List USB devices
$ sudo lsusb

# Surface firmware failures and driver errors from boot
$ sudo dmesg | grep -E "firmware|Error|fail|unsupported" | head -40?
dmesg | grep -E "..." | head -40
dmesgPrints the kernel ring buffer — a log of everything the kernel reported during boot and since. It captures driver probe attempts, firmware loads, and hardware errors.
-EEnables extended regex so you can match multiple patterns at once with the pipe character. Without -E, the pipe is treated as a literal character.
head -40Show only the first 40 matching lines. Prevents the output from becoming overwhelming on systems with many devices. Remove this to see all matches.

Key dmesg patterns to watch for:

• firmware: failed to load rtlXXXX_X.bin — the wireless adapter's firmware blob is missing from the live environment.
• iwlwifi: probe of ... failed with error -2 — the iwlwifi driver found Intel wireless hardware but cannot initialize it, usually due to missing or mismatched firmware.
• amdgpu 0000:XX:00.0: amdgpu: fail to init atom bios — the AMD GPU driver cannot read the card's BIOS data, indicating a firmware problem or driver/hardware version mismatch.
• nouveau: unknown chipset — the Nouveau open-source NVIDIA driver does not support your GPU generation. This is expected for current Ada Lovelace and Blackwell GPUs.

Checking Against External Databases

Beyond your local machine's output, three external resources provide pre-migration intelligence:

linux-hardware.org is a database of hardware probes submitted by the community. Search by device name, PCI ID, or USB ID to find real-world reports from machines running the same hardware. The probe data includes driver status, distribution, and kernel version.

Ubuntu Hardware Certification lists systems that Canonical has formally certified for Ubuntu. These certifications are at the system level — specific laptop or server models — confirming system-level integration including power management and suspend/resume.

The PCI ID Repository is the authoritative lookup for PCI vendor and device IDs. Run update-pciids on most distributions to download the latest version, ensuring new device IDs are resolved correctly by lspci.

How to Run a Full Pre-Migration Compatibility Check

Step 1: Export your hardware inventory from your current OS

On Windows, use Device Manager export or msinfo32. On an existing Linux system, run sudo lshw -json to capture a full hardware snapshot before you begin. This gives you a reference point to compare against after migration.

Step 2: Boot a live USB of your target Linux distribution

Write an ISO of the distribution you plan to install to a USB drive using a tool like dd, Balena Etcher, or Ventoy. Boot from the USB without installing anything. This environment runs the exact kernel and driver set your installed system will use, so results are directly applicable.

Step 3: Run lspci, lsusb, and dmesg to audit driver and firmware status

Run sudo lspci -nn -k to verify that every critical device — GPU, wireless, audio, storage controller — has a kernel driver bound. Then run sudo dmesg filtered for firmware and error keywords to surface any missing firmware blobs or driver initialization failures. Record the PCI or USB ID of any unbound device for external research.

Step 4: Cross-reference unrecognized device IDs against linux-hardware.org

Take any [xxxx:xxxx] ID pair from lspci or lsusb output that shows no driver and search it at linux-hardware.org. The database will show real-world probe results from machines running the same hardware, including which driver handles it and what kernel version first added support.

Step 5: Run the live environment for at least 30 minutes and test suspend/resume

Exercise Wi-Fi, display output, audio, and suspend/resume before drawing conclusions. ACPI bugs in laptop firmware frequently cause sleep/wake failures that only appear after the system has been running for a while. Fingerprint readers, Thunderbolt, and USB-C alternate modes may also require extended testing to confirm full functionality.

Secure Boot: The Gate You Have to Negotiate

Secure Boot is a UEFI firmware feature that verifies a cryptographic signature on every piece of code the firmware loads before handing off to the operating system. It was designed to prevent bootkit malware from loading before the OS. It also creates a meaningful compatibility checkpoint that many Linux migration guides never mention.

Linux distributions handle Secure Boot in two ways. Ubuntu, Fedora, and SUSE use Microsoft-signed shim loaders that chain to a distribution-signed GRUB and kernel — Secure Boot stays enabled and everything works transparently. Arch, Gentoo, and other distributions aimed at more manual configuration do not ship signed shims and require either disabling Secure Boot or manually enrolling your own keys. If you plan to use one of the latter and your firmware enforces Secure Boot, you will need to disable it in firmware settings before the installer will boot at all.

The sharper problem is NVIDIA. The proprietary out-of-tree NVIDIA driver uses DKMS to build kernel modules. Those modules must be signed with a key that Secure Boot trusts before the kernel will load them. Distributions package the necessary machinery to enroll a Machine Owner Key (MOK) automatically during driver installation, but it requires a reboot into the MOK enrollment utility — a step that trips up many people who do not expect it. If you skip or dismiss that step, the NVIDIA driver silently fails to load and the system falls back to the framebuffer or Nouveau.

# Check current Secure Boot state from a running Linux system
$ mokutil --sb-state

# List enrolled Secure Boot keys
$ mokutil --list-enrolled

# Check whether a loaded kernel module is signed
$ modinfo nvidia | grep -i "sig\|vermagic"

From a live USB, running mokutil --sb-state tells you immediately whether Secure Boot is active. If it is, and you plan to use NVIDIA's proprietary driver or any other out-of-tree kernel module, plan for the MOK enrollment step before assuming the driver will work out of the box.

Bluetooth: The Often-Forgotten Sibling

Bluetooth and Wi-Fi hardware are frequently packaged together on the same physical chip — a so-called combo card. On a laptop, the device showing up under your PCI or USB wireless controller is often handling both radio protocols simultaneously. This architectural detail has an important consequence: a wireless card that works for Wi-Fi may still have a non-functional Bluetooth subsystem if the firmware blob for the Bluetooth co-processor is missing or the kernel's Bluetooth stack has an issue with that specific chip revision.

Linux Bluetooth runs through the BlueZ stack, which interfaces with hardware via HCI (Host Controller Interface). The kernel presents Bluetooth controllers to BlueZ as HCI devices. You can inspect the Bluetooth subsystem directly:

# List detected Bluetooth controllers
$ hciconfig -a

# BlueZ control utility — shows whether the controller is available
$ bluetoothctl show

# Check dmesg for Bluetooth firmware load failures
$ sudo dmesg | grep -i "bluetooth\|hci\|btusb"

# List USB Bluetooth adapters (many combo cards enumerate as USB internally)
$ lsusb | grep -i bluetooth

Intel CNVi Wi-Fi/Bluetooth combo cards are a reliable example of this pattern. The iwlwifi driver handles the Wi-Fi side while a separate btintel driver handles Bluetooth, and both require firmware from the linux-firmware package — but they are separate firmware files. A system can have working Wi-Fi with non-functional Bluetooth if only one firmware file is missing. Confirm both subsystems independently when testing from a live USB.

Audio: More Layers Than It Should Have

Audio is the compatibility category that rarely stops working entirely but frequently works with caveats. Understanding those caveats before you migrate is worth the few minutes it takes.

The Linux audio stack has three relevant layers. At the bottom, ALSA (Advanced Linux Sound Architecture) is the kernel-level driver interface. Most modern systems use the snd_hda_intel driver, which implements the Intel High Definition Audio specification — a standard used by essentially all integrated audio controllers regardless of their vendor name. Above ALSA sits PipeWire, which became the default audio server across all major distributions between 2022 and 2024, replacing PulseAudio for consumer audio and JACK for low-latency audio. Most applications talk to PipeWire, which handles routing to ALSA.

# Check which audio drivers are loaded
$ lsmod | grep snd

# List all detected sound cards
$ cat /proc/asound/cards

# Inspect ALSA mixer state and available outputs
$ amixer -c 0 contents 2>/dev/null | grep -i "name\|item"

# Check PipeWire status in a live environment
$ pw-cli info all | grep -i "audio\|sink\|source" | head -20

Integrated audio on most machines works without any configuration. The common failure modes are more subtle. HDMI and DisplayPort audio are delivered through the GPU driver rather than the HDA codec — an AMD or Intel GPU that has full display output should also carry audio over those connections, but NVIDIA GPU audio output requires the proprietary driver to be functional. Headset jacks on laptops sometimes need quirk entries in /etc/modprobe.d to configure the HDA codec correctly for that specific laptop model. USB audio interfaces use the USB Audio Class driver, which is fully mainline and generally works without any configuration.

If you use a dedicated external audio interface — a USB or Thunderbolt DAC, audio interface, or studio hardware — search the specific USB Vendor ID and Product ID against the ALSA compatibility matrix at alsa-project.org before assuming it will work. Some class-compliant interfaces work immediately; others require DKMS drivers or have reduced channel counts compared to their Windows counterparts.

Laptop-Specific Hardware: The Compatibility Long Tail

Desktop hardware compatibility maps fairly cleanly onto the categories above. Laptops introduce a long tail of integrated peripherals that each carry their own compatibility story — and since none of them are critical for booting, they often go unexamined until after installation.

Touchpads

The libinput library handles input device management for touchpads, touchscreens, and pointing sticks across both X11 and Wayland. For most modern laptops using I2C-connected precision touchpads (the standard since roughly 2016), this works well. The failure cases tend to involve very new laptop models where the touchpad firmware uses a protocol revision that libinput does not yet support, or older Synaptics touchpads where the older xf86-input-synaptics driver has been deprecated in favor of libinput, sometimes with reduced gesture configurability as a result.

# List input devices recognized by libinput
$ libinput list-devices

# Check for I2C input devices in kernel (precision touchpad detection)
$ sudo dmesg | grep -i "i2c\|hid\|touchpad\|synaptics\|elantech"

# List all input event nodes
$ cat /proc/bus/input/devices | grep -E "Name|Phys|Handlers"

Webcams

USB webcams using the UVC (USB Video Class) standard work without any additional drivers — the uvcvideo kernel driver handles them and has been mainline for over a decade. The compatibility gap appears on laptops where the webcam is connected via a proprietary internal interface rather than USB, or where advanced features like Windows Hello IR cameras require manufacturer-specific software that has no Linux equivalent. The IR camera hardware itself may enumerate, but the facial recognition stack built on top of it does not exist in the same form on Linux.

Fingerprint Readers

Fingerprint reader support on Linux has improved substantially through the fprintd daemon and libfprint library, but remains patchy compared to Windows. The libfprint supported devices list is the definitive reference. Check your laptop's fingerprint reader USB ID against that list before expecting enrollment to work. On unsupported devices, the hardware will enumerate but fprintd will not claim it.

# List USB devices — fingerprint readers typically appear here
$ lsusb | grep -i "finger\|biometric\|validity\|elan\|synaptics"

# Check fprintd for supported device recognition
$ fprintd-enroll --finger left-index-finger 2>&1 | head -5

ACPI, Power Management, and Suspend

ACPI (Advanced Configuration and Power Interface) is the firmware interface through which the OS controls power states, thermal management, fan curves, battery reporting, and sleep/wake transitions. Laptop ACPI tables are written by the manufacturer and are often written with Windows assumptions baked in. The Linux kernel works around known ACPI quirks for major OEM hardware, but new laptop models may ship with ACPI tables that expose undocumented paths or use ambiguous behavior that Linux interprets differently than Windows does.

Suspend failures — where a laptop enters S3 or S0ix sleep but does not wake cleanly — are among the hardest pre-migration issues to catch because they are not always reproducible on a live USB. Running the live environment for an extended session and deliberately triggering suspend/resume at least twice is the minimum test. A persistent installation is a better environment for ACPI testing because firmware and kernel parameters can be adjusted between tests.

# Check available sleep states
$ cat /sys/power/state

# Check which sleep state the system currently targets
$ cat /sys/power/mem_sleep

# Examine ACPI errors from boot
$ sudo dmesg | grep -i "acpi\|suspend\|wake\|resume" | head -30

When the Live USB Finds a Problem

Everything above is investigative. What happens when the investigation turns up something broken? A missing firmware blob, an unbound driver, a device that appears but does not function — these have resolution paths, and knowing those paths before you migrate changes the risk calculus considerably.

Missing Firmware Blobs

If dmesg shows a firmware: failed to load line naming a specific file, the path forward is direct. The file it is looking for lives in the linux-firmware repository at git.kernel.org. Many distributions package a linux-firmware or firmware-linux-nonfree package — verifying that the installed package version contains the required file often resolves the issue. If the distribution's packaged version is too old, downloading the file directly from the repository and placing it in /lib/firmware is the manual solution.

A more targeted approach when the packaged firmware is stale: use git clone --depth=1 to pull only the latest HEAD of the linux-firmware repository rather than downloading the full history, then copy the specific file. This avoids downloading several gigabytes of older blobs just to get one recent file. On Arch-based systems, the linux-firmware-git AUR package tracks the upstream repository HEAD and is worth installing when the stable package consistently lags behind hardware requirements.

A second resolution path that many guides skip entirely is fwupd and the Linux Vendor Firmware Service (LVFS). A growing number of hardware vendors — including Intel, AMD, Lenovo, Dell, and HP — distribute firmware updates directly through LVFS. If your device is supported, running fwupdmgr get-updates after installation can bring Intel wireless firmware, NVMe firmware, and platform EC firmware current without any manual file copying. Check your hardware against the LVFS device list before concluding that manual file placement is the only option.

If the firmware file does not exist in the public linux-firmware repository at all, the situation is more constrained. Check whether the hardware vendor has a dedicated Linux support page — some ship firmware separately from linux-firmware for licensing reasons. If the card is an internal laptop wireless adapter and no firmware path exists, a USB-to-Ethernet adapter or a supported USB Wi-Fi dongle provides network connectivity while you wait for the firmware to be released. Intel AX series adapters enumerate cleanly via USB on most systems and serve as a reliable stopgap.

# Find the exact firmware filename the kernel is requesting
$ sudo dmesg | grep "firmware: failed to load"

# Check if the file is present in the installed package
$ find /lib/firmware -name "iwlwifi-*.ucode" | sort

# Trigger a firmware reload without rebooting (useful for testing)
$ sudo modprobe -r iwlwifi && sudo modprobe iwlwifi

Out-of-Tree Drivers and DKMS

When no in-kernel driver exists for a device, the options are: an out-of-tree driver packaged by the distribution, a community-maintained DKMS module, or no support at all. DKMS (Dynamic Kernel Module Support) is a framework that rebuilds kernel modules automatically when the kernel updates. It solves the problem of out-of-tree modules becoming incompatible after kernel upgrades — but it adds a dependency chain that occasionally breaks when an upstream kernel API change outpaces the DKMS module's maintenance.

Before committing to any hardware that requires an out-of-tree DKMS driver, check the upstream repository for the module and note the last commit date, the issue tracker for kernel compatibility reports, and whether the distribution you plan to use packages the module officially or requires manual installation.

The distinction between a distribution-packaged DKMS module and a manually installed one matters considerably. A distribution-packaged module (such as nvidia-dkms in Ubuntu's repositories or rtw89-dkms in Debian's non-free-firmware section) is tested against the kernels that distribution ships. It receives updates through the normal package manager. A manually cloned GitHub repository is entirely on you to update before each kernel upgrade. If a kernel API breaks the module, the distribution-packaged version will likely have a fix pushed to the repository within days. The manually installed version may break silently — with the driver failing to compile and the device going unclaimed — until you track down the problem yourself.

A related path worth checking: the Linux kernel's staging tree (drivers/staging/) contains drivers that are actively being developed toward mainline inclusion. If your device has a staging driver in a recent kernel series, choosing a distribution that ships that kernel version means the driver is already in-tree, with no DKMS dependency at all. Check the staging tree against your device's chip identifier before concluding that only a DKMS module is available.

Kernel Boot Parameters

Some compatibility problems are resolvable through kernel parameters passed at boot — they address known bugs in driver or firmware interactions without requiring a driver update. Common examples relevant to new hardware include iommu=soft for IOMMU mapping errors on AMD platforms, acpi_osi=Linux for laptops with ACPI tables that behave differently based on what OS string the firmware detects, and pcie_aspm=off for ASPM-related suspend/wake failures.

Two additional parameters that appear frequently in hardware compatibility discussions but rarely get explained together: intel_iommu=igfx_off isolates the integrated Intel GPU from IOMMU remapping, which resolves a class of initialization failures on systems where the IOMMU interferes with the iGPU's DMA access at boot. And nowatchdog disables the hardware watchdog timer — relevant when dmesg shows spurious NMI events from a watchdog driver competing with legitimate hardware interrupt handling on certain laptop platforms.

For laptops with non-functional or intermittent keyboard backlights, trackpoint buttons, or battery reporting, ec_sys.write_support=1 enables direct read/write access to the embedded controller register space, which some community tools like thinkpad-acpi require for full feature access on certain Lenovo and HP platforms. This is not a general-purpose parameter — apply it only when a specific tool's documentation identifies it as required.

The workflow for testing parameters without permanently modifying GRUB is worth internalizing: at the GRUB menu, press e to edit the entry, navigate to the linux line, append your parameter after quiet splash, and press Ctrl+X to boot. The change is not written to disk. If the parameter resolves the problem, then edit /etc/default/grub to make it permanent and run sudo update-grub. Testing first avoids situations where a permanently applied parameter makes the system unbootable.

# View current kernel command line (shows any params already in use)
$ cat /proc/cmdline

# Test a parameter without permanently editing GRUB:
# At the GRUB menu, press 'e', find the linux line, append your parameter,
# then press Ctrl+X to boot. Changes are not saved across reboots.

modprobe.d and udev Rules as Workarounds

Between "the driver exists and works" and "no driver exists at all" sits a middle tier that many guides ignore: situations where a driver loads but behaves incorrectly, applies wrong parameters, or conflicts with another driver. Two tools address this without requiring a kernel rebuild or a new package.

The /etc/modprobe.d/ directory holds configuration files that control how kernel modules are loaded. A file like /etc/modprobe.d/audio-fix.conf containing options snd_hda_intel power_save=0 disables HDA audio power saving, which causes audio dropouts on many laptops under PipeWire. The options directive passes parameters to a module at load time — exposing the same tuning knobs that the driver developer built in but that distributions do not always set correctly for every hardware combination. Run modinfo [module-name] to see the full list of supported parameters for any loaded driver.

The blacklist directive in modprobe.d prevents a module from loading entirely. This resolves conflicts where a generic driver claims a device before a more capable one can bind to it — a common pattern with Bluetooth drivers, where a generic HCI USB driver and a vendor-specific driver compete for the same device. Blacklisting the conflicting module forces the correct one to take ownership.

udev rules at /etc/udev/rules.d/ run arbitrary commands when the kernel enumerates a device. For hardware where a vendor supplies a firmware loader or initialization script that must run at device insertion — certain Wacom tablets, some USB audio interfaces, and a handful of wireless adapters — a udev rule is the correct mechanism. The rule matches on USB vendor and product ID, then runs the specified command. This is a permanent, boot-resilient solution that does not require any driver modification.

Filing a Bug and Upstream Paths

When a device has no working driver and no firmware path, the most durable long-term solution is to ensure the problem is visible to the people who can fix it. The Linux kernel bug tracker at bugzilla.kernel.org accepts hardware compatibility reports. A report that includes your hw-probe URL, the full dmesg output, and the specific PCI or USB ID of the failing device gives driver maintainers everything they need to reproduce the problem without having the hardware in hand.

For wireless hardware specifically, reaching out to the hardware vendor directly is more effective than it used to be. Intel, MediaTek, and Realtek all maintain active Linux driver teams. MediaTek's rtw89 driver — now mainlined — originated from direct vendor engagement with the kernel community. If your device uses a chip from one of these vendors and lacks mainline support, checking the vendor's GitHub organization for an in-progress driver tree is worth the five minutes it takes.

Distribution Selection as a Hardware Variable

The guide has treated distribution selection as already settled, but if the live USB reveals compatibility problems, distribution choice is a hardware variable worth revisiting. If you have not yet committed to a specific distribution, the definitive Linux distribution decision framework on this site covers that selection process in depth. Distributions that track newer kernels — Fedora ships close to the current kernel release, Ubuntu LTS ships a newer hardware-enablement kernel as an option — will have better out-of-the-box support for hardware released in the last 12 to 18 months. A wireless card that gains mainline support in kernel 6.13 will work on Fedora 42 without any intervention but may require a manual kernel upgrade or backported package on an Ubuntu LTS still shipping kernel 6.8.

If your hardware probe reveals a device with a driver added in a recent kernel series, cross-reference that kernel version against your target distribution's current and upcoming kernel packages before making a final distribution choice.

Ubuntu LTS deserves specific mention here because its Hardware Enablement (HWE) stack is frequently underused. When an LTS release ships with kernel 6.8, Ubuntu publishes an HWE kernel stack — currently tracking kernel 6.11 on 24.04 LTS — installable with a single command: sudo apt install linux-generic-hwe-24.04. This is not a third-party kernel. It is Canonical-supported, receives security updates, and does not require any repository changes. For hardware released after the LTS launch date, the HWE kernel is often the path of least resistance compared to switching distributions entirely.

Rolling release distributions — openSUSE Tumbleweed, Arch Linux, Void Linux, Manjaro — ship kernel updates within days of upstream releases. If your hardware requires kernel 6.14 and you want an out-of-the-box system rather than a manual kernel build, a rolling release distribution effectively eliminates kernel version as a hardware variable. The tradeoff is a faster-moving system that requires more attention to update hygiene. For hardware compatibility specifically, rolling releases are the most reliable path to current driver support without any manual intervention.

Finally, if you need to stay on a specific distribution but want a newer kernel without switching to a full rolling release, tools like mainline (formerly ukuu) provide a GUI for installing upstream kernel builds on Ubuntu and Ubuntu-based distributions. These are not distribution-supported kernels — they bypass the package manager's dependency tracking for kernel modules — but they are a legitimate tool for hardware compatibility testing before committing to a distribution change.

Frequently Asked Questions

How do I check if my hardware is compatible with Linux before installing?

Boot a live USB of your target Linux distribution and run sudo lspci -nn -k to see whether each device has a kernel driver bound to it. Also run sudo dmesg filtered for firmware and error keywords to catch missing firmware blobs. Cross-reference any unbound device IDs against linux-hardware.org for real-world compatibility reports.

Why does Linux see my wireless card but it still does not connect?

The cause is a missing firmware blob. Many wireless adapters require a binary firmware file that loads separately from the kernel driver. Check dmesg for lines containing "firmware: failed to load" — they will name the specific file required. Install the linux-firmware package for your distribution, or manually download the firmware from kernel.org and place it in /lib/firmware.

Which NVIDIA GPUs still receive driver support on Linux in 2026?

Turing (GTX 1650/1660 series and RTX 20xx and up) and newer GPUs use the 590+ driver series with open kernel modules. Maxwell, Pascal, and consumer Volta (GTX 900/1000 series, Titan V) require the legacy 580.xx branch — NVIDIA dropped those architectures from the 590 driver in December 2025. Kepler (GTX 600/700 series) requires the 470.xx legacy branch. Blackwell (RTX 5000 series) requires open kernel modules only and CUDA 12.8 or later for compute workloads. Security-only updates for the 580.xx legacy branch continue through October 2028.