Rescan for removable devices

I’m looking for a way to rescan for removed usb devices and get them back under /dev - ideally from the command line.

Scenario:
Plug usb thumb drive in.
KDE (5.18) picks it up and mounts it.
Remove device using KDE : “you can now safely remove divice”.

Terminal:
lsblk : device not listed. ( was previously /dev/sdc )

I want to make it show up again (as /dev/sdc) without physically unplugging and plugging it back in again.

Googling “linux rescan usb” returns lsusb and other commands. For example: https://www.linuxquestions.org/questions/linux-general-1/rescan-for-usb-devices-754916/

Yeah, I tried lsusb - no joy, I read the articles on udevadm trigger - no joy. I also read the thread on Arch Linux where the moderators and other contributors gave non-answers and then had a go at the OP for daring to suggest they might actually supply an answer if they had one.

Then I posted here.

Now, @jlehtome, you’ve given me useful info here before and I appreciate your help but telling people to “google it” on a forum is rude in the extreme. It suggests the OP either doesn’t have the intelligence to do a basic search or is abusing and taking advantage of other people’s willingness to help - freeloading on their time.

The link you’ve given is 20yrs old - have you tried the suggestions ? They don’t work. Ok, maybe one of the write-your-own-code links at the end do but I won’t know that without a lot more effort than this should take.

Perhaps I should have been clearer “is there an easy, simple, one-command way to do this simple thing today ?”

Even if you quickly found an actual answer by googling, it is possible the OPs search didn’t return that answer. So in future, and I say this to everyone, if you are going to tell someone to “google” just skip the post and don’t say anything.

The original post doesn’t make sense to me. Scan for a device that’s just been removed and somehow it appears in the list?
He’s not saying just use Google, he’s saying that he found some related information by using that search term.

@gerry666uk, you’re havin’ a laugh right ?

removed via the KDE UI - not physically removed. Do you really believe I physically removed the disk and expected the machine to be able to find it when it is not physically connected ?

“Googling “ linux rescan usb ” returns lsusb and other commands. For example:” suggests “this is what you might find if you were to google, maybe try reading some of those” which implies I didn’t bother to /don’t know how to google. You really have to be reaching to interpret it any other way.

My bad. Did not see from OP that several options had already been explored and found nonfunctional. Yes, that link had old entries. For example, power management of USB has changed.

This is old too, but the first “way” in it, eject -t /dev/sdc does the trick on my system.

eject -t only seems to work if you used eject to remove the drive.

There doesn’t seem to be any simple, universal, non-physical way of doing this i.e. logically reconnecting a usb drive you inadvertently logically disconnected via the desktop UI or other miscellaneous method.

So there’s two main ways of “removing” a USB device. And which option is used depends on what file manager is used!

The first is a “soft eject”. This is what the eject command does, and also appears to be what “pcmanfm” does. In this scenario, eject -t will cause the partitions to reappear. This works because the device is still connected to the bus (and still shows in /dev/) and so the OS can control it.

The other is more “hard”. This is what udiskctl power-off and Nautilus does. Here the device is effectively removed from the bus and so disappears from /dev/

(This example done on a Debian machine, but it should apply to Rocky8).

# /usr/bin/udisksctl power-off -b /dev/sdg
# dmesg | tail -1
[179677.977567] usb 1-2.2: USB disconnect, device number 10

We can see the kernel has reported the USB device has been disconnected. It no longer shows up in lsusb as a result.

So how do we tell the OS the disk has been re-inserted?

That “usb 1-2.2” becomes important. This means USB bus 1-2, port 2.

We can use uhubctl to re-enabled it, by turning it off and on:

# /usr/sbin/uhubctl -l 1-2 -p 2 -a off  
Current status for hub 1-2 [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0101 power connect []
Sent power off request
New status for hub 1-2 [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0000 off

# uhubctl -l 1-2 -p 2 -a on 
Current status for hub 1-2 [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0000 off
Sent power on request
New status for hub 1-2 [0bda:5411 Generic 4-Port USB 2.0 Hub, USB 2.10, 4 ports]
  Port 2: 0101 power connect []

And it’s re-appeared again!

[179834.775058] usb 1-2.2: new high-speed USB device number 11 using ehci-pci
[179834.888056] usb 1-2.2: New USB device found, idVendor=0781, idProduct=5567, bcdDevice= 1.00
[179834.888063] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[179834.888067] usb 1-2.2: Product: Cruzer Blade
[179834.888070] usb 1-2.2: Manufacturer: SanDisk
[179834.888074] usb 1-2.2: SerialNumber: 4C530000260115213093

(And the partitions mounted)

Note that not all hubs can be controlled this way.

uhubctl is available in EPEL.

(Again, that was done on Debian, but it should work the same on RHEL).

@sweh, yeah, but that’s all just way too much hassle - I just want to avoid having to unplug/replug on the odd occasion I need it and remembering the steps (given it’s a relatively rare occurence) isn’t going to happen: I’d have to dig out the notes…and copy and paste commands into the terminal : quicker to unplug/replug and damn! the extravagant wear-and-tear on that fragile usb port :slight_smile: … it seems the obvious solution is to check the power-on status on all usb ports and toggle the “off” ones to on … then turn off the empty ones … : you’d think (by now) there’d be a lsusb --rescan to do that… :frowning: I could probably (maybe… how to check for empty?..) put a script together but more pressing issues in the todo list …