USB Device Not Detected on Linux: lsusb and dmesg Checks

When a USB device is not working on Linux, first establish whether the kernel detects it. Run lsusb, then inspect new kernel messages as you connect a spare peripheral. Detection, driver binding, and application access are separate steps.

lsusb
lsusb -t
sudo dmesg --follow --human

Use the last command in a separate terminal and press Ctrl+C when finished. These commands inspect the system; they do not install drivers or repair hardware.

1. Does the device appear in lsusb?

Example output:

Bus 002 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

0bda:8153 is the vendor/product ID pair. The bus and device number describe its current enumeration and may change after reconnecting. The example ID is a USB Ethernet adapter; use the values reported for your own device.

If a device appears, enumeration succeeded. Continue to driver and application checks. If it is absent, check the connection, cable, power, and whether you are inspecting the correct host. A charge-only cable will not provide a data connection. A virtual machine may need explicit USB passthrough; a container may not expose host USB devices.

Do not conclude that an empty filtered command proves the hardware is absent: first inspect the unfiltered list. The lsusb reference explains vendor filters and tree output.

2. Compare before and after without touching storage

Choose a spare mouse or another non-storage peripheral. Keep a working keyboard or input device connected. Do not unplug a mounted disk, a production network adapter, or the device providing your only remote connection.

In terminal A:

sudo dmesg --follow --human

If the system denies access, use authorized administrator access. In a container, switch to the actual host for this diagnosis rather than weakening kernel log restrictions.

In terminal B:

lsusb

Note the current list. Connect the spare peripheral and run lsusb again. Identify the new row and compare its timing with terminal A. You may see messages describing a new USB device, vendor/product IDs, and a driver attaching. Exact wording depends on the kernel and device.

Then run:

lsusb -t

Find the relevant interface and read its Driver= value. A composite device can have several interfaces with different drivers; do not expect one driver entry for the whole physical device. A speed such as 480M is a reported connection speed, not a measured file-transfer rate.

Success means you can record the new device ID, identify the corresponding kernel event, and distinguish detection from driver binding. Disconnect your spare non-storage peripheral, confirm its row disappears, and stop log following with Ctrl+C. If there is no new row, that observation is still useful evidence for the next step.

3. Interpret the failure point

Observation	Next check
No new row and no kernel event	Data cable, port, power, host/VM passthrough
Repeated connect/disconnect events	Cable or connector stability, hub power, relevant kernel errors
Device row exists but expected driver is absent	Exact vendor/product ID, kernel support, distribution driver documentation
Driver appears but application cannot use the device	Application selection, permissions, and the device-specific subsystem
Storage is visible but files are absent	Block devices, partitions, and mount state; do not format it

These observations narrow the investigation; a reset message alone does not prove that a cable is faulty. Capture the actual error and correlate it with a deliberate connection attempt.

For kernel-log filtering and timestamp limitations, use the dmesg guide. Do not clear the ring buffer: older messages may contain the first failure.

4. If the device is USB storage

USB enumeration does not mean the disk is mounted. Inspect the storage layer:

lsblk -f
findmnt

Compare device names, filesystem types, and mount points. If you already know the directory, findmnt -T /path/to/directory shows its containing filesystem. It may report the root filesystem if the expected external disk is not mounted there.

Read how findmnt identifies a filesystem before interpreting a directory as proof of a successful mount. Do not format or run repair commands simply because a drive does not appear in a file manager. Preserve the evidence and determine whether the data needs recovery first.

5. Write a useful troubleshooting note

Record the distribution/kernel version, device model and ID, direct port versus hub, whether enumeration occurred, driver information, and the relevant log lines. Avoid pasting entire logs containing unrelated machine details when a few relevant lines explain the event.

Change one thing at a time: for example, test a known data-capable cable, then a direct port. Repeat the same observations after each change. You should be able to state what improved, what stayed the same, and which layer still fails.

Start Chapter 1 free in Shell Samurai to practice Linux fundamentals. The physical USB exercise requires access to a Linux host and a suitable peripheral; a hosted container cannot reproduce a local hardware connection.

References: lsusb manual, dmesg manual.