Trouble with USB 3 port

[linuxman]

I have a problem with a USB 3 port on a desktop running Debian Linux. The problem started when a system backup was attempted to a portable hard drive plugged into the USB 3 port. The backup operation had previously been done many times with no problems.

This time the mount operation failed with a message of the type 'can't find UUID=....'

Various commands such as fdisk -l showed that the kernel was not detecting the drive.

The drive was unplugged, then replug with a dmesg command issued straight after the replug.
The dmesg output seemed to indicate the portable hard drive itself had some problem.

A new portable hard drive was plugged into the port, but the kernel could not see the new drive, although a slowly flashing light on the drive indicated some power was reaching the hard drive.

I thought that perhaps the port was not supplying enough power to the drive, so I then plugged a new USB flash drive into the port. However the kernel would not recognise the flash drive.

Someone subsequently suggested that perhaps the power pins of the port were working but not the data pins.
This could perhaps be due to a problem with the port's USB header or associated cabling or possibly due to damage to
the host controller or associated wiring.

Any thoughts on this, please.

 

[hogfish]

I run Debian testing and regularly use external usb drives via an USB 3 port.
What mount command did you use?
The fact that you had a message about the UUID sounds as if something (not hideous systemd, I hope) was guessing which drive to use and getting it wrong.

To debug , I would start as root.
Here is a session here as I plugin an external drive:
1) plugin in the drive.
2) As root: # ls -l /dev/disk/by-label/
I see among others:

lrwxrwxrwx 1 root root 10 Oct 11 14:47 aelstor1 -> ../../sdc1

That depends on the disc having a label. In my case "aelstor1".
If it hasn't got a label, you could look at dmesg:
An extract from my dmesg:

3694.574771] sd 7:0:0:0: Attached scsi generic sg3 type 0
[ 3694.575293] sd 7:0:0:0: [sdc] 937703088 512-byte logical blocks: (480 GB/447 GiB)
[ 3694.575295] sd 7:0:0:0: [sdc] 4096-byte physical blocks
[ 3694.575443] sd 7:0:0:0: [sdc] Write Protect is off
[ 3694.575445] sd 7:0:0:0: [sdc] Mode Sense: 53 00 00 08
[ 3694.575727] sd 7:0:0:0: [sdc] Disabling FUA
[ 3694.575729] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 3694.575986] sd 7:0:0:0: [sdc] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[ 3694.598129] sdc: sdc1 <============== Note sdc1
[ 3694.599658] sd 7:0:0:0: [sdc] Attached SCSI disk

As you see it shows the partition/disc is /dev/sdc1 in my case

If you care, you could check
ls -l /dev/disk/by-uuid/

In my case I have
lrwxrwxrwx 1 root root 10 Oct 11 14:47 7156460d-aae3-48e5-bdd2-5885b917b245 -> ../../sdc1
(well actually, I have slightly changed the uuid for security reasons).
That is pretty horrible and not good for humans, but it does tell you what uuid should be used for this particular disc.

3)
Now I can just
# mount /dev/disk/by-label/aelstor1 /ssdback1/
No error message: success.
I could have used
# mount /dev/sd1 /ssdback1/
if I didn't have a label.

4) Check if you want to feel comfortable:

# findmnt /ssdback1
TARGET SOURCE FSTYPE OPTIONS
/ssdback1 /dev/sdc1 f2fs rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,....
confirms that all is well.

If you do something similar and the mount fails, post the error message and perhaps someone here can help.