I will document here how to hack a Seagate hard disk that ran into one of these annoying firmware bugs that affected the Seagate Barracuda 7200.11 series lately. If you want to know more about the background you may want to start with the first part of the story.
The friend who brought me the disk kindly came by the next day to help with the operation. According to the recipes I found here and here, we had to connect the hard drives service port to a serial console via a RS232-TTL converter. My friend prepared the RS232-TTL converter, brought a stable power supply as we needed 5V to operate. My task was to prepare the operating table, find a serial cable and a computer with a serial port, a two-pin-connector with wires and to get to know minicom.
So and here is how we did it:
First we connected the converter to the devices. The docking station of my notebook has a serial port, so I connected it via a serial cable to the converter. The three wires coming from the converter had to be connected the hard drive directly. We fixed the ground wire with a screw of the board. The Rx and Tx connectors had to be connected to the Tx and Rx connectors of the drive (so just cross them). Thats where we used the two-pin-connector. On the drive the pin next to the SATA connector is the Rx and next to this one is Tx. The other two are reserved and we did not need them.
The most tricky part was about to be next. We had to interrupt the power supply for the motor of the platters but keep everything else connected properly. And it must be possible to remove this interruption during the operation. We unscrew all screws a little and pushed a piece of paper between the contacts of the board and the connector, and fastened the screws just a bit.
So much for the preparation. Let’s start. Here is my minicomrc I used to communicate with the drives firmware:
$ cat minirc.seagateBug # Machine-generated file - use "minicom -s" to change parameters. pu port /dev/ttyS0 pu baudrate 38400 pu bits 8 pu parity N pu stopbits 1
Now we connected the the SATA power cable to the drive and let minicom establish the serial connection. And really, I got first contact with the drive:
Even the error codes the drive dumped to the screen were correct according to the recipe. So we were on the right track. Now it was just about to properly retype the commands into minicom and patiently wait for the drive to complete the commands. Here is a screenshot with some comments in it.
Then finally we were done. But we did not repair the drive, but only reactivated it. Now it can run into the same bug again any time (but only on startup, so we would notice). So we tried to prevent as many restarts as we could. The first thing I did was connect it to an external SATA-2-firewire case and use the first startup of the disk to backup all important data. The second thing I did was connect the drive to the onboard connectors of my workstation and boot from the firmware upgrade CD I downloaded from the Seagate website the day before and deployed the new firmware to finally get rid of the bug.
In the end the disk felt quite well back in its original machine. Fortunately we had nothing more to fix within the installed system (yes, it was the other operating system).
Btw. the commands we sent to the drive took serveral seconds each to process, so we had to wait for for them to finish. Disconnecting power too early would have broken the disk. Thats why I connected all vital systems to my UPS for this hack. If you happen to have such a Seagate drive, my deepest regrets to you and good luck for your recovery hack.