3

I removed my 1 tb external hard disk (Seagate) directly from a windows system and now it is not working anymore. I'm trying to fix it via ubuntu now, and when I try to check it in Disks (gnome utility), it says no media.

I have tried to gather as much input as I can, by running some commands that I could find online in help forums.

sudo lshw -c disk

*-disk
description: SCSI Disk
product: JMS579
vendor: JMICRON
physical id: 0.0.0
bus info: scsi@4:0.0.0
logical name: /dev/sdb
configuration: ansiversion=6 logicalsectorsize=512 sectorsize=512

sudo lshw -class disk -class storage

*-usb:1
description: Mass storage device
product: USB Mass Storage
vendor: JMicron
physical id: 4
bus info: usb@2:4
logical name: scsi4
version: 1.00
serial: 152D00579000
capabilities: usb-2.10 scsi emulated scsi-host
configuration: driver=usb-storage maxpower=34mA speed=480Mbit/s
*-disk
description: SCSI Disk
product: JMS579
vendor: JMICRON
physical id: 0.0.0
bus info: scsi@4:0.0.0
logical name: /dev/sdb
configuration: ansiversion=6 logicalsectorsize=512 sectorsize=512
sudo hdparm -I /dev/sdb

/dev/sdb:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders 0 0
heads 0 0
sectors/track 0 0
--
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 0 MBytes
device size with M = 1000*1000: 0 MBytes 
cache/buffer size = unknown
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0 
sudo smartctl -a -d scsi /dev/sdb

=== START OF INFORMATION SECTION ===
Vendor: JMICRON
Product: JMS579
Compliance: SPC-4
Device type: disk
Local Time is: Fri Jun 22 23:07:23 2018 IST
device Test Unit Ready [unsupported scsi opcode]
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

fdisk -l

Fdisk doesn't show any result for this disk. as it is not mounted anywhere.

sudo dmesg

[141307.332889] usb 2-4: USB disconnect, device number 5
[141310.499914] usb 2-4: new high-speed USB device number 7 using xhci_hcd
[141310.628540] usb 2-4: New USB device found, idVendor=152d, idProduct=0579
[141310.628544] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[141310.628547] usb 2-4: Product: USB Mass Storage
[141310.628549] usb 2-4: Manufacturer: JMicron
[141310.628551] usb 2-4: SerialNumber: 152D00579000
[141310.629107] usb-storage 2-4:1.0: USB Mass Storage device detected
[141310.629201] scsi host4: usb-storage 2-4:1.0
[141311.628514] scsi 4:0:0:0: Direct-Access     JMICRON  JMS579                PQ: 0 ANSI: 6
[141311.629170] sd 4:0:0:0: Attached scsi generic sg2 type 0
[141311.629942] sd 4:0:0:0: [sdb] Unit Not Ready
[141311.629953] sd 4:0:0:0: [sdb] Sense Key : Illegal Request [current] 
[141311.629960] sd 4:0:0:0: [sdb] Add. Sense: Invalid command operation code
[141311.632053] sd 4:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[141311.632064] sd 4:0:0:0: [sdb] Sense Key : Illegal Request [current] 
[141311.632072] sd 4:0:0:0: [sdb] Add. Sense: Invalid command operation code
[141311.632253] sd 4:0:0:0: [sdb] Write Protect is off
[141311.632261] sd 4:0:0:0: [sdb] Mode Sense: 00 00 00 00
[141311.632435] sd 4:0:0:0: [sdb] Asking for cache data failed
[141311.632441] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[141311.635917] sd 4:0:0:0: [sdb] Unit Not Ready
[141311.635927] sd 4:0:0:0: [sdb] Sense Key : Illegal Request [current] 
[141311.635935] sd 4:0:0:0: [sdb] Add. Sense: Invalid command operation code
[141311.639186] sd 4:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[141311.639197] sd 4:0:0:0: [sdb] Sense Key : Illegal Request [current] 
[141311.639205] sd 4:0:0:0: [sdb] Add. Sense: Invalid command operation code
[141311.639534] sd 4:0:0:0: [sdb] Attached SCSI disk
[141594.937486] EXT4-fs (sdb): unable to read superblock
[141594.937770] EXT4-fs (sdb): unable to read superblock
[141594.938048] EXT4-fs (sdb): unable to read superblock
[141594.938335] SQUASHFS error: squashfs_read_data failed to read block 0x0
[141594.938337] squashfs: SQUASHFS error: unable to read squashfs_super_block

no record for sdb in /proc/partitions

Here is the output of various gdisk commands that I tried:

sudo gdisk
GPT fdisk (gdisk) version 1.0.1

Type device filename, or press <Enter> to exit: /dev/sdb
Problem reading disk in BasicMBRData::ReadMBRData()!
Warning! Read error 22; strange behavior now likely!
Warning! Read error 22; strange behavior now likely!
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************

Command (? for help): i 
no partitions

Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): Y

Command (? for help): p
Disk /dev/sdb: 0 sectors, 0 bytes
Logical sector size: 512 bytes
Disk identifier (GUID): ACBB4EFC-7AE9-4C9B-B804-DA09D936163D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 18446744073709551582
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name

Command (? for help): v

Problem: Disk is too small to hold all the data!
(Disk size is 0 sectors, needs to be 0 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 18446744073709551582, but backup header is at
18446744073709551615 and disk size is 0 sectors.
The 'e' option on the experts' menu will probably fix this problem

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Identified 3 problems!

Command (? for help): x

Expert command (? for help): e
Relocating backup data structures to the end of the disk

Expert command (? for help): z
About to wipe out GPT on /dev/sdb. Proceed? (Y/N): Y
Warning! GPT main header not overwritten! Error is 28
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.

Expert command (? for help): p
Disk /dev/sdb: 0 sectors, 0 bytes
Logical sector size: 512 bytes
Disk identifier (GUID): 4B3EC7B7-2E9E-4933-885C-0CF09BFBE24C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 18446744073709551582
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name

Expert command (? for help): w
Caution! Secondary header was placed beyond the disk's limits! Moving the
header, but other problems may occur!
Warning! The claimed last usable sector is incorrect! Do you want to correct
this problem? (Y/N): Y
Have adjusted the second header and last usable sector value.

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdb.
Unable to save backup partition table! Perhaps the 'e' option on the experts'
menu will resolve this problem.
Warning! An error was reported when writing the partition table! This error
MIGHT be harmless, or the disk might be damaged! Checking it is advisable.

I also tried to fix it using the Windows system. it shows Unknown, not initialized in Disk Management. I tried Diskpart as well, here is the output for various commands under that:

clean: 
DiskPart succeeded in cleaning the disk

recover: 
Virtual Disk Service error:
The disk is not initialized

convert gpt: 
Virtual Disk Service error:
The system's information about the object may not be up to date

DiskPart has referenced an object which is not up-to-date.
Refresh the object by using the RESCAN command. 
If the problem persists exit DiskPart, then restart DiskPart or restart the computer.

rescan:
Please wait while DiskPart scans your configuration...
Diskpart has finished scanning your configuration. 

convert mbr: this one didn't work as well. 

I tried EaseUs as well, it couldn't detect the drive.

Any help is highly appreciated, thanks in advance.

9
  • As no-one's picked up on this yet... it sounds like you had an issue, then spent several hours making it worse before asking for help. Professional data recovery might be your only option now, assuming you can't just nuke it & restore from backup.
    – Tetsujin
    Aug 17, 2018 at 16:57
  • actually, I tried the safest options first to gather important information only, but when i couldn't get anything I moved to diskpart and tried to restore gpt/mbr and then to my last resort gdisk and complete cleaning. But nothing worked. I know my data is there in the hardisk i just need to fix it to make it accessible. After that there are many data recovery tools which can recover the data as long as the data is not overwritten by anything else.
    – Sachin
    Aug 17, 2018 at 17:10
  • which just makes it a possible duplicate of How do I recover lost/inaccessible data from my storage device?
    – Tetsujin
    Aug 17, 2018 at 17:17
  • I went through the link provided, and none of the issues mentioned seems to be the cause. it is more about making the disk accessible again, recovery is my ultimate objective but out of question at the moment now. Please remove the duplicate flag from it.
    – Sachin
    Aug 17, 2018 at 18:13
  • Looking at the information provided: /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a snip... Does your drive have a security feature enabled that would prevent access without the correct password ? Configuration: Logical max current cylinders 0 0 heads 0 0 sectors/track 0 0 Seems like your not able to get valid information from the drive. Focus on getting good geometry data first.
    – Hogstrom
    Aug 19, 2018 at 13:08

3 Answers 3

0

Diskpart does not affect the actual data if you not explicitly force it to do so - your assumption is correct the data is still there.

SMART-diagnostics (for example accessible via Gnome-Disks in Ubuntu) will show you eventual hardware-failures, but it seems that Windows was actively writing data to the drive, which happens since Windows 7 very often as it is a delayed operation that runs when resources are free/io-load is low.

Also the indexing-service accesses the drive regularly and repeatedly in read/write-mode to store the gathered metadata. If you wish to prevent this in the future and wish to force the immediate write/sync then you can enable the disk-cache in the hardware-properties of the drive next time you access it via Windows. You will give up the functionality to quick-remove the drive though and need to unmount via the Devices-Selector in the SysTray - similar to the mount-operations in Linux-Distros.

If you wish to use Windows-based software or explicitly GUI-applications then your best bet will be Macrium Reflect, either installed inside Windows as an application or by using its functionality to create a Windows PE based Rescue-System you can run similar to a Linux-Live-system from an USB-Drive.

I recommend although to use:

TestDisk

... which is the most reliable tool for data/partition-recovery, especially because it does not change the contents of the drive based on the possible partition-structure it finds until you decide to do so. It has no GUI, but runs in a terminal-window and offers an assisted approach to scan for files/folders/partitions by actually scanning the raw data on the drive.

If you can remember the partition-structure, the estimated sizes and position of each and if you remember the names of the partition-labels you are good to go, it is all you need to identify the correct partitions. The preparation/scanning/analysis takes actually longer than the restoration/recreation of the partition-structure.

Assuming you read the manual and on-screen-directions given in the text-interface of TestDisk it will repair your drive if it is indeed not a hardware-failure.

2
  • For speed sake and to guarantee the JMicron-Controller which are known to rely on a correct blocksize and readable sectors in the first 34 bytes of the disk, as well as a basic MBR/GPT-structure i would advise to pull the drive from the enclosure and plug it directly into a pc if possible. This is especially helpful if it is a USB3.0 adapter running in backwards-compatibility on a USB2.0/1.1 or a 3.1 Port/Hub. Nov 12, 2021 at 5:38
  • Additionally: Due to the use of an adapter hdparm can not access the firmware of the drive itself as all access is translated through the JMicron-Adapter. Attaching the drive directly should allow you to read all information and if available apply a firmware-update or if necessary rewrite the firmware via the firmware-updater provided by the manufacturer, in your case Seagate. Nov 12, 2021 at 5:42
0

You used diskpart to clean the disk and destroyed all the data. Not good. With luck, only the meta data was destroyed and the files are still there. If you are lucky, there may also be a backup meta data on the disk which can be accessed by the right product.

But always remember rule #1 which says : Never modify the disk you are trying to salvage.

Your only hope now, if you don't have a backup, is to use a recovery product.

For a list of such products with reviews see this article :
Best Free Data Recovery and File Un-delete Utility.

As not all the products use the same algorithms, you may try them one by one. If you manage to salvage some files, write them to another disk, not to the disk you are trying to salvage.

The one on the list that I found to be the most effective in a similar case was MiniTool Power Data Recovery, although recovering more than 1 GB of data at a time requires the commercial version ($69).

If the files prove unrecoverable but are of great value to you, you may contact a commercial salvage company. You will need to ship them the disk, and be aware that these services are costly. So better shop around the Internet and verify well the reputation of the service before choosing.

There are also commercial products to be found on the internet by searching for "data rescue" or "data recovery". Some of them have a free download where analyzing the disk is free but recovering the files may require payment.

2
  • That first link is dead.
    – Gantendo
    Nov 12, 2021 at 1:45
  • 1
    @Gantendo: Fixed with a link from the Internet Archive.
    – harrymc
    Nov 12, 2021 at 9:32
0

This has all signs of a non-software fixable issue. So you can stop fiddling with software as it potentially only makes things worse.

As a rule of thumb, the minute a (physical) drive stops correctly ID'ing itself with correct capacity, you are dealing with an issue you can not fix/tackle using software alone. If underlying issue is media damage then running software potentially only causes additional damage. If a drive stops ID'ing with correct capacity then it's very unlikely the PCB is the culprit as this information is kept mostly on the the platters (firmware) which may be corrupt due to media damage.

As a rule of thumb, if a drive spins, the issue is not the PCB.

If the data is of importance, best advice at this point is, to take to a data recovery specialist. Many labs offer a free diagnosis. The 'common knowledge' that a data recovery service will charge several thousands of Dollars by definition is a myth as long as you avoid larger franchises. Many media type issues or even 'weak' heads, firmware issues can be handled without ever opening the drive in a cleanroom. It's often the cleanroom work that makes a recovery expensive.

There were times in which you could try removing a drive from it's USB enclosure. This had several advantages:

  • You can rule out the enclosure itself is the problem.
  • In event of minor read issues (media/head damage), error handling is best left to a drive's native interface rather than having to deal with the extra USB layer. Most USB bridges s*ck at handling errors. A USB drive that hangs constantly while copying data may be handle-able when connected to a native SATA port for example.

Nowadays it is often no longer this straight forward.

  • USB enclosure may provide/handle encryption.
  • USB enclosure may present drive as 4K device, and so it was partitioned, formatted etc. assuming 4K sectors.
  • USB may not be easily bypassed anyway if it's integrated into drive's PCB.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .