External HDD Showing Up As Loop Device

[aforwood]

I have a 4TB external HDD (Seagate Backup Plus Portable) with two partitions on it, one is an EXT4 and the other is an NTFS. It hasn't been visible to Ubuntu for a while now. I used to have a dual boot system but I stopped using Windows much because I preferred Ubuntu. The HDD wasn't a problem with Windows previously, but Windows did something to it during an upgrade that was waiting to load and it's been invisible to Ubuntu ever since. Windows was removed from my system immediately after that last access due to the fact that it's always acted like it owned my computer and that was the final straw. The HDD doesn't show up on other Windows or Ubuntu systems.

I decided to plug in the HDD last night and it suddenly shows up in Disks as you see in the image below. It appears to be full, based on the color of the volume. It's been a while since I last accessed it so I can't remember if there was any sort of MBR at the front of the drive, but I believe the volume it shows might be that, based on it's size. I let GParted guide me when I partitioned it so it's most likely uses GPT due to the size of the drive. The EXT4 partition came after that and is about a TB or more in size, and the second partition is NTFS and was left for future use so I gave it the remaining drive space. It was a fairly new drive and worked just fine in either OS until Windows got at it that last time.

I'm not certain what to do at this point. The data on the drive is very important to me and I don't want to lose it. I've tried everything I can over the months to try to get Ubuntu to see the drive, and occasionally it shows signs that it sees it when I run dmesg after a boot, such as giving the following messages when it's been plugged into the port that dmesg is giving the error message for:

"unable to enumerate USB device"

and

"connect -debounce failed"

Of course, lsblk, lsusb. lsscsi, etc. don't see it at all and it has never showed up in /dev/ (except now as loop22).

I'm still fairly new to using bash commands and utilities to analyze this problem, and I don't want to do anything that might make it disappear again or corrupt anything that might.be retrievable before I consult someone with more knowledge that might be able to help me.

 

[camtaf]

My personal opinion would be to see if it will mount from the command line.
If you can mount it, back up the data to another disk, or to your internal disk.
Then you can play around with it, knowing your data is safe.
Failing that, fsck might fix it, depending on what MSWindows did to it.
There is also a way to use another replacement superblock - https://askubuntu.com/questions/796240/how-to-restore-my-superblocks

 

[bob466]

Have you tried to mount the drive by clicking the black triangle...should turn to a black square...

Of cause the Drive could be failing.

 

[MikeWalsh]

@aforwood :-

Unfortunately, Bob may have a point.

The 2TB and 4TB Seagate desktop externals (these are 'Barracuda' drives' internally) did not have a very good reputation. My own 3 TB version of one of these has, touch wood, been issue-free to date, and is NOT on the list of known 'problem cases'.

In my case, I pulled the Barracuda drive from the enclosure and installed it internally in my HP Pavilion as a secondary data drive, and this eliminated the refusal of gSmartControl to 'see' it due to the USB-SATA 'bridge' card these things use.

A failing drive could, I'm afraid, be a very real possibility with these. There again, I might be barking up the wrong tree, and it may be a relatively easy 'fix'. I just don't know enough to be able to advise further.

Some of our other members are better suited to help with this stuff...


Mike.

 

[wizardfromoz]

G'day @aforwood and welcome to linux.org

Of course, lsblk, lsusb. lsscsi, etc. don't see it at all...

If you haven't tried them, can you give us relevant output from

blkid #(may require sudo)

and

sudo fdisk -l

# and also

inxi -Fxz #(with the drive plugged in)

As you are likely aware, /dev/loop is typically for Snaps, and on;y shows up on 'buntu-based Distros, or other Distros for which snaps are in use.

Yours is showing as /dev/loop22 in Disks, so are there other numbered loops - these loops are also read-only by nature.

Cheers

Chris Turner
wizardfromoz

BTW - does it still show in GParted, and if so, choose View-Device information and give us its output?

 

[bob466]

aforwood,

At least you can see yours...plugged in my portable 1TB HDD today and nothing except a clicking noise...it's gone...only had it 10 years.

I'll be getting a 1TB portable SSD next for my System Images and other things...should last a long time...I hope.

 

[sphen]

aforwood,

At least you can see yours...plugged in my portable 1TB HDD today and nothing except a clicking noise...it's gone...only had it 10 years.

I'll be getting a 1TB portable SSD next for my System Images and other things...should last a long time...I hope.

It will be quieter.

 

[bob466]

It will be quieter.

Yes very true...it will get the last rites with my hammer.

 

[sphen]

I moved this distracting post to a new thread here:
https://www.linux.org/threads/data-...gnets-by-disassembling-old-disk-drives.45825/

A "Like" attached to this post may be for the previous version of this post.

 

[aforwood]

My personal opinion would be to see if it will mount from the command line.
If you can mount it, back up the data to another disk, or to your internal disk.
Then you can play around with it, knowing your data is safe.
Failing that, fsck might fix it, depending on what MSWindows did to it.
There is also a way to use another replacement superblock - https://askubuntu.com/questions/796240/how-to-restore-my-superblocks

Sorry I'm late getting back to this.

To save you reading my OP (to which my current situation has changed slightly), I'll summarize the problem I currently have, which is that I have an external HDD that isn't being recognized at all by Ubuntu (using lsblk, lsusb, lsscsi, etc.) but sometimes shows signs of being there when I run dmesg, which sometimes gives the following messages when it's been plugged into the port that dmesg is giving the error message for:

"unable to enumerate USB device"

and

"connect -debounce failed"

dmesg is currently showing:

[321920.885970] usb 1-1-port1: connect-debounce failed

My problem with trying to mount it is that I don't know how to identify the device using mount or whether I even can, since I'm not familiar with using mount.

I've reinstalled Ubuntu a number of times since the HDD was last working, so any files containing it's UUID, etc. are gone. All I have is information printed on the device's outer label and I remember the names of the two file storage partitions ('Backup Plus' and 'New Volume') and their types (EXT4 and NTFS respectively).

I'm not very familar with using fsck, but a simple test I ran with fsck early on to try to detect the HDD wasn't successful either.

I'll look at the link you gave me, but in the meantime, if there's any way I can try mounting the HDD with the information I have about it, please let me know.

 

[osprey]

Sorry I'm late getting back to this.

To save you reading my OP (to which my current situation has changed slightly), I'll summarize the problem I currently have, which is that I have an external HDD that isn't being recognized at all by Ubuntu (using lsblk, lsusb, lsscsi, etc.) but sometimes shows signs of being there when I run dmesg, which sometimes gives the following messages when it's been plugged into the port that dmesg is giving the error message for:

"unable to enumerate USB device"

and

"connect -debounce failed"

dmesg is currently showing:

[321920.885970] usb 1-1-port1: connect-debounce failed

My problem with trying to mount it is that I don't know how to identify the device using mount or whether I even can, since I'm not familiar with using mount.

I've reinstalled Ubuntu a number of times since the HDD was last working, so any files containing it's UUID, etc. are gone. All I have is information printed on the device's outer label and I remember the names of the two file storage partitions ('Backup Plus' and 'New Volume') and their types (EXT4 and NTFS respectively).

I'm not very familar with using fsck, but a simple test I ran with fsck early on to try to detect the HDD wasn't successful either.

I'll look at the link you gave me, but in the meantime, if there's any way I can try mounting the HDD with the information I have about it, please let me know.

It seems there's quite a bit of frustration with this. The following is what comes to mind, not all of which may seem relevant, but it's from a bit of free thinking about it.

1. Check all the usb ports. For each port I would plug in a known-to-work usb, run: lsusb, to see that it is seen. If all the usb ports work, that's helpful to know.

Next it may be useful to plug the usb-hdd progressively in each usb port to see if any pick it up. To do this I would open a terminal and run as root: dmesg -w. This command lets dmesg print to screen immediate output so that watching the terminal screen output would show you what it sees as you plug the usb in and out of each port.

If nothing happens or just errors appear, then the kernel is either not seeing the device, or unable to see it well enough for it to be used on the system. Could be cactus.

2. You wrote: "My problem with trying to mount it is that I don't know how to identify the device using mount". If by chance, you plugged in the external usb-hdd, and the command: lsusb, was able to see it, it would have been allocated a device name like: sdb, with partition names like: sdb1, sdb2. In that case, to mount the device you could select a partition to mount, say sdb1, and run a command as root like:

mount /dev/sdb1 /mnt

which would mount the partition at /mnt in the filesystem, after which you navigate to /mnt, and look into what's there. You can mount and umount partitions, and mount them simultaneously as long as they all have their own mount points which you can construct by, for example creating directories like: /mounts/1, /mounts/2 etc.

I realise that you may not see any usb-hdd, but if you did, the above is one way to go.

3. It's possible there's a power management issue with supply of power to the usb port, so you could reboot with the usb hdd plugged in and run:

udisksctl status

and see what it sees. If it sees the usb, use the device name output from this udisksctl command (e.g. sdb) and run the following to see details:

udisksctl info -b /dev/sdb

If dmesg didn't see anything, then udiskctl may not either, but this test may depend on the power system after a reboot. If by chance the udisksctl output has no errors and shows full details, then that's hopeful for rescue.

4. Another investigative approach would be run a live disk, have the usb-hdd plugged in, and use the tools of the live disk to see if it could see the usb-hdd. Such live disk could be a distro one such as a ubuntu or debian live disk, or a rescue disk such as systemrescue which is more specialised for the purpose with tools to suit.

5. What is on the external hdd? Is it an ordinary filesystem, or something else. I'm not familiar with snaps so can't say how they interfere with mounting.

Finally, the proposal by @camtaf in relation to superblocks, is something I would also investigate.

 

[camtaf]

"unable to enumerate USB device"

This means that the O/S can't find it to give it a designation (eg /dev/sda) for the system to use, so no, you won't be able to mount it.

As suggested, try it in each port, one at a time, after inserting it, run (you may need to use sudo) dmesg|tail to see if it gets a designation.

Otherwise, I think it is time to try a different super block.

 

[aforwood]

It seems there's quite a bit of frustration with this. The following is what comes to mind, not all of which may seem relevant, but it's from a bit of free thinking about it.

1. Check all the usb ports. For each port I would plug in a known-to-work usb, run: lsusb, to see that it is seen. If all the usb ports work, that's helpful to know.

Next it may be useful to plug the usb-hdd progressively in each usb port to see if any pick it up. To do this I would open a terminal and run as root: dmesg -w. This command lets dmesg print to screen immediate output so that watching the terminal screen output would show you what it sees as you plug the usb in and out of each port.

If nothing happens or just errors appear, then the kernel is either not seeing the device, or unable to see it well enough for it to be used on the system. Could be cactus.

2. You wrote: "My problem with trying to mount it is that I don't know how to identify the device using mount". If by chance, you plugged in the external usb-hdd, and the command: lsusb, was able to see it, it would have been allocated a device name like: sdb, with partition names like: sdb1, sdb2. In that case, to mount the device you could select a partition to mount, say sdb1, and run a command as root like:

mount /dev/sdb1 /mnt

which would mount the partition at /mnt in the filesystem, after which you navigate to /mnt, and look into what's there. You can mount and umount partitions, and mount them simultaneously as long as they all have their own mount points which you can construct by, for example creating directories like: /mounts/1, /mounts/2 etc.

I realise that you may not see any usb-hdd, but if you did, the above is one way to go.

3. It's possible there's a power management issue with supply of power to the usb port, so you could reboot with the usb hdd plugged in and run:

udisksctl status

and see what it sees. If it sees the usb, use the device name output from this udisksctl command (e.g. sdb) and run the following to see details:

udisksctl -b /dev/sdb

If dmesg didn't see anything, then udiskctl may not either, but this test may depend on the power system after a reboot. If by chance the udisksctl output has no errors and shows full details, then that's hopeful for rescue.

4. Another investigative approach would be run a live disk, have the usb-hdd plugged in, and use the tools of the live disk to see if it could see the usb-hdd. Such live disk could be a distro one such as a ubuntu or debian live disk, or a rescue disk such as systemrescue which is more specialised for the purpose with tools to suit.

5. What is on the external hdd? Is it an ordinary filesystem, or something else. I'm not familiar with snaps so can't say how they interfere with mounting.

Finally, the proposal by @camtaf in relation to superblocks, is something I would also investigate.

1) I've tried the HDD in all of the ports and then rebooted and ran dmesg to look for it. I haven't used dmesg -w while testing it on each port, but it's worth a try. All my ports work, btw. I've made sure by shuffling devices around and testing them, particularly my two other mass storage devices, which work fine on every one.

(Don't say cactus. I don't want cactus. You'll jinx it with those thoughts. I'll crawl through the desert for 100 miles in the blazing hot sun to get this HDD working so I can at least retrieve the data on it. It's always worked fine and wasn't that old or been through any rough handling before Windows got to it and made it invisible.)

2) I've been through /dev/ watching for sd[x] and sg[x] files, run lsusb, lsblk, etc., and even set up the original mount points in the hopes that it would help, but nothing.

3) and 4) I had to stop going through these suggestions last night because it was getting late and I have a bunch of programs open in their various workspaces that I have to close down before I can reboot. I have my doubts that it's a power issue to the port though, since my 5TB HDD and other other devices work on that usb port just fine.

5) The HDD is a 4TB Seagate Backup Plus Portable with two file storage partitions, one an EXT4 (named 'Backup Plus') and the other an NTFS (named 'New Volume'). I don't recall if there was any sort of MBR or file management partition created at the start of the disk or any extra unallocated space left at the end of the disk when I used GParted to set up the partitions. I just let GParted and a few online documents explaining how to use GParted guide me. It's been over a year since I did that so my memory isn't clear. I've been spending most of my time on this problem trying to understand how my ports are mapped on my system using various command line utilities that I've learned about online and trying to understand how they're used via the man pages, hoping I could find something that could send a signal to test the device, such as Seagate's openSeaChest, but the learning curve is steep and I'm a newb when it comes to Linux systems.

I'll get my currently open programs cleared up so I can focus my time and attention on this problem and be able to reboot and try the different suggestions you and a few other users have offered.

 

[aforwood]

G'day @aforwood and welcome to linux.org



If you haven't tried them, can you give us relevant output from

blkid #(may require sudo)

and

sudo fdisk -l

# and also

inxi -Fxz #(with the drive plugged in)

As you are likely aware, /dev/loop is typically for Snaps, and on;y shows up on 'buntu-based Distros, or other Distros for which snaps are in use.

Yours is showing as /dev/loop22 in Disks, so are there other numbered loops - these loops are also read-only by nature.

Cheers

Chris Turner
wizardfromoz

BTW - does it still show in GParted, and if so, choose View-Device information and give us its output?

The loop device that was showing up in Disks has disappeared since doing a reboot, so I don't know what was going on there.

The first thing I did when I saw it in Disks was to check GParted to see if it showed up, but it didn't. I was having some other problems related to security authorizations at the time, which might have caused the loop device to temporarily show up, but those other problems appear to have been resolved somewhat, although dmesg still warns that there's a kernel lockdown, which started before the loop device showed up, and has to do with me screwing around with NetManager, trying to change the password to my wifi connection (since fixed by resetting the router to default password and making a few changes to the configuration files in /etc/NetworkManager/system-connections/).

 

[sphen]

I have recovered a few drives over the years, but not in a long time. The last time was at least five years ago, maybe closer to ten by now.

Dumb question: When you connect the drive, can you hear it spin up? Do you hear the head reset or move? If you tip it slightly and very Very VERY GENTLY, do you get that "gyroscope" feel from the drive and its spinning disk platters? If the answer is no, the problem may not be in the drive itself. @MikeWalsh suggested that it might be the drive case, not the drive. I agree, because I have seen it often. Power supplies and external interface circuit cards fail, especially in low cost drives. Remove the drive and connect it to another external case. I have a "drive adapter" that I use for that purpose.

If the drive platters are not spinning, they may be stuck. This was an old problem that was solved a long time ago, so it is unlikely that you would encounter it, but it is worth a try. Disconnect the drive from all power and interfaces. There is no need to remove the drive from its case, but be sure the cables are all disconnected. Hold the drive flat on a table, then give it short, quick, quarter spin, like from 12 o'clock to 3 o'clock. Spin it while the drive inside the case is flat on the table - you are trying to overcome inertia in the platters themselves.

If the data is truly valuable, there are paid recovery services. They are very expensive. What they bring to the table is:

• Experience at drive recovery.
• Experience with the tools used to recover drives.
• A large collection of circuit cards from many different versions of many different drives that they can use to read your drive if the problem is YOUR card. An exact match is critical, and that's what they do.
• You can spend a lot of money and results are not guaranteed.
  • I have yet to see a full recovery. Ever.
  • They do very well for consumers who want to recover the family photo files. Often the fix is a simple matter of undeleting the files for the customer.
• Not all drives can be recovered.

Nobody has mentioned drive recovery and forensic software yet. Frankly, this is a last resort. I have a binder with a variety of bootable CDs or DVDs that are used for forensics. Later, some were rebranded for data recovery. All of them are old and obsolete, but I found "Caine" and "Deft" and Backtrack (now Kali) and others. Others are in backups that would take too much time to recover. They are obsolete or superseded anyway. I remember that my most recent recovery used something not yet mentioned, sorry.

I would have to start from scratch to identify what tools are currently available and best fit the need. I hope they have improved quality and chances of recovery as well as ease of use. None were easy to use, but if you take your time and pay attention, you can figure them out. Here are a few practices that I follow:

• Your first goal should be to clone the drive and work on the clone. You do not want to operate "without a net" if there is any other way.
• Try every tool in your arsenal without making changes. See what they do and what they can find. If you are not sure what a tool does or how it works or whether you can stop it from committing changes to your precious original drive, then try the tool on an unused test drive to see how the tool works.
• Plan on recovering your data to another drive first. Once you have the data in your hands, then you can try to do more with making the old drive useable enough to mount it as it was supposed to be mounted.
• If you must use tools on the actual drive, factor in the risks when you choose tools or next actions.

I hope this helps.

 

[wendy-lebaron]

I see the OP posting an image of GNOME Disks and...

I remembered one of the few times I was glad I saw a Youtube video talking about any Linux distro! (Usually I don't want to take seriously whatever I watch in any online video service.) Somebody who warned that Snaps could put a large number of loop devices into the system, at least slowing it down, causing a resource problem or much worse... what is being explained in this thread.

Maybe it's a mistake what is being displayed as path. But this isn't a good way to convince skeptical people about Ubuntu's way to distribute applications.

I'm sorry for going off-topic but it's a shame something like this has to happen to somebody, and to a few thousand other people who put all their faith into Ubuntu. I hope the OP could resolve this and at least get his/her data back.

 

[wendy-lebaron]

Power supplies and external interface circuit cards fail, especially in low cost drives.

I have seen it on two drives, one taken from a desktop computer that I purchased in 2004. The flimsy power supply was trying to warn me that the disk itself was going to have read errors. I was trying to recover some data while on Windows which was far and away from "General Failure Reading Drive C:, Abort, Retry, Fail?" of those stark MS-DOS days. :/

The other drive doesn't have its light functioning anymore, and after I couldn't get any Linux OS to read it, I was forced to go into Windows to make a regular error scan and fix.

 

[aforwood]

If you haven't tried them, can you give us relevant output from

blkid #(may require sudo)

micky@base-one:~$ sudo blkid #
[sudo] password for micky:
/dev/nvme0n1p2: UUID="7c9aa68a-01f4-4c04-9e62-d93e734f4d5d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6e76f5c2-8077-473b-bfb6-63169ac4a117"
/dev/loop1: TYPE="squashfs"
/dev/loop29: TYPE="squashfs"
/dev/loop19: TYPE="squashfs"
/dev/nvme0n1p1: UUID="A2B4-CA69" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="cf85a808-369e-4524-8cc3-7458760923ea"
/dev/loop27: TYPE="squashfs"
/dev/loop17: TYPE="squashfs"
/dev/loop8: TYPE="squashfs"
/dev/loop35: TYPE="squashfs"
/dev/loop25: TYPE="squashfs"
/dev/sdb2: LABEL="Backup" BLOCK_SIZE="512" UUID="1F75CE595B0EEB07" TYPE="ntfs" PARTLABEL="Backup" PARTUUID="fbe7b25f-0330-4d3d-a944-821f34c631e1"
/dev/sdb1: LABEL="Expansion Drive" BLOCK_SIZE="512" UUID="7E899C16721AAA40" TYPE="ntfs" PARTLABEL="Expansion Drive" PARTUUID="f607832f-1ec4-4e71-9a61-6ad731a4f21a"
/dev/loop15: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop33: TYPE="squashfs"
/dev/loop23: TYPE="squashfs"
/dev/loop13: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop31: TYPE="squashfs"
/dev/loop21: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop28: TYPE="squashfs"
/dev/loop18: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop36: TYPE="squashfs"
/dev/loop26: TYPE="squashfs"
/dev/loop16: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/loop34: TYPE="squashfs"
/dev/loop24: TYPE="squashfs"
/dev/sda4: LABEL="Passport 4" BLOCK_SIZE="512" UUID="570C7D942E719793" TYPE="ntfs" PARTLABEL="Passport 4" PARTUUID="caa5c5a2-f647-4f34-be78-8ae96a345552"
/dev/sda2: LABEL="Passport 2" BLOCK_SIZE="512" UUID="3A250B90126A4520" TYPE="ntfs" PARTLABEL="Passport 2" PARTUUID="eee9b11f-cfc1-441a-a30e-b615f492423b"
/dev/sda5: LABEL="Passport 5" BLOCK_SIZE="512" UUID="33825F4209F10819" TYPE="ntfs" PARTLABEL="Passport 5" PARTUUID="1099e621-97b9-4d1f-b4c0-3014c9ae1aac"
/dev/sda3: LABEL="Passport 3" BLOCK_SIZE="512" UUID="1F10E4125A418982" TYPE="ntfs" PARTLABEL="Passport 3" PARTUUID="735167e9-366e-4492-8f12-1e9d28d60e77"
/dev/sda1: LABEL="Passport 1" BLOCK_SIZE="512" UUID="30F3961E34510C1C" TYPE="ntfs" PARTLABEL="Passport 1" PARTUUID="15ee2c6e-90d6-4408-96fb-c9094578405b"
/dev/loop14: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop32: TYPE="squashfs"
/dev/loop22: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop30: TYPE="squashfs"
/dev/loop20: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
micky@base-one:~$

It doesn't show up.

 

[aforwood]

If you haven't tried them, can you give us relevant output from

blkid #(may require sudo)

and

sudo fdisk -l

micky@base-one:~$ sudo fdisk -l

Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SAMSUNG MZVLV256HCHP-000L2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 13C4A767-2245-44CF-8F0E-576DF35FAD49

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 500117503 499066880 238G Linux filesystem


Disk /dev/sda: 4.55 TiB, 5000947302400 bytes, 9767475200 sectors
Disk model: My Passport 2665
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 83F2E296-1964-48CF-87AD-240A4CA18F00

Device Start End Sectors Size Type
/dev/sda1 2048 2097154047 2097152000 1000G Microsoft basic data
/dev/sda2 2097154048 4194306047 2097152000 1000G Microsoft basic data
/dev/sda3 4194306048 6291458047 2097152000 1000G Microsoft basic data
/dev/sda4 6291458048 8388610047 2097152000 1000G Microsoft basic data
/dev/sda5 8388610048 9767473151 1378863104 657.5G Microsoft basic data


Disk /dev/sdb: 931.51 GiB, 1000204885504 bytes, 1953525167 sectors
Disk model: Externa
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7647E336-B4F9-4A1C-B0A9-B00AAA86ADA4

Device Start End Sectors Size Type
/dev/sdb1 54697984 1953523711 1898825728 905.4G Microsoft basic data
/dev/sdb2 2048 54697983 54695936 26.1G Microsoft basic data

Partition table entries are not in disk order.
micky@base-one:~$

I stripped out the info for the loop devices to reduce excess data.

The HDD in question still doesn't show up.

 

[Brickwizard]

OK lets go down the silly route
save any work and switch off the computer, connect the ext drive and switch on, [depending on your fixed boot order it will either load from int hard drive or if USB has first boot priority it will try booting from the ext drive [if it boots from the ext drive at least you know its working]
if it loads from the internal disc , then from the terminal run inxi -D and copy/paste back the results