476
edits
Locked HGST drives: Difference between revisions
520-byte sector changes
(added problems 2 and 3 and fixed up a lot of stuff) |
(520-byte sector changes) |
||
| (3 intermediate revisions by the same user not shown) | |||
|
This is a very common problem with decommissioned enterprise SAS drives and also typically very easy to fix.
All you need is a "true" HBA in the server that is reformatting the disks
Dell PERC cards and HP Smart Array controllers cannot communicate with 520-byte sector disks whatsoever, even when put into "HBA mode".
The cards inside the [[Servers|Kurisu and Okabe]] servers have been flashed with the "IT mode" firmware, as their PERC cards were old enough to be flashed using [https://fohdeesha.com/docs/perc.html a script]).▼
▲The cards inside the [[Servers|Kurisu and Okabe]] servers have been flashed with the "IT mode" firmware, as their PERC cards were old enough to be flashed using [https://fohdeesha.com/docs/perc.html a script]
The sector size of a disk can be reformatted to 512 bytes using <code>sg3utils</code> with the command below:
<code>sg_format -v --format --size=512 --six /dev/sgX</code>
Of note,
* Netapp needs ten-byte
== Problem 2: (Hitachi VSP firmware) ==
The primary issue with these drives is the firmware
* They will experience I/O errors when used on a regular system, even
* Apparently it is related to the firmware only accepting <code>SCSI_WRITE_WITH_VERIFY</code> commands [https://old.reddit.com/r/DataHoarder/comments/7raoz8/firmware_for_hgst_10k_sas_huc109090css600/idxmolz/]▼
These exact physical drives are also sold as OEM variants that work in generic systems without issue.
▲Apparently it is related to the firmware only accepting <code>SCSI_WRITE_WITH_VERIFY</code> commands [https://old.reddit.com/r/DataHoarder/comments/7raoz8/firmware_for_hgst_10k_sas_huc109090css600/idxmolz/]
* It should be possible to put OEM firmware onto the disks to allow them to work in our servers. (this leads into problem 3)
== Problem 3: (Firmware lock) ==
In addition to the previous problem, the drives also have a lock that prevents rewriting the firmware.
=== Russian dude (WD Niagara) ===
There is a Russian dude who, for the price of ~$10/drive, will RDP into a Windows environment and flash the drives for you. [https://forum.hddguru.com/viewtopic.php?f=22&t=39927&sid=121a6e12d2d1fdaf816fe00eedac1745]
Should we have the money, this is the easiest route to solve the problem. However, by that point, it makes more sense to just buy new drives.▼
He has uploaded a video of the process to YouTube [https://www.youtube.com/watch?v=mAhS_sk3wKE]
▲
=== Hydata SCSITools ===
According to a Chinese dude who paid for Hydata SCSITools in another ServeTheHome thread, this program can also send the command to unlock the drives and flash the firmware.
A SCSITools license is $2800.
* SartenX recommended asking them for a free license as students, I seriously doubt they'd
* It just pulls in <code>hasp_windows_102966.dll</code> which is the Sentinel HASP (Hardware Against Software Piracy) all-in-one check that looks for a valid USB hardware key plugged into the computer.
* I doubt fiddling with Sentinel HASP would be easy, it has checks for VMs, emulated dongles, and even WINE for some reason
=== Hardware ===
We also considered flashing the drives via the hardware, with a Pomona SOIP8 clip (SOIP8 is the same form-factor as SOP8)
We identified the following chips on the drive's mainboard:
## Drive Spindle controller?
* LSI TNNKU873 BJR12034: microcontroller▼
## DDR2 memory
* MAXIC 25U40325 M1-126: the SOP8 ROM (this is the big one)▼
## Microcontroller
# MAXIC 25U40325 M1-126
Apparently only disk-specific calibration information is stored on the ROM and not the actual firmware.
^ (Josh found a forum post from someone trying
So the hardware route is a dead-end :(
__FORCETOC__
__NOEDITSECTION__
| |||