Hello everyone!

I have a Seagate Barracuda internal hard drive (ST2000DM001) that I was using as an extra data drive, and just recently it stopped being recognized by Windows & the BIOS. I should mention early on that the data on here is not at all valuable and not worth professional recovery efforts, I have already considered it lost. That being said, I wanted to try messing around with it to see what could be done and maybe see if some data could be pulled off, just to learn more!

When plugged in, the drive spins up like normal, but I cannot hear any sound of head activity. I did some reading & purchased a CP2104 USB TTL adapter, and then hooked it up to the COM port (TX & RX pins) to pull the logs. This is what I get:



I would really appreciate any guidance on what steps I should take to see if I can get this drive recognized again & maybe even see if any kind of data recovery is viable!

Many thanks!

Did a little more reading, looks like getting terminal access is the next step to be able to use commands to see if anything can be done.

Unfortunately, the system appears to hang after the "(P) SATA Reset" event is logged. Pressing Ctrl + Z at any point in the process does not bring up the input line. To possibly resolve this, it looks like the read pins need to be shorted. I am not able to take the PCB off, since I don't have the T6 bit required to remove the motherboard. I'll be purchasing the right bit soon and doing more research / investigation with a multi-meter to try and find the right pins on the board. Then I'll try shorting the pins to see if I can get terminal access.

Hope it works!

Hey Everyone!

Found some time to get back at this. Got the right tool, took the board off, and must have done something to mess up the HSA pads or another part of the board, because putting the board back on the drive caused it to click and stop spinning. Ordered a new PCB, did a ROM chip swap, and now the drive is back to spinning properly. Not only that, with the old PCB I wasn't able to access terminal commands, but with the new PCB, repeatedly pressing CTRL + Z during the boot process gives me command line access, no need to short pins. Not sure what is different or how that is possible, maybe TX/RX pins on old board were not functioning properly.

The boot log is the same as before, with the exception of the command line:



I've gone ahead and run the informational commands, and I've attached their results. In summary:

X -> Not too sure how to interpret, heads 0 and 4 might be weak?
V1 -> Long list, around 7610 entries
V2 -> Short list, 10 entries
V4 -> Long list, 11285 entries, 385 alts
V10 -> Long list, 9040 entries
V40 -> No Entries
N5 -> Not sure how to interpret

I tried clearing S.M.A.R.T with N1 and power cycling, unfortunately the drive was still not visible in BIOS afterwards.

I feel like getting it visible is very close, similar threads report clearing G-list & SMART, then power cycling, but others try rebuilding translator. However, my translator appears to be loading correctly, so I wanted to consult with you folks before trying anything too drastic.

Any help would really be greatly appreciated!

I vote for H1 being weak.

It should still get ready though, at least visible during BIOS detection.
FYI, the sata interface is not accessible in ASCII diag mode (ie after pressing ctrl-z).
press ctrl-r to return online mode and press ctrl-V to activate echo interface commands.
It would also be useful to check it with some low-level prog like mhdd.

pepe

_________________
Adatmentés - Data recovery

pepe, thank you so much for your reply.

I will have to work the heads until they die unfortunately, no replacement for me (no clean room or experience). There were some interesting developments after following your suggestions. Pressing CTRL-R after CTRL-Z caused the command line to hang. It seemed that the drive was not able to go ready. I tried to 'force' it to ready by repeatedly restarting the computer into the BIOS, with only the problem drive connected, and after several tries, the drive properly ID'd. I immediately connected my spare target drive and booted into linux to attempt ddrescue, but when trying to run ddrescue (forward and reverse), nothing could be read properly. It seems there is extensive firmware damage. I've attached photos of what I saw.

I restarted the machine and attempted to read the terminal boot log again to see if anything was different, and I saw some new errors appear that I hadn't seen before, before the terminal again hung. I power cycled, pressed CTRL+Z and was able to get a prompt again. I've attached a picture of those errors as well.

Some research led me to believe that some of those errors are with sysfile 17a and possibly 133, but an AceLab document says that if these files were damaged I would get 'DiagError 0000000E' when trying to read them, but instead, the files appear to read normally. I don't really know if these sysfiles are damaged or not. I've attached the read attempt.

I also saw what appeared to be Media Cache errors (LED000000EE), so I think Media Cache needs to be disabled as well. I believe these are the commands to do so, after looking at some other threads.



Should I go ahead and disable the Media Cache? How do I determine if sysfiles 17a and 133 are really damaged? I've attached CTRL+X as well, I've read it can possibly display damaged modules, but unfortunately I'm struggling to understand it. I feel like I'm close to getting this drive to reliably ID!

Thank you so much for your help!

An update to this, the drive is now able to ID properly, and data is being copied through ddrescue (sector copy to another 2TB drive).

I did my best to fix the errors that were popping up. For the media cache errors, I backed up sysfile 346 before writing a zeroed out copy of the same size, I then re-initialized the MCMT using the U1, U2, and U3 commands. I finally then disabled it entirely using the Cogen command found in this sysfile93 patching thread (after backing up sysfile 93):

http://www.hddoracle.com/viewtopic.php?f=59&t=1842

After dealing with Media Cache, I was still unable to ID the drive in BIOS. I went on to try and fix the SIM 1009 error. Following this link,

https://web.archive.org/web/20170914073351/http://ts.acelaboratory.com/index.php?/Knowledgebase/Article/View/23/0/sim-error-1009-rw-error-00000080-17a-sys-file

I backed up copies of the 17a (SMART config?) and 133 (also SMART config?) sysfiles. I then downloaded and wrote the files provided in the above link, since they were the exact same size. It should be noted, however, that even after doing this I saw the SIM 1009 error once more, and the link then suggested a translator regeneration.

Before attempting that, I backed up sysfile 93 again and applied the remaining commands from the above sysfile 93 patching thread, to completely disable reallocation. After a power cycle, drive was still not able to ID.

I then went on to clear g-list. I checked non-resident g-list to ensure there were no entries, and made backups of sysfile 28 (translator), and 35 (non-resident g-list). I then used this command:

to clear g-list. I followed this with clearing SMART:

Finally, I regenerated the translator using this command (includes ALT list):

Interesting to note that, after regenerating translator, 3 entries appeared in the non-resident g-list. I then made backups of these new 28 and 35 sysfiles as well, just in case. I followed this with a power cycle of the drive, then headed into my Ubuntu environment, where I plugged it in and it ID'd after a little bit of waiting, with access to the user space. The sector copy then began in ddrescue.

It is expected to take 40 days, I don't believe the heads will last that long, but I intend to let it run until it is no longer able to. There is extensive media damage with bad sectors, and the heads aren't in the best shape (drive is around 8 years old). I am also aware the firmware is in bad shape, despite my best efforts. I know some of those bad sectors are in the Service Area.

All in all, not too bad! I learned how to do a successful PCB / ROM swap, followed by learning so much about Seagate's F3 architecture and terminal commands. I may not get the data in the end, but the knowledge itself was well worth it. Now it is time to play the waiting game. Who knows, maybe it will complete, I've been surprised before!

nice progress, albeit, as i said H1 is weak, it might die completely or even survive, but the data will be corrupt anyway due to missing blocks.
The drive could be cloned in a few hours with the working heads on a good tool, and probably would be completely recoverable after a head swap, but if you decide to torture it, it's up to you of course...

pepe

_________________
Adatmentés - Data recovery

Pepe, that's true, a hardware imager would for sure be faster than software. Fortunately, I am not in need of the data and just wanted to learn so that would be an unnecessary step for me. But its excellent advice for those with critical data (who should be taking the drive to a professional immediately anyway!).

I do have one question about what you said though. I understand that corrupted sectors on the media mean that files that use those sectors would be corrupt. I also understand that a hardware imager would be faster with the existing heads, and probably more so with a new set of heads.

But I don't understand how the use of a hardware imager and new heads would yield less corrupt files (make the drive completely recoverable, as you mentioned). If the sectors are bad / blocks missing, wouldn't they stay bad regardless of heads / imaging method? Would really appreciate some insight on this!

Unrelated, but for anyone who may come across this, I discovered that I caused the drive to have a partial access problem using the commands in my previous post. The last third of the drive was unreadable in MHDD, throwing uncorrectable errors.

After regenerating translator using

in the previous post, I noticed the V1 - slip defect list had lost 3 entries from before the regeneration. Also, the non-resident g-list had gained 3, being 0 before. I imagine they migrated from one list to another. I do not know why. I didn't pay any attention to it, and began imaging the drive like normal. I discovered the error when trying to go in reverse, ddrescue was unable to read any of the higher LBA's.

Back in terminal, I restored my backed up copies of the original empty non-resident g-list (module 35) and translator (module 28) by writing them back to the drive. I then power cycled, and checked the V1, V4, V10, & V40 lists. All had successfully restored to how they were before I ran any commands. I then reset g-list again, reset SMART, then regenerated translator without including the ALT list:

After completing, I power cycled and again looked at the lists. They were all the same values (correct), and I was then able to access the beginning, middle and end of the drive again in MHDD. I am now continuing the same ddrescue image, after using the same logfile. Will see how it goes...

It all depends on the type of damage. Different heads may read weak sectors which the old ones could not, hardware imagers give better control of reading methods, timeouts and retries. If it's physical damage to the platter surface causing the defects that's a different matter.

Tweaking stuff like this is why there's a difference between in success rates (and costs) between DR companies.

Swapping the heads as Pepe suggests is the least risky (correct) way to recover. Where my clients can't/don't want to pay for a head swap I often ride bad or weak heads into the ground at their request to get as much data for them as cheaply as possible, retail clients tend to be more concerned about costs than time and I'm normally happy to leave a drive running.

You may also want to check out hddsuperclone for a bit more control than ddrescue, although there's no substitute for turning a head off the head skipping algo isn't too bad and gets there in the end.

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

Skipping the weak head makes imaging fast with native (bad) heads, only using good ones.
replacing the heads gives access to those areas that are unreadable now due to the weak head.
From your logs i concluded the problem is more likely with the head instead of the surface (which might also be damaged here and there of course, who knows).

pepe

_________________
Adatmentés - Data recovery

Lardman, many thanks for the clarification. That does make sense, better heads would be able to make more sense of troublesome spots compared to weaker heads. I suppose I thought it was more of a binary thing where you could either read it properly or not, but as I discovered through this process, hard drives are much too complicated for simple assumptions like that! I'll check out hddsuperclone, ddrescue is making some good progress right now, but its algorithm seems interesting.

Pepe, I understand now, thank you. I do believe there is damage as well on the media, we'll have to see how much of an impact it will really have though. The pressing concern is seeing if the heads even survive, though I doubt they will. Thanks again for the insight!

Hey everyone, just had an update to this.

As it turns out, Pepe's earlier assertion was completely correct.

ddrescue completed a first copying pass, rescuing 57% of the total drive. Viewing the rescue log in ddrescueview, there were some clear zig-zag patterns with non-tried areas across the drive surface, which from my reading was indicative of weak head(s).

I thought that there was nothing else left for me to do, but after some more reading I found an experimental, risky technique employed by some of the more senior members on Seagate drives with weak heads, a technique which involves manipulating the flying height of the read/write heads. For any that may come across this, here are some great resources and information on this technique:

https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiTkeH_kevwAhXbAZ0JHbLHAuUQFjABegQIAxAD&url=http%3A%2F%2Fmaeresearch.ucsd.edu%2Fcallafon%2Fpublications%2F2011%2FUweIEEETonM.pdf&usg=AOvVaw1DSRpO_KfX5aJzdhM-wS9V

http://www.hddoracle.com/viewtopic.php?f=175&t=2682
https://forum.acelaboratory.com/viewtopic.php?f=154&t=9993

Essentially, it involves manipulating the current flow to the resistive heating element at the tip of the read/write head to raise/lower the flying height. This is achieved by adjusting the Read Adaptive Parameters, specifically, the RHtClr parameter. In this case, the goal was increasing current flow to the element to cause the tip to expand, dropping the weak head(s) closer to the platter surface to get a better read.

I followed the above instructions, applying the above technique to head 1 first since Pepe was confident in it being the troublesome head. A boost of 20 led to some lower LBA's becoming readable, but the higher ones still throwing errors. A boost of 30 across all zones led to the higher ones becoming readable, but not the lower ones. Eventually I settled on a boost of 2E across all the zones for head 1, giving stable reads on lower and higher LBA's that were previously entirely unreadable. Changes were tested with a quick run through sections of the drive with MHDD.

I am now continuing the previous ddrescue image, it is going through and picking up all the previously unreadable areas at a solid rate of about 5 MB/s - 7MB/s, compared to the 500 kB/s it was reading through the other heads. Whether the head(s) will survive to complete the image or not, only time will tell...

@CalculatedRisk, that's some really good work. Good luck!

_________________
A backup a day keeps DR away.

good job!. I do it all the time with all kinds of Hdds (having at least a read heater of course), BUT under instrumental control. Overloading the heating element can lead to breaking it completely, either the reading element or the heater, not to mention the surface. I still consider it risky if done blind.

pepe

_________________
Adatmentés - Data recovery

Excellent tweaking ! and results. Hopefully you'll get what you need from the drive. Thanks for posting back and updating us.

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

fzabkar, thank you so much! Its been an incredible learning experience, a huge thank you to you for all the research you've put up online both here and hddoracle, I've referenced a lot of your work in my earlier posts. You've made it very easy for those with no understanding of HDD recovery and the Seagate F3 architecture like myself to develop a better understanding.

Pepe, many thanks for your help, you were bang on with your earlier analysis! That's interesting to know, I didn't know it was possible to damage the heater itself, but I can see how something like that could happen. Agreed, it is definitely a risky procedure, I don't think it should be done carelessly (DIY) on a drive with any important data, hand off to a professional like yourself would be best in that case.

Lardman, thank you, I really appreciate it! Fortunately, there is nothing of value on this drive I am seeking to recover, this was all just for learning and educational purposes. I hope by posting my progress and some of the resources I've used here, someone may learn just a little bit more. I would hope that anyone who may have similar issues on an important drive would take the drive to a pro immediately and not do anything I've done here, given the risks. Perhaps some of the links I've shared here may help them understand what might be going on behind the scenes.