I have this wierd problem that I don’t understand. I have been using an external SATA hard drive in a USB caddy for backups. It’s been fine for years. Recently it started not auto-mounting when I plugged it in, and making a funny sort of repetitive ‘restarting’ noise, sounding as if the head was sticking somewhere. Not always, but enough to be annoying. I thought it had gone west and I bought a brand new replacement, with a new caddy too, but that has the same problem so it looks like it isn’t either drive nor the caddies themselves. The system log shows the drive mounting and then being disconnected - the log extract is below. Can anyone throw some light on what is gong wrong?
Linux Mint 18.3, Kernel 4.15.0-106-generic #107~16.04.1-Ubuntu SMP Thu Jun 4 15:40:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Gigabyte board, 8GB memory, USB2 ports.
The log extract (this repeats endlessly until the drive is physically disconnected, with the device number incrementing each time):
Jun 28 17:09:59 study kernel: [ 505.967378] usb 2-1.1: new high-speed USB device number 26 using ehci-pci
Jun 28 17:09:59 study kernel: [ 506.080235] usb 2-1.1: New USB device found, idVendor=152d, idProduct=2329
Jun 28 17:09:59 study kernel: [ 506.080237] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Jun 28 17:09:59 study kernel: [ 506.080238] usb 2-1.1: Product: USB to ATA/ATAPI Bridge
Jun 28 17:09:59 study kernel: [ 506.080238] usb 2-1.1: Manufacturer: JMicron
Jun 28 17:09:59 study kernel: [ 506.080239] usb 2-1.1: SerialNumber: D61A3188123F
Jun 28 17:09:59 study kernel: [ 506.080791] usb-storage 2-1.1:1.0: USB Mass Storage device detected
Jun 28 17:09:59 study kernel: [ 506.080935] usb-storage 2-1.1:1.0: Quirks match for vid 152d pid 2329: 8020
Jun 28 17:09:59 study kernel: [ 506.081123] scsi host5: usb-storage 2-1.1:1.0
Jun 28 17:09:59 study mtp-probe: checking bus 2, device 26: “/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1”
Jun 28 17:09:59 study mtp-probe: bus: 2, device: 26 was not an MTP device
Jun 28 17:10:00 study kernel: [ 507.108047] scsi 5:0:0:0: Direct-Access WDC WD50 00BPVT-00HXZT1 PQ: 0 ANSI: 2 CCS
Jun 28 17:10:00 study kernel: [ 507.108667] sd 5:0:0:0: Attached scsi generic sg7 type 0
Jun 28 17:10:00 study kernel: [ 507.109767] sd 5:0:0:0: [sdg] 976773168 512-byte logical blocks: (500 GB/466 GiB)
Jun 28 17:10:00 study kernel: [ 507.111955] sd 5:0:0:0: [sdg] Write Protect is off
Jun 28 17:10:00 study kernel: [ 507.111957] sd 5:0:0:0: [sdg] Mode Sense: 34 00 00 00
Jun 28 17:10:00 study kernel: [ 507.112987] sd 5:0:0:0: [sdg] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
Jun 28 17:10:00 study kernel: [ 507.152508] sd 5:0:0:0: [sdg] Attached SCSI disk
Jun 28 17:10:01 study kernel: [ 508.024133] usb 2-1.1: USB disconnect, device number 26
Jun 28 17:10:01 study kernel: [ 508.028261] scsi 5:0:0:0: rejecting I/O to offline device
Jun 28 17:10:01 study kernel: [ 508.028266] scsi 5:0:0:0: [sdg] killing request
Jun 28 17:10:01 study kernel: [ 508.028283] scsi 5:0:0:0: [sdg] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Jun 28 17:10:01 study kernel: [ 508.028286] scsi 5:0:0:0: [sdg] CDB: Read(10) 28 00 00 00 10 00 00 00 08 00
Jun 28 17:10:01 study kernel: [ 508.028287] print_req_error: I/O error, dev sdg, sector 4096
Jun 28 17:10:01 study kernel: [ 508.028356] Buffer I/O error on dev sdg, logical block 512, async page read
Jun 28 17:10:01 study systemd-udevd[3586]: inotify_add_watch(9, /dev/sdg, 10) failed: No such file or directory
Jun 28 17:10:03 study colord-sane: io/hpmud/pp.c 627: unable to read device-id ret=-1
Also I notice that it is reported as /dev/sdg, but my internal drives are /dev/sda and /dev/sdb. Should this not be /dev/sdc? is that significant?
Keith, thank you for the response. I’m like you, out of my depth on this sort of thing. That article has a log extract that looks remarkably like mine, so it looks like I am suffering from a USB Disconnect action instead of a USB Reset action, but I am puzzled as to why this is occurring. This is the Mint automount at work when I plug in the external drive and according to the log the drive remains connected:
[sdg] Attached SCSI disk
for a little under one second, until this is logged:
usb 2-1.1: USB disconnect, device number 26
What could be causing that to be happening? Is it possible that a kernel update (I have been installing every new kernel update as they are available via the Update Manager tool) has caused this? Could it be that the latest kernel no longer works with my hardware (which is now a good few years old) and I should be reverting to increasingly earlier kernels, until the problem stops?
This is very often a good move in cases where a previously working distro suddenly ‘plays up’ possibly due to a conflict with the new kernel. If you revert to a known working kernel, (often the one before) and the problem disappears, then the issue is resolved immediately. It’s then a matter of waiting until the conflicting software ‘catches up’ or a patch is found and then the new kernel can be utilised. It is rarely a problem to wait a while for this to happen, other than for a security threat - very rare in Linux.
If it’s been a bug in Mint, then perhaps Mint 20 has indeed “caught up”. If so, then creating a Live USB of Mint 20 might show if that’s been the problem. What do you think?
I find the computer’s assignment of /dev a mystery — when I plug in a USB, it’s always /dev/sdc, despite the fact that I don’t have a /dev/deb — so I have no idea why the identification of your device varies. But I think the stackexchange article has the answer. I always assign a mount point for my USB sticks in fstab:
/dev/sdc1 /media/usb auto noauto,noatime,users 0 0
You could try doing that and using UUID or LABEL to identify the external drive, as indicated in the article. Whether that will end the disconnects is another question!
DavidMcCann, I’m probably being a numpty but can you please explain your fstab suggestion a little more? I’ve tried your code line as stated and rebooted but it doesn’t seem to do anything, and the format doesn’t look like the rest of my fstab file. I added a modified version, eg
LABEL=data_neil /dev/sdc1 /media/usb auto noauto,noatime,users 0 0
but that is no better. I am also puzzled by
/media/usb
(I have no such folder on my Mint 18.3 machine) and it looks out of place in fstab.
I’ve now tried booting from my original Mint 18.3 live CD (kernel 4.10.0.38), and have the same problem (and the log is very similarly to the extract I originally posted), so on reflection I don’t think it’s a kernel issue; I was using 18.3 and backing up to the external drive without issue for many months before I started updating the kernel.
Also I can plug in a USB ‘stick’ and it auto-mounts and stays mounted without a problem. It seems to be the drive and caddy that are giving my system indigestion, but swapping drives, caddies and cables doesn’t make any difference.
Yesterday and this morning the problem was persistent, but just now I managed to do a backup without the device being disconnected. This is bizarre! Here is the compete log section from plugging the drive in, to completing the backup and unmounting the dirve:
Jul 1 13:18:33 study kernel: [ 2429.538669] usb 2-1.1: new high-speed USB device number 9 using ehci-pci
Jul 1 13:18:33 study kernel: [ 2429.647602] usb 2-1.1: New USB device found, idVendor=152d, idProduct=2329
Jul 1 13:18:33 study kernel: [ 2429.647605] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Jul 1 13:18:33 study kernel: [ 2429.647607] usb 2-1.1: Product: USB to ATA/ATAPI Bridge
Jul 1 13:18:33 study kernel: [ 2429.647608] usb 2-1.1: Manufacturer: JMicron
Jul 1 13:18:33 study kernel: [ 2429.647609] usb 2-1.1: SerialNumber: D61A3188123F
Jul 1 13:18:33 study kernel: [ 2429.648725] usb-storage 2-1.1:1.0: USB Mass Storage device detected
Jul 1 13:18:33 study kernel: [ 2429.648885] usb-storage 2-1.1:1.0: Quirks match for vid 152d pid 2329: 8020
Jul 1 13:18:33 study kernel: [ 2429.648987] scsi host4: usb-storage 2-1.1:1.0
Jul 1 13:18:33 study mtp-probe: checking bus 2, device 9: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1"
Jul 1 13:18:33 study mtp-probe: bus: 2, device: 9 was not an MTP device
Jul 1 13:18:34 study kernel: [ 2430.671302] scsi 4:0:0:0: Direct-Access WDC WD50 00BPVT-00HXZT1 PQ: 0 ANSI: 2 CCS
Jul 1 13:18:34 study kernel: [ 2430.671899] sd 4:0:0:0: Attached scsi generic sg3 type 0
Jul 1 13:18:34 study kernel: [ 2430.672417] sd 4:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/466 GiB)
Jul 1 13:18:34 study kernel: [ 2430.673416] sd 4:0:0:0: [sdc] Write Protect is off
Jul 1 13:18:34 study kernel: [ 2430.673418] sd 4:0:0:0: [sdc] Mode Sense: 34 00 00 00
Jul 1 13:18:34 study kernel: [ 2430.675932] sd 4:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 13:18:34 study kernel: [ 2430.720791] sd 4:0:0:0: [sdc] Attached SCSI disk
Jul 1 13:18:35 study kernel: [ 2431.088086] EXT4-fs (sdc): recovery complete
Jul 1 13:18:35 study kernel: [ 2431.090302] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null)
Jul 1 13:18:35 study udisksd[1766]: Mounted /dev/sdc at /media/neil/data_neil1 on behalf of uid 1000
Jul 1 13:18:37 study colord-sane: io/hpmud/pp.c 627: unable to read device-id ret=-1
Jul 1 13:20:21 study crontab[4367]: (root) LIST (root)
Jul 1 13:20:23 study backintime (root/1): INFO: Lock
Jul 1 13:20:23 study backintime (root/1): INFO: Take a new snapshot. Profile: 1 Main profile
Jul 1 13:20:23 study backintime (root/1): INFO: Found leftover 'new_snapshot' which can be continued.
Jul 1 13:20:24 study backintime (root/1): INFO: [qt4systrayicon] begin loop
Jul 1 13:20:34 study backintime (root/1): INFO: Call rsync to take the snapshot
Jul 1 13:23:54 study backintime (root/1): INFO: Save config file
Jul 1 13:23:54 study backintime (root/1): INFO: Save permissions
Jul 1 13:23:59 study backintime (root/1): INFO: Create info file
Jul 1 13:23:59 study backintime (root/1): INFO: Keep min free disk space: 1024 MiB
Jul 1 13:23:59 study backintime (root/1): INFO: Keep min 2% free inodes
Jul 1 13:24:01 study backintime (root/1): INFO: Unlock
Jul 1 13:24:02 study backintime (root/1): INFO: [qt4systrayicon] end loop
Jul 1 13:24:33 study rtkit-daemon[1777]: Supervising 4 threads of 2 processes of 1 users.
Jul 1 13:24:47 study rtkit-daemon[1777]: message repeated 5 times: [ Supervising 4 threads of 2 processes of 1 users.]
Jul 1 13:24:47 study rtkit-daemon[1777]: Successfully made thread 4602 of process 4121 (n/a) owned by '1000' RT at priority 10.
Jul 1 13:24:47 study rtkit-daemon[1777]: Supervising 5 threads of 3 processes of 1 users.
Jul 1 13:24:53 study rtkit-daemon[1777]: message repeated 2 times: [ Supervising 5 threads of 3 processes of 1 users.]
Jul 1 13:36:53 study udisksd[1766]: Cleaning up mount point /media/neil/data_neil1 (device 8:32 is not mounted)
Jul 1 13:36:53 study udisksd[1766]: Unmounted /dev/sdc on behalf of uid 1000
Sorry I confused you — I assumed too much. Look at my fstab entry
/dev/sdc1 /media/usb auto noauto,noatime,users 0 0
We start with the device name. That can be a /dev address, a label, or a uuid — but not two of them. I’ve used a /dev address, but you don’t want one because yours keeps changing.
Next we have a mount point. I use /media/usb because it’s convenient for me, and I had to create it. You have been using /media/neil/data_neil1 which was presumably created automatically, but you could use anything, such as /media/data or /home/neil/data or whatever you prefer — but you do have to create it.
Thirdly, the file system. I use auto so that any flash drive will be accepted — you should use whatever fining system you have on your device, like ext4.
David’s explanation is still a bit advanced for me, but I did find something easier to follow and which works for me, and might be worth a try if David’s method doesn’t work for you.
Install pmount as it doesn’t require user authorisation:
sudo apt-get install pmount
Immediately after your device auto-unmounts, leave it connected and enter:
sudo fdisk -l
Your disk should be listed near the bottom of the output as /dev/sdc.
If it is, then create a mount point and, as David suggests, you can call it anything you like, e.g. “/media/usb, /media/data, /home/neil/data or whatever you prefer”. For example:
sudo mkdir /media/usb
If your chosen mount point already exists, it will tell you - and that’s fine.
Then:
sudo pmount /dev/sdc
…and your device should mount. If it still doesn’t mount, then I’m out of ideas. If it does, then don’t forget to unmount it when you have finished working with the device:
Keith, the drive isn’t appearing as a device (using fdisk), so I’m stumped. Oddly something is giving it a good kicking, because I can hear the heads repeatedly being moved (it sounds like they’re being banged up against a stop!).
I’m going to try to install it as an internal drive, which will isolate the USB system and tell me if it is a caddy or USB problem, or the new drive itself. If that doesn’t get me anywhere I’ll try a different distro live CD. After that I don’t know.
DavidMcCann, thanks - that is clearer now. I’ve done some reading now and learned a lot about the options fstab offers that I never bothered with before.
So I now have
LABEL= /media/neil/ auto (etc...)
in my fstab, and as long as exists the system boots up okay even if the drive isn’t plugged in, but it still won’t mount when plugged in, even if I do a
sudo mount -a
command. Sometimes it just automounts when I plug it in, other times it doesn’t even appear as a device when I do
This is very strange. It can’t be a problem with the drive, as you’ve tried two. You could try using a different USB port to plug it in, or have you already done that? You could try a different LInux live disk and see if it’s the software. That’s what debugging is like — trying different bits until you find the guilty party.
DavidMcCann, yes, I’ve tried plugging the caddy into both other internal USB ports and an external powered USB hub. Same experience all round so that at least tells me it isn’t a single USB port at fault. Also plugging in a USB stick works flawlessly.
I’m just waiting for a cable to be delivered, then I’m going to try connecting the drive into the motherboard as a direct SATA device. That will tell me if it is the drive at fault or not. If it isn’t, it must be something to do with the USB->SATA part. I suppose it’s just possible that both old and brand new drives have the same fault, although they are both formatted as ext4 on an ‘msdos’ volume, so I think that’s unlikely. But it is possible.
The live distro I used was the original Mint 18.3 that worked with the same external drive plugged in to a USB port for many months, so I don’t think it is the distro or the kernel given that the original kernel was fine, and now exhibits the problem as well as the latest kernel. Replacing the SATA->USB caddy with a new one (and new cable) doesn’t solve the problem either.
UPDATE: I’ve now plugged the new hard drive directly into a spare SATA socket on the motherboard, and it works perfectly. It appears as /dev/sdc, and I can mount that and backup to it quite reliably. In fact my old backup hard drive works just as well in the same way.
So I’m guessing that something is amiss with my USB>SATA caddies, both old and new. Can it be that the new one, a USB3>SATA3 device, is not properly compatible with my USB or USB2 ports?
UPDATE: I’ve now plugged the new hard drive directly into a spare SATA socket on the motherboard, and it works perfectly. It appears as /dev/sdc, and I can mount that and backup to it quite reliably. In fact my old backup hard drive works just as well in the same way.
So I’m guessing that something is amiss with my USB>SATA caddies, both old and new. Can it be that the new one, a USB3>SATA3 device, is not properly compatible with my USB or USB2 ports?
It turned out that the drives in their USB->SATA caddies were not getting adequate power from the USB port. No idea why this should suddenly be the case after years of using the same port with the same drive (and I’ve not added any other hardware to the PC), but that seems to have been the cause. On a hunch I bought an independently powered USB hub, plugged it all in, and that solved the problem. Been working reliably once again, ever since.