Identify and observe Linux devices

You need to know what a Linux machine has inside: which disk hides behind /dev/nvme0n1, which driver handles the network card, why the USB key you plugged in stays invisible. This reference page gathers the hardware identification commands: lsblk for disks, lspci and lsusb for buses, lshw for the full inventory, lsmod and modinfo for kernel modules, dmesg to follow detection live. You will also see how udev creates the files in /dev and how to write a custom rule to name a device in a stable way.

What you will learn

• Link a physical device to its special file in /dev;
• Identify PCI and USB components and disks with lspci, lsusb and lsblk;
• Write, reload and test a custom udev rule;
• Load, unload and inspect a kernel module;
• Diagnose an undetected device with dmesg.

How Linux sees your devices

On Linux, hardware management rests on a well-defined architecture, which handles communication between the physical components and the operating system. This interaction is essential to guarantee that every device, hard disk, network card or USB key, works properly and can be used by applications.

Hardware abstraction

Linux uses drivers to link the hardware and the kernel. Each driver is designed for a precise type of device: graphics card, USB controller, network card, etc. The driver lets the kernel interact with the hardware without having to handle each component's technical particularities directly.

For instance, when you plug in a USB key, the kernel does not know by default how to read this hardware. The USB storage driver translates the exchanges on the bus into read and write operations Linux understands.

The management chain

The process of recognising and managing hardware always follows the same chain, whether it is an internal disk or a device plugged in hot:

• Hardware: a device signals its presence when it is plugged in or detected at boot.
• Driver: the driver translates the exchanges with the hardware into instructions the system can use.
• Kernel: the Linux kernel processes these instructions and emits an event.
• udev: the device manager receives the event and creates the matching special file in /dev.

Each command on this page observes one link of this chain: dmesg looks at the kernel, udevadm queries udev, lsblk and ls -l /dev show the final result.

Hardware interrupts (IRQ)

Devices often need to get the attention of the processor to signal that a task is finished or that an event has happened (for instance, a key pressed on a keyboard). Linux handles this with hardware interrupts (IRQ). Each device is given one or several interrupt numbers, sometimes shared between several components on old machines. The /proc/interrupts file lists the IRQs in use and the number of events handled per processor.

Concrete example: plugging in a USB key

Let's take a common scenario to walk through the full chain:

• You plug in a USB key.
• The USB controller signals a new device, the kernel emits an event.
• The kernel identifies the type of device and loads the appropriate module if it is not loaded already (here usb-storage, the USB mass storage driver).
• udev receives the event and exposes the device as a file in /dev, such as /dev/sdb.
• The system can then mount the key and make it reachable through a mount point, for instance /media/usb.

Module management (lsmod, modprobe, modinfo) is detailed further down this page.

udev: the device manager

udev is a key element of hardware management on Linux. It acts as a dynamic device manager, allowing automatic detection and configuration of hardware as soon as it is connected or disconnected. It is udev that creates or removes the files in the /dev directory in real time.

How udev works

When a device is plugged in (for instance, a USB key), the Linux kernel sends a hardware event (uevent). udev catches this event, identifies the device, applies the matching rules, and creates a special file under /dev, possibly along with stable symbolic links (those you see in /dev/disk/by-uuid/ for instance).

Simplified diagram of the process:

• Hardware event -> Kernel -> udev -> Creation of the /dev file

This makes the system immediately ready to use the hardware, with no manual intervention.

udev rules

udev's behaviour is controlled by rules, located in two places with distinct roles:

• /etc/udev/rules.d/: the administrator's rules, which take precedence;
• /usr/lib/udev/rules.d/: the rules shipped by the distribution's packages (also reachable via /lib/udev/rules.d/ on Debian and Ubuntu).

A file in /etc/udev/rules.d/ with the same name as a file in /usr/lib/udev/rules.d/ replaces it entirely. Files are processed in alphabetical order: the numeric prefix (10-, 70-, 99-) therefore sets the order of application.

Each rule defines how udev must handle a device: custom naming, specific permissions, or running scripts. Example of a rule that creates a stable link for a Kingston USB key (file /etc/udev/rules.d/99-cle-inventaire.rules):

ACTION=="add", SUBSYSTEM=="block", ATTRS{idVendor}=="0951", ATTRS{idProduct}=="1666", SYMLINK+="cle-inventaire%n"

This rule creates a symbolic link /dev/cle-inventaire for the disk and /dev/cle-inventaire1 for its first partition (%n reuses the number assigned by the kernel). Two traps to know:

• ATTRS{} (with an S) compares the attribute on the device and its parents: essential here, because idVendor belongs to the parent USB device, not to the disk itself. ATTR{} only tests the current device.
• The idVendor and idProduct identifiers are read in the output of lsusb (column ID 0951:1666).

To discover every attribute usable in a rule, walk up the chain of a device's parents with:

udevadm info --attribute-walk --name=/dev/sdb

udevadm commands

The udevadm tool gathers all of udev's controls: watching events, inspecting a device, reloading rules.

To see live what happens when you connect or disconnect a device:

udevadm monitor

The command starts by announcing what it listens to, then shows a KERNEL line (the raw event from the kernel) and a UDEV line (after applying the rules) for each event:

monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1534.567890] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2 (usb)
UDEV  [1534.569012] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2 (usb)

To get every property of a device already present, use udevadm info. Example on an NVMe partition:

udevadm info --name=/dev/nvme0n1p1

P: /devices/pci0000:00/0000:00:06.0/0000:01:00.0/nvme/nvme0/nvme0n1/nvme0n1p1
N: nvme0n1p1
S: disk/by-uuid/3DF4-92C7
S: disk/by-path/pci-0000:01:00.0-nvme-1-part1
S: disk/by-id/nvme-CT1000P3PSSD8_24361234ABCD-part1
E: DEVNAME=/dev/nvme0n1p1
E: DEVTYPE=partition
E: ID_FS_TYPE=vfat

The S: lines list the symbolic links created by udev, and the E: lines the properties usable in rules or scripts.

After changing a rule, ask udev to reload its configuration:

sudo udevadm control --reload

The reload only applies to future events. To replay the rules on devices already plugged in:

sudo udevadm trigger

Understand device files in /dev

On Linux, each hardware device is represented by a special file located in the /dev directory. This approach follows the "everything is a file" principle: a disk, a serial port or even a mouse can be handled like any other file by the operating system.

The /dev directory holds device files that act as an interface between the kernel and the hardware. When an application wants to interact with a device (for instance, read a file on a disk), it goes through this special file.

Example of inspecting two devices:

ls -l /dev/nvme0n1 /dev/tty0

brw-rw---- 1 root disk 259, 0 juin   5 17:36 /dev/nvme0n1
crw--w---- 1 root tty    4, 0 juin   5 17:36 /dev/tty0

The first character of each line reveals the category of the file. There are two big families:

• Character devices (type c): they transmit data character by character. That is the case for terminals (/dev/tty), serial ports or audio devices.
• Block devices (type b): they handle data in blocks, which is more efficient for disks, USB keys and partitions (/dev/sda, /dev/nvme0n1p1).

The two numbers that replace the usual file size identify the device to the kernel:

• Major number: identifies the driver used (8 for SATA/SCSI sd* disks, 259 for NVMe disks).
• Minor number: identifies the precise instance of the device (disk, then each partition).

To get this information in a detailed form, use stat:

stat /dev/nvme0n1

  File: /dev/nvme0n1
  Size: 0           Blocks: 0          IO Block: 4096   block special file
Device: 0,5  Inode: 334         Links: 1     Device type: 259,0
Access: (0660/brw-rw----)  Uid: (    0/    root)   Gid: (    6/    disk)

The block special file mention confirms the type, and Device type: 259,0 repeats the major/minor pair.

Inventory all the hardware with lshw

The lshw command (Hardware Lister) shows detailed information about all the hardware of your system: processor, memory, network cards, storage. Unlike lspci or lsusb, which focus on a specific bus, lshw gives a global view of the machine. It is not always installed by default:

sudo apt install lshw    # Debian / Ubuntu
sudo dnf install lshw    # RHEL / Fedora

To show all the information available about your hardware:

sudo lshw

Using sudo is needed to reach the details of low-level devices (disks notably): without privileges, the output is incomplete and lshw says so at the end of the run.

If you are after a quick overview without going into detail, the -short option produces a table with one line per component:

sudo lshw -short

H/W path              Device     Class          Description
===========================================================
                                 system         UM250 (Default string)
/0                               bus            UM250
/0/9                             memory         40GiB System Memory
/0/9/0                           memory         32GiB SODIMM DDR4 Synchronous Unbuffered (Unregistered) 2666 MHz
/0/e                             processor      AMD Ryzen Embedded V1605B with Radeon Vega Gfx
/0/100/1.1/0          enp1s0     network        Ethernet Controller I225-V
/0/100/1.3/0          wlo1       network        Wireless 7265
/0/100/8.1/0                     display        Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]

The Class column lets you spot the categories at a glance: memory, processor, network, display, storage. You can in fact filter directly on a class with the -C option:

sudo lshw -C network    # network cards
sudo lshw -C storage    # storage controllers
sudo lshw -C memory     # memory

Filtering by class is the reflex to check that a network card is detected and bound to the right driver:

sudo lshw -C network

*-network
    description: Ethernet interface
    product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
    vendor: Realtek Semiconductor Co., Ltd.
    configuration: driver=r8169

The configuration: driver= line gives the kernel module used, precious information when an interface does not come up.

Finally, lshw can export its inventory to feed reports or external tools, as HTML or JSON (depending on the version installed):

sudo lshw -html > rapport_hardware.html
sudo lshw -json > rapport_hardware.json

Identify PCI devices with lspci

The PCI (Peripheral Component Interconnect) bus connects a wide variety of internal devices: network cards, graphics cards, SATA and NVMe controllers, USB controllers. The lspci command (pciutils package) lists every device present on this bus, which is especially useful to diagnose or document a machine's hardware configuration.

To list every PCI device:

lspci

00:00.0 Host bridge: Intel Corporation Device 4649 (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P GT1 [UHD Graphics] (rev 0c)
00:06.0 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 (rev 02)
00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller (rev 01)
00:17.0 SATA controller: Intel Corporation Alder Lake-P SATA AHCI Controller (rev 01)
00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High Definition Audio Controller (rev 01)

Each line starts with the device's PCI address (bus:device.function), followed by its class and its description. It gives a quick overview of the major components.

To know which driver handles each device, the -k option is the most direct:

lspci -k -s 00:02.0

00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P GT1 [UHD Graphics] (rev 0c)
  Subsystem: Intel Corporation Alder Lake-P GT1 [UHD Graphics]
  Kernel driver in use: i915
  Kernel modules: i915, xe

The Kernel driver in use line shows the module actually loaded, and Kernel modules the candidate modules. It is the first reflex when a device is detected but does not work: no Kernel driver in use line, no driver.

The -v option (verbose) adds the allocated resources (IRQ, memory ranges), and -nn shows the vendor's and model's numeric identifiers:

lspci -nn

00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-P GT1 [UHD Graphics] [8086:46a3] (rev 0c)

Here, 8086 is the vendor ID (Intel) and 46a3 the model ID. These identifiers are very handy to look for a compatible driver or to identify precisely a piece of hardware shown as an unrecognised Device xxxx.

lspci relies on a local database to match PCI identifiers with readable names. To update this database (useful when recent hardware shows up without a name):

sudo update-pciids

To look only for your graphics card, combine with grep:

lspci | grep VGA

00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P GT1 [UHD Graphics] (rev 0c)

This lets you quickly check that the system correctly detects the video card.

Identify USB devices with lsusb

The USB (Universal Serial Bus) is everywhere: USB keys, external disks, keyboards, mice, webcams. All these devices are listed with the lsusb command (usbutils package), essential to diagnose an external device that does not answer or to check that it is detected.

To show the list of connected USB devices:

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 2109:2822 VIA Labs, Inc. USB2.0 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 2109:0822 VIA Labs, Inc. USB3.1 Hub

Each line gives the USB bus, the device number, the vendor:product ID and the name of the recognised device. The "Linux Foundation" root hub entries are the machine's USB controllers themselves, not plugged-in devices.

Each USB device has an identifier of the form ID 2109:2822:

• the first 4 hexadecimal characters (2109) are the vendor ID;
• the next 4 (2822) are the product ID.

These identifiers are used to look up information about the hardware (the public database usb.ids lists them) and to write custom udev rules, as seen above.

To get the full details of a device (interfaces, protocols, power draw), use -v, preferably targeting a precise address with -s, because the full output is very long:

lsusb -s 001:002 -v

To show the USB device tree, useful to see on which physical port each device is plugged and at which speed it negotiates:

lsusb -t

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/2p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/2p, 10000M

The Driver= column shows the driver bound to each interface, and the final value the negotiated speed (480M for USB 2.0, 5000M or 10000M for USB 3.x). A USB 3 disk plugged into a port that negotiates at 480M is a sign of an unsuitable cable or port.

Practical example, to detect whether a USB printer is recognised:

lsusb | grep -i printer

If there is no result, the printer is not detected at the USB bus level: no point looking further up (CUPS, drivers), the problem is hardware or cabling.

View block devices with lsblk

The lsblk command (List Block Devices, util-linux package) shows the full hierarchy of block devices: disks, SSDs, USB keys, partitions, LVM volumes. It is the reference tool to check the structure of the disks before any partitioning or mount operation.

To list every block device detected:

lsblk

NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1                   259:0    0 931,5G  0 disk
├─nvme0n1p1               259:1    0     1G  0 part /boot/efi
├─nvme0n1p2               259:2    0     2G  0 part /boot
└─nvme0n1p3               259:3    0 928,5G  0 part
  └─ubuntu--vg-ubuntu--lv 252:0    0 928,5G  0 lvm  /

This tree view shows the relation between the physical disk (nvme0n1), its partitions (nvme0n1p1 to p3) and the LVM volumes built on top. The RM column is 1 for removable devices (USB keys), and MOUNTPOINTS shows where each volume is mounted.

On a machine where snap is installed, the list is cluttered with dozens of loop devices. Exclude them with -e 7 (7 is the major number of loop devices):

lsblk -e 7

To also see the file systems, their UUIDs and the space available:

lsblk -f

NAME                      FSTYPE      FSVER    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1               vfat        FAT32          3DF4-92C7                                   1G     1% /boot/efi
├─nvme0n1p2               ext4        1.0            9a43eed7-0049-4b6f-b80d-5593cb2744a0      1,6G    10% /boot
└─nvme0n1p3               LVM2_member LVM2 001       9HHBOS-dOrC-yKYx-nK9s-nH8N-5gaM-jIB8Qg
  └─ubuntu--vg-ubuntu--lv ext4        1.0            044f2a54-fb22-4a0e-bc4e-40cd719d479e    138,4G    81% /

The UUID is the identifier to use in /etc/fstab (the file of persistent mounts): unlike /dev/sdb1, it does not change if the kernel renumbers the disks at boot.

You can build your own view with -o and the list of columns you want:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL

The MODEL column shows the commercial reference of the disk, handy to tell two disks of the same size apart. Two other useful options:

• lsblk -a adds empty devices (no medium inserted or of zero size), hidden by default;
• lsblk /dev/nvme0n1 limits the view to a single disk and its children.

Practical example: to check that a freshly plugged USB key is recognised, run lsblk -f and look for the new disk with RM at 1 (usually sdb or sdc). If it appears without a mount point, the key is detected but not mounted: it is a normal state on a server, up to you to mount it.

In addition, the blkid command quickly identifies each device by its UUID and its file system type:

sudo blkid

/dev/nvme0n1p1: UUID="3DF4-92C7" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="cd4e410d-262f-41af-8958-27fffd6a49fa"
/dev/nvme0n1p2: UUID="9a43eed7-0049-4b6f-b80d-5593cb2744a0" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="31a14aba-e3e5-4040-a75d-1fa06baed451"

To go further on reliable identification of disks (/dev/disk/by-id/ paths, WWN, serial numbers), a dedicated page covers the topic: identify your disks reliably.

Other useful commands for the hardware inventory

On top of the classic lspci, lsusb and lsblk, Linux offers several other precious commands to explore the hardware in depth. These tools bring complementary information about the BIOS/UEFI, the motherboard and the processor.

dmidecode

The dmidecode command extracts information from the DMI/SMBIOS table filled in by the machine's firmware: motherboard vendor, BIOS model and version, memory modules installed and free slots. It is the command to use to inventory a machine without opening it.

sudo dmidecode -t system

# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.4.0 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
  Manufacturer: Micro Computer(HK) Tech Limited
  Product Name: NAB6
  Serial Number: Default string

The -t option targets a precise section: system, bios, memory, processor. To know the details of the RAM modules (size, speed, occupied slots):

sudo dmidecode -t memory

Beware: the values come from the firmware, not from a measurement. On some machines (mini-PCs, virtual machines), fields contain generic values such as Default string.

inxi

inxi is a script that sums up in a few lines the hardware, the system and the software environment. Very handy to get a quick summary of a machine you are discovering:

sudo apt install inxi    # Debian / Ubuntu
sudo dnf install inxi    # RHEL / Fedora (EPEL repository)

The recommended combination of options shows everything (-F), with the technical details (-x) and hiding sensitive information such as IP and MAC addresses (-z):

inxi -Fxz

hwinfo

hwinfo is an alternative to lshw, historically tied to openSUSE, which scans all the hardware in a very verbose way. It is used to diagnose undetected devices or to get raw details no other tool shows:

sudo apt install hwinfo
sudo hwinfo --short        # summary
sudo hwinfo --network      # one precise category

lscpu

To show only the processor information (architecture, number of cores and threads, virtualisation), lscpu is provided by util-linux and therefore always available:

lscpu

Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
CPU(s):                   16
  On-line CPU(s) list:    0-15
Vendor ID:                GenuineIntel
  Model name:             12th Gen Intel(R) Core(TM) i7-12650H
    Thread(s) per core:   2
    Core(s) per socket:   10
    Socket(s):            1

The full output also includes the cache sizes, the NUMA topology and the state of mitigations for CPU vulnerabilities (Spectre, Meltdown). The cores/threads ratio (Thread(s) per core: 2) confirms here that hyperthreading is active.

Manage kernel modules with lsmod, modprobe and modinfo

The Linux kernel uses modules to handle many hardware components. These modules are pieces of code loaded or unloaded dynamically, which lets the kernel adapt to the devices present without a reboot.

The lsmod command shows every module currently loaded:

lsmod

Module                  Size  Used by
tcp_diag               12288  0
inet_diag              28672  1 tcp_diag
vxlan                 155648  0
ip6_udp_tunnel         16384  1 vxlan

The columns read as follows:

• Module: name of the module;
• Size: size of the module in memory (bytes);
• Used by: number of users of the module, followed by the names of the modules that depend on it (here tcp_diag depends on inet_diag).

This dependency counter is the key to understand why a module sometimes refuses to unload.

To load a module (for instance usb-storage, the USB mass storage driver):

sudo modprobe usb-storage

modprobe automatically loads the module's dependencies, which makes it the tool to favour. Note that dashes and underscores are interchangeable: modprobe usb-storage and modprobe usb_storage load the same module, but lsmod always shows it with an underscore (usb_storage).

To remove a module from memory:

sudo modprobe -r usb-storage

Beware: a module can only be removed if it is not in use (the Used by counter must be 0). Otherwise, modprobe -r fails with Module usb_storage is in use.

To check that a module is loaded or unloaded:

lsmod | grep usb_storage

The modinfo command shows a module's identity card: description, licence, file on disk, parameters and hardware aliases:

modinfo usb-storage

filename:       /lib/modules/6.8.0-134-generic/kernel/drivers/usb/storage/usb-storage.ko.zst
license:        GPL
description:    USB Mass Storage driver for Linux
author:         Matthew Dharm <mdharm-usb@one-eyed-alien.net>

On a hardware problem, reloading a module lets you reset a driver without rebooting, for instance for a Realtek network card:

sudo modprobe -r r8169
sudo modprobe r8169

Module files are stored in /lib/modules/$(uname -r)/, often compressed (.ko.zst or .ko.xz depending on the distribution). To locate a precise module:

find /lib/modules/$(uname -r) -type f -name 'usb-storage.ko*'

/lib/modules/6.8.0-134-generic/kernel/drivers/usb/storage/usb-storage.ko.zst

Follow hardware detection with dmesg

The dmesg command shows the kernel message buffer (kernel ring buffer): everything the kernel records since boot, including hardware detection and configuration. It is the tool of first resort when a plugged-in device gives no sign of life.

On most recent distributions, reading this buffer is reserved to root (kernel.dmesg_restrict parameter): without sudo, the command fails with read kernel buffer failed: Operation not permitted.

sudo dmesg

Example sequence when a USB device is plugged in:

[    1.155126] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[    1.285464] usb 1-1: New USB device found, idVendor=2109, idProduct=2822, bcdDevice=90.13
[    1.285515] usb 1-1: Product: USB2.0 Hub
[    1.285520] usb 1-1: Manufacturer: VIA Labs, Inc.

You find the idVendor and idProduct identifiers, the same as those shown by lsusb and usable in a udev rule.

To target only the messages about USB devices:

sudo dmesg | grep -i usb

To look only at the latest messages, the most recent being at the bottom, combine with tail right after plugging in hardware:

sudo dmesg | tail

For continuous monitoring of kernel messages (the equivalent of tail -f for logs), the --follow option shows events live; it is the best way to observe what happens at the exact moment you plug in a device:

sudo dmesg --follow

You can also look for errors by filtering on keywords such as error, fail or fault:

sudo dmesg | grep -i error

By default, dmesg timestamps messages in seconds since boot. For a display with real dates, use -T:

sudo dmesg -T

[mar. juil. 14 07:50:18 2026] usb 1-1: new high-speed USB device number 2 using xhci_hcd

Practical example: to diagnose a problematic disk, filter on its device name and look for input/output errors:

sudo dmesg | grep -i nvme0

The absence of an I/O error or link reset in this output is a good sign: the disk is recognised and talks normally with the kernel.

Troubleshooting

Facing a stubborn device, the classic mistake is to test at random. This table covers the most frequent symptoms and the diagnostic order to follow, from the hardware to the configuration.

Symptom	Likely cause	Fix
USB key invisible in lsblk	Faulty cable/port, or storage module missing	Run sudo dmesg --follow then plug in the key: no message = hardware problem; messages present but no /dev/sd* = check lsmod | grep usb_storage and load the module
Card detected by lspci but interface missing	Driver not loaded or nonexistent	lspci -k: if Kernel driver in use is missing, load the module listed in Kernel modules with modprobe, or install the missing firmware reported in dmesg
udev rule has no effect	Rules not reloaded, or wrong attribute (ATTR instead of ATTRS)	sudo udevadm control --reload && sudo udevadm trigger, then check the real attributes with udevadm info --attribute-walk
modprobe -r fails with Module is in use	The module is used by a mounted device or another module	Look at the Used by column of lsmod, unmount the file systems or unload the dependent modules first
dmesg answers Operation not permitted	Reading the kernel buffer is restricted (kernel.dmesg_restrict=1)	Run the command again with sudo

Swipe to see more

Key points

• Every device follows the same chain: hardware, driver, kernel, then udev which creates the special file in /dev.
• Files in /dev are of block type (b, disks) or character type (c, terminals, serial ports), identified by a major/minor pair.
• Custom udev rules go in /etc/udev/rules.d/; after a change, udevadm control --reload then udevadm trigger.
• ATTRS{} also compares the attributes of parent devices, ATTR{} only those of the current device: it is the number one trap of udev rules.
• lspci -k and lshw -C network reveal the driver bound to a device; a card without Kernel driver in use will not work.
• lsblk -f shows the disks/partitions hierarchy with the UUIDs, the stable reference to use in /etc/fstab.
• modprobe loads a module with its dependencies; a module only unloads if its Used by counter is zero.
• sudo dmesg --follow is the best observation point at the moment you plug in a device.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

FAQ: frequently asked questions about Linux devices

The questions that come up most often about identifying devices on Linux, with short and direct answers, from udev to kernel modules.

What is udev on Linux?

What is the lspci command for?

How do you list the connected USB devices?

What does the lsblk command do?

What is the lshw command for?

How do you reload udev rules after a change?

What is a device file in /dev?

What is the difference between a character device and a block device?

How do you check the loaded kernel modules?

What is a hardware interrupt (IRQ)?

How do you monitor hardware events in real time?

What does the dmesg command let you do?

How do you know whether a specific module is loaded?

How do you quickly identify a network card on Linux?

Which command shows the processor details?

×

See in the glossary →