← Back to DevBytes
Linux July 09, 2026 10 min read

Fix 'Device not found' Error in Linux

Understanding the "Device not found" Error in Linux

The "Device not found" error in Linux is a generic yet frequent message that appears when the system cannot locate or access a hardware device, block storage, network interface, or peripheral you're trying to interact with. It can surface in many contexts — when mounting a drive, running fsck, accessing a serial port, or configuring a network adapter. At its core, the error means the kernel's device tree, the /dev filesystem, or the relevant subsystem has no entry matching the identifier you specified.

This error is not tied to a single daemon or utility. You might encounter it as:

Understanding the layered nature of Linux device handling — from hardware detection in the kernel, through udev rules, to the /dev representation — is key to diagnosing and resolving this error systematically.

Why Proper Device Detection Matters

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

Device detection failures disrupt critical workflows. A developer relying on an external SSD for builds, an embedded engineer flashing firmware over USB, or a system administrator bringing up a network interface after a kernel update — all face immediate blockers when a device goes missing. Beyond inconvenience, undiagnosed device absence can mask deeper issues: faulty drivers, failing hardware, kernel module mismatches after upgrades, or race conditions in udev coldplug processing. Addressing the error promptly prevents data loss from misdirected writes and ensures reproducible development environments.

Common Scenarios and Their Root Causes

1. Block Device (Storage) Not Found

The most common variant. You plug in a USB drive or connect an NVMe disk, but /dev/sdb or /dev/nvme0n1 never appears, or appears with a different name than expected.

Root causes:

2. Network Interface Not Found

After a kernel upgrade or migrating a configuration to a new machine, NetworkManager or ip link reports that eth0 or wlan0 does not exist.

Root causes:

3. USB / Serial Device Not Found

A USB-to-serial adapter that worked yesterday now shows /dev/ttyUSB0: No such file or directory.

Root causes:

Systematic Diagnosis Workflow

Rather than guessing, follow a layered approach — from hardware visibility through kernel logs to userspace device nodes.

Step 1: Check Physical Connection and Hardware Visibility

Start at the lowest level: the PCI/USB bus and kernel messages.

# Check kernel ring buffer for recent device events
dmesg | tail -50

# Filter for USB or storage-related messages
dmesg | grep -iE "usb|scsi|nvme|sd[a-z]|tty"

# List PCI devices (for network cards, NVMe drives)
lspci | grep -iE "network|storage|nvme|ethernet"

# List USB devices with verbose details
lsusb
lsusb -t   # tree view showing ports and speeds

If the device does not appear in dmesg at all when physically connected, the issue is at the hardware or kernel driver level — not a userspace naming problem. Look for USB enumeration failures or PCI link training errors in the logs.

Step 2: Verify Kernel Modules

Even if the hardware is visible on the bus, the corresponding driver module must be loaded for a usable device node to appear.

# List loaded modules and filter for relevant ones
lsmod | grep -iE "usb|nvme|sdhci|igb|e1000|wireless"

# Check if a specific module is available at all
modinfo nvme
modinfo usb_storage
modinfo ftdi_sio

# Load a module manually for testing
sudo modprobe nvme
sudo modprobe usb_storage

# Check for module loading errors in dmesg
dmesg | grep -i "modprobe\|failed\|error" | tail -20

Common situations: after a kernel update, initramfs may lack the required module. Rebuild it with:

# On Debian/Ubuntu
sudo update-initramfs -u

# On Arch
sudo mkinitcpio -P

# On Fedora/RHEL with Dracut
sudo dracut --force

Step 3: Inspect the /dev Filesystem and udev

Once the kernel has a driver bound to the device, udev creates the node in /dev. Sometimes the node exists but with an unexpected name.

# List all block devices
lsblk
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL,SERIAL

# List disk devices by ID (stable identifiers)
ls -l /dev/disk/by-id/
ls -l /dev/disk/by-path/
ls -l /dev/disk/by-uuid/

# Check for tty devices
ls -l /dev/ttyUSB* /dev/ttyACM* /dev/ttyS*

# Monitor udev events in real-time
sudo udevadm monitor

# Trigger udev rules manually and observe
sudo udevadm trigger --verbose

# Query udev database for a specific device path
sudo udevadm info --query=all --path=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2

The /dev/disk/by-id and /dev/disk/by-uuid symlinks are persistent across reboots and port changes — use them in scripts and fstab instead of raw /dev/sda names.

Step 4: Isolate the Missing Device with Sysfs

The /sys filesystem exposes the kernel's device model directly. Even if no /dev node exists, you can confirm the device is known to the kernel here.

# Browse sysfs for block devices
ls /sys/block/
ls /sys/class/block/

# Check network devices in sysfs
ls /sys/class/net/

# Check tty devices
ls /sys/class/tty/

# Read the device type and driver information
cat /sys/block/sda/device/type
cat /sys/class/net/enp3s0/device/driver/module

If the device appears in /sys/class/ but not in /dev, a udev rule is likely missing or misconfigured.

Practical Fixes by Scenario

Fix A: Block Device Missing After Reboot

Symptoms: /dev/sdb vanished after a reboot; lsblk shows only the system disk.

  1. Run dmesg | grep -i "sd[a-z]\|scsi" — if you see "ata" or "scsi" link errors, the cable or port may be loose.
  2. If the device appears in lsusb (for USB storage) but not in lsblk, check lsmod | grep usb_storage. Load it if missing.
  3. Use persistent device paths in your mount commands or /etc/fstab:
# Instead of /dev/sdb1, use:
UUID="a1b2c3d4-..."   /mnt/data   ext4   defaults   0   2

# Or use /dev/disk/by-id/
/dev/disk/by-id/usb-Seagate_Expansion_Desk-XXXX-part1  /mnt/backup  ext4  defaults  0  2

To find UUIDs reliably:

sudo blkid
ls -l /dev/disk/by-uuid/

Fix B: Network Interface Name Changed (Predictable Naming)

Symptoms: ip link show eth0 returns "Device 'eth0' does not exist", but ip link lists enp3s0.

Modern Linux uses predictable network interface names based on BIOS/firmware slot locations. To adapt:

# Discover current interface names
ip link show
ls /sys/class/net/

# Update network configuration files (Netplan, /etc/network/interfaces, etc.)
# Replace 'eth0' with the new name, e.g., 'enp3s0'

# For NetworkManager connections:
nmcli connection show
nmcli connection modify "Wired Connection" ifname enp3s0

# Alternatively, revert to old-style naming with kernel parameter:
# Add to GRUB_CMDLINE_LINUX in /etc/default/grub:
net.ifnames=0 biosdevname=0
# Then run: sudo update-grub && sudo reboot

Be careful reverting naming — predictable names prevent race conditions on systems with multiple NICs.

Fix C: USB Serial Adapter Not Creating /dev/ttyUSB0

Symptoms: lsusb shows the adapter, but /dev/ttyUSB* is empty.

# Check which driver the USB device is bound to
lsusb -t

# If bound to usb-storage instead of a serial driver, unbind and rebind:
# First, find the device bus ID from lsusb
lsusb
# Example output: Bus 001 Device 003: ID 0403:6001 FTDI FT232 USB-Serial

# Check current driver in sysfs
ls /sys/bus/usb/devices/1-3/driver

# If it shows 'usb-storage', unbind it:
echo "1-3" | sudo tee /sys/bus/usb/drivers/usb-storage/unbind

# Bind to the correct serial driver:
sudo modprobe ftdi_sio
echo "0403 6001" | sudo tee /sys/bus/usb-serial/drivers/ftdi_sio/new_id

# Alternatively, use usb_modeswitch if the device has dual functionality
sudo usb_modeswitch -v 0x0403 -p 0x6001 -J

For a permanent fix, create a udev rule to bind the correct driver automatically:

# Create /etc/udev/rules.d/99-usb-serial.rules
# Replace vendor/product IDs with your device's values from lsusb
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", \
  RUN+="/bin/sh -c 'modprobe -b ftdi_sio && echo $idVendor $idProduct > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"

# Reload udev rules
sudo udevadm control --reload-rules
sudo udevadm trigger

Fix D: Device Present but "Device not found" from fsck or mount

Symptoms: The block device exists (lsblk confirms), but mount or fsck complains "device not found" or "No such device".

# Check if the device node has actually the correct major:minor numbers
ls -l /dev/sda1
stat /dev/sda1

# Verify the device contains a valid partition table
sudo fdisk -l /dev/sda
sudo parted /dev/sda print

# If the partition table is corrupted, try to recover:
sudo fsck /dev/sda1
# For the whole disk (GPT recovery):
sudo gdisk /dev/sda   # use 'r' recovery options
sudo parted /dev/sda rescue START END

# Check for device mapper or loop device conflicts
losetup -l
dmsetup ls

Sometimes a stale device mapper entry or a leftover loop device from a previous container/VM deployment occupies the same minor number. Clear them:

sudo dmsetup remove stale_mapper_name
sudo losetup -d /dev/loopX

Fix E: GRUB Reports "Device not found" at Boot

Symptoms: At boot, GRUB prints "error: device not found" followed by a UUID, then drops to rescue shell.

This happens when the GRUB configuration references a disk UUID that no longer exists — common after disk cloning or partition resizing.

# From GRUB rescue shell, identify available partitions
ls
# Example: (hd0,gpt2) (hd0,gpt1)

# Boot manually to the system:
set root=(hd0,gpt2)
linux /boot/vmlinuz-* root=/dev/sda2
initrd /boot/initrd-*
boot

# Once booted into the system, fix the UUID references:
sudo update-grub          # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # Fedora/RHEL
sudo grub-mkconfig -o /boot/grub/grub.cfg     # Arch

# Verify the UUID in grub.cfg matches current partitions:
grep "search.*UUID" /boot/grub/grub.cfg
sudo blkid

Advanced Diagnostic Techniques

Using strace to Trace System Calls

When a tool reports "device not found" but the reason is opaque, trace its system calls to see exactly which path it tries to open:

# Trace mount command
strace -e open,openat,stat mount /dev/sdb1 /mnt 2>&1 | grep -E "ENOENT\|ENXIO"

# Trace fsck
strace -e open,openat fsck /dev/sdb1 2>&1 | tail -30

# Look for ENOENT (No such file or directory) or ENXIO (No such device)
# ENXIO often indicates the device node exists but the driver returned an I/O error

Inspecting Device Node Major/Minor Numbers

Device nodes are just handles pointing to kernel drivers via major/minor numbers. If these numbers are wrong, the kernel driver won't match.

# Show major/minor for a device
stat -c "%t %T" /dev/sda
# Returns major (hex) and minor (hex), e.g., 8 0 for /dev/sda

# List all allocated major numbers for block devices
cat /proc/devices | grep block

# Create a temporary device node manually (for testing)
sudo mknod /tmp/test-sda b 8 0
# b = block device, 8 = major for SCSI/SATA disks, 0 = minor for first disk

Prevention and Best Practices

Conclusion

The "Device not found" error in Linux is a symptom with many possible causes, spanning hardware detection, kernel module loading, udev device node creation, and userspace naming conventions. By working through a structured diagnosis — verifying bus visibility in dmesg and lsusb/lspci, confirming driver binding in sysfs, checking module presence with lsmod, and tracing device node creation with udevadm — you can isolate the root cause efficiently. The fixes range from simple module loading and initramfs rebuilding to persistent naming adjustments and custom udev rules. Adopting persistent identifiers, keeping firmware current, and documenting custom configurations transforms these errors from recurring emergencies into rare, quickly resolvable incidents.

🚀 Need a reliable AI agent for your project?

Deploy Hermes Agent in 10 minutes. Managed hosting, zero DevOps.

Get Started — $23.99/mo
← Back to all articles