Seagate ST3000DM001: 2 HDDs, one fried, ROM differences
February 25th, 2022, 18:42
Hi guys,
I have two Seagate ST3000DM001. One I use for backup ("HD04-good"), the other ("HD03-fried") was on the server and the PCB + PC Power Supply fried (1,8V regulator on the HDD board blew off). Backup was late some months, want to recover data on the "fried".
Measured motor coils resistance (without PCB) on both and they are similar.
I'll perform a board swap. But first I made a backup of both ROMs (Flash) and in F3Rom Explorer I got a BAD CRC in the "DL_BFWDIR" for the HDD that fried! Their stored values at CRC location are equal on both binaries, but the one that fried have lots of 0xFF's whereas the other have some data that seems a structure composed of "types and addresses".
I'm not familiar with HDD recovery but seems to me that there is an error here. a) a lot of 0xFFs b) DL_BOOTFW are the same on both ROMs and my "intuition" says that this DL_BFWDIR is what "addresses" the BOOTFW.
RAP+CAP+IAP have good CRCs checked so I think I can trust them!
So my questions:
1) Is the fried ROM image corrupted?
2) Can I use the same 04-fried.bin but change those bytes "copying" from the 03-good.bin?
3) Is there any harm that can be done powering this HDD with this "bad CRC ROM"?
4) Any good souls out there with correct program to make this "bad ROM" a "good ROM"? To make this transplant in a safer way.
I'm setting up an environment with a patched Linux kernel to make sure that not even one single bit will be written to the disc before I copy the data because if I mess up those adaptives I don't want the OS writing to the disc device.
Thank you very much!!
Appreciate any help/guidance/information
Eduardo
I have two Seagate ST3000DM001. One I use for backup ("HD04-good"), the other ("HD03-fried") was on the server and the PCB + PC Power Supply fried (1,8V regulator on the HDD board blew off). Backup was late some months, want to recover data on the "fried".
Measured motor coils resistance (without PCB) on both and they are similar.
I'll perform a board swap. But first I made a backup of both ROMs (Flash) and in F3Rom Explorer I got a BAD CRC in the "DL_BFWDIR" for the HDD that fried! Their stored values at CRC location are equal on both binaries, but the one that fried have lots of 0xFF's whereas the other have some data that seems a structure composed of "types and addresses".
I'm not familiar with HDD recovery but seems to me that there is an error here. a) a lot of 0xFFs b) DL_BOOTFW are the same on both ROMs and my "intuition" says that this DL_BFWDIR is what "addresses" the BOOTFW.
RAP+CAP+IAP have good CRCs checked so I think I can trust them!
So my questions:
1) Is the fried ROM image corrupted?
2) Can I use the same 04-fried.bin but change those bytes "copying" from the 03-good.bin?
3) Is there any harm that can be done powering this HDD with this "bad CRC ROM"?
4) Any good souls out there with correct program to make this "bad ROM" a "good ROM"? To make this transplant in a safer way.
I'm setting up an environment with a patched Linux kernel to make sure that not even one single bit will be written to the disc before I copy the data because if I mess up those adaptives I don't want the OS writing to the disc device.
Thank you very much!!
Appreciate any help/guidance/information
Eduardo
- Attachments
-
-
-
- HDs-ROMs.zip
- (742.36 KiB) Downloaded 247 times
-
-
Re: Seagate ST3000DM001: 2 HDDs, one fried, ROM differences
February 25th, 2022, 19:14
More observations
1) On the GOOD HDD CAP first & seconde name are blank! On the fried is ST3000DM001-9YN166.
2) Servo FW revision differ. Is this OK are besides ROM swap is also necessary to change some file in SA? Which file/volume?
3) EXTRA_SPACE are different. Is this OK?
1) On the GOOD HDD CAP first & seconde name are blank! On the fried is ST3000DM001-9YN166.
2) Servo FW revision differ. Is this OK are besides ROM swap is also necessary to change some file in SA? Which file/volume?
3) EXTRA_SPACE are different. Is this OK?
Re: Seagate ST3000DM001: 2 HDDs, one fried, ROM differences
February 28th, 2022, 21:27
If this helps anyone: solved the problem by copying the good data from the good binary into the other, checked CRCs in F3Rom explorer.
Used console, power up without sata, checked ctr+z ctrl+x the last commands and saw read/writes in SA... booted with linux forensics mode ro,noatime,loop in a ro block device and all data was there.. copied to another disk rebooted and used in normal read/write without a problem.
Used console, power up without sata, checked ctr+z ctrl+x the last commands and saw read/writes in SA... booted with linux forensics mode ro,noatime,loop in a ro block device and all data was there.. copied to another disk rebooted and used in normal read/write without a problem.
Powered by phpBB © phpBB Group.